Introducing: Enhanced Performance Settings for Faster Static Loads
Making your site even faster, without reliance on any third-party Plugins.
Yes, a Static version of your WordPress site will inherently load faster than traditional, database-driven WordPress.
In fact, the perceived user load speed is significantly faster as a user loads and traverses a site.
If your HTML, however, isn’t optimized then Static WordPress hasn’t traditionally been able to fix that for you. Why? Well, for one, the way we (as well as many others like HardyPress and Simply Static) generate static is just converting your pages to Static HTML. If they’re not optimized, they’re not optimized.
And if your HTML is not optimized, Google Page Speed is going to massacre you.
- Deferring render blocking scripts and css
- Loading critical CSS (above the fold)
- Lazyloading images
- Preloading above the fold, critical elements
All of that has been true until today. Say hello to optimized HTML through the Headless Hostman.
Again, the Headless Hostman takes your existing WordPress site and converts the pages systematically to Static HTML.
That Static HTML is then sent to a Static hosting environment.
Because we’re dealing with your raw HTML, we have the ability to enhance and optimize it for speed during generation during the conversion process.
Previously, we recommended Plugins to Help Optimize Your HTML … But There Were a Few Limits
At the end of the day, optimization Plugins built for WordPress are built for a database-driven, traditional WordPress site. Typically they will:
- Optimize HTML
- And then store that HTML within the database to serve it
We could capture that HTML during generation, but ran into issues:
- It’s hard to actually get that HTML during Static conversion. We tried a slew of methods, but sometimes those optimized pages would just avoid detection because we’re reading with programming, not as a user. In fact, sometimes users even have issues seeing load of optimized content.
- Most are incapable of properly or accurately capturing above-the-fold CSS for Critical CSS
- Most just plain break jQuery scripts sitewide while trying to minify, defer, or delay them
- All of them run slow and resource-intensive jobs in the background that can sometimes take too long
- All of them require “cache clears” to update your optimized HTML
And beyond that, we couldn’t find the features we wanted to specifically see, like:
- Auto-detecting above-the-fold images and adding them for preload in the <head> for faster first-contentful paint
- In the instance of multiple CSS stylesheets, combining them and deferring them to not be render blocking
Other Downfalls of WordPress Caching and Performance Plugins
And at the end of the day, these Plugins are meant for database-driven, traditional WordPress.
It’s objectively proven that traditional WordPress sites are:
- Slower
- More susceptible to traffic-spike sluggishness
- And very vulnerable to attacks
What We Do to Your HTML to Make it Faster on Static
Again, we take your pages and convert them to static HTML. While we have them we …
Generate Critical, Above-the-Fold CSS
In short, this just means the styles needed to render the first load are inlined.
Like all of this view:
This is done by extracting them from the Stylesheet and putting them high up on the page.
Some Themes Already Do This
Some Themes and site builders are already equipped to do this, and have said critical inline CSS present when we touch the page.
We auto-detect it and make sure we aren’t conflicting with that.
Defer and Combine ALL Stylesheets
So, because we’re already rendering all the above-the-fold, first-page-load styles, we don’t immediately need all the other stylesheets.
Most pre-made, and builder, Themes like Divi and Elementor will drop several CSS stylesheets right above the fold. Sometimes upwards of five or more.
This means on page load, the browser has to download and deal with those before loading the page.
This will tank Pagespeed Score results pretty quickly.
Our Feature Handles Them More Gracefully
- We auto-read all stylesheets
- We combine them into a single stylesheet (to reduce all of those requests)
- We minify the code (for faster loading)
- And then we tuck it somewhere where it won’t block page rendering
Rest assured though, those styles will beat you to your first scroll so you won’t even notice.
Lazyload Images
Another big Pagespeed wrecker is not lazyloading images.
We auto-detect and do this automatically to <img> and style background images.
Key Point Here
You don’t want to lazyload everything.
- It’s key that above-the-fold elements are not lazyloaded.
- In fact, we need to handle those differently entirely.
Which brings us to our next point.
Auto Preload First (3) Images on Page
While reading your HTML during static conversion, we auto-detect the first (3) images on the page by reading said HTML.
These images are marked to not be lazyloaded.
To take it a step further, we embed those image files in the <head> with preload tags so they are available as fast as possible to enhance first contentful paint.
Sometimes Auto-Detection Isn’t Enough
In some cases, critical above-the-fold resources might be embedded in a Stylesheet.
Yes, they’ll be there in Critical CSS, but we can’t otherwise find them to preload. If this is an important asset, we need to account for this.
So, we added an area to specify these on the page editor in WordPress.
Defer Scripts and Delay Them Until First User Interaction
Scripts can be one of the biggest page-load render blockers in the game.
In 99% of cases, scripts aren’t required until the user has started interacting with the page.
- We auto-detect all inline and embedded scripts
- We change their HTML so they only load on first interaction
- We preserve their ordering and other tags for proper load order and deference
Although our detection method for handling scripts during Static conversion was written entirely in-house with complicated regexing, we do want to give credit where credit is due:
- Under the GNU GPL v2 license, we utilize a modified version of WP Rocket’s lazyload script for getting those lazy loaded inlines and embedded scripts rendered.
We love WP Rocket, and we still support it on Headless Hostman, but we ran into a lot of issues capturing optimized pages during conversion. And they unfortunately denied a partnership collaboration, so we had to turn in-house.
All of This is Done on Static Generation
By assigning this optimization activity to Static Generation, we are making sure your WordPress experience is uninterrupted.
No caching. No force-reload activities. No waiting around.
And is Served on Static WordPress
And of course, these optimizations are then served by Static WordPress.
No Other Static Generator Does This
As of now, we’re the only Static WordPress Generator, and Static WordPress host, that converts and optimizes your HTML.
Don’t believe us? Check out the other guys:
ready to get started?
Headless Hostman takes the best of both traditional CMS systems and other static host providers to create a site that is both easy to manage, fast, and secure.