The fastest loading, top ranking sites on the internet have some of the worst Google PageSpeed scores I've ever seen.
If that's not testimony to the fact that Google PageSpeed, YSlow and other scores are meaningless, then nothing is.
Knowing how to use these tools properly can really be of benefit in optimizing your site for users as long as you never fall into the trap of optimizing for score.
Load is not a single moment in time — it’s an experience that no one metric can fully capture. There are multiple moments during the load experience that can affect whether a user perceives it as "fast" or "slow".
W3C (paint timing spec)
The most critical (and the first) speed test you should ever perform is to inspect, with your own eyes, how your site loads for humans.
Thereafter, you can use website speed test tools to tweak things that optimize the user perception to the max.
While a first paint may introduce some formatting and colors, users aren't interested in looking at your site's header and an otherwise blank screen. They want content. And they want it fast. The best way to meet that criteria is to stop chasing scores and concentrate on the things that make a real difference to the way that users perceive the loading experience.
There are many factors to consider, the most important of which are to ensure that your hosting is tip top, that you're using a properly coded and optimized theme (I can't stress the importance of this enough) that loads resources in the correct order so as to eliminate FOIT and FOUT while providing a smooth and seamless user experience.
If you feel the urge to perform speed tests (using Google PageSpeed Insights, GTMetrix or Pingdom), which I'll concede is very tempting if not impossible to resist, I'll show you exactly what to concentrate on in order to best optimize your WordPress site for speed. It's definitely not scores!
Heck, here's how the Google developers site performs in their own testing tool for mobile devices ...
and for desktop devices.
Need I say more?
Knowing How To Read And Interpret Google PageSpeed Insights vs Pingdom vs GTMetrix Tests?
It doesn't take a rocket scientist to realize that Google PageSpeed Insights is, for the main part, score driven. While the tool does make some meaningful recommendations for optimizing load times, some of them are just way too generic (and incorrect) to apply while others are insufficiently described and/or impossible to control.
A test like this can seem intimidating but on closer inspection it's apparent that some of the recommendations are incorrect and not applicable. Much depends on the site's configuration and what's really necessary to load it properly. Clearly Google PageSpeed Insights can't determine these smaller intricacies.
Some of the problems with this test are the inability to read the .htaccess file (my .htaccess file does contain expires headers) and the recommendation to add an expires header to Google's own analytics script. It's not possible to add expires headers to external resources.
Lastly, you never want fallback text to render for an icon font because you never know what may be rendered. There is no fallback text for icon fonts.
Pingdom provides an actual speed result, a waterfall and some written suggestions, some of which are also hopelessly incorrect.
The tool is fickle in that it is able to read an .htaccess file in about 50% of tests. For the remaining 50%, it provides incorrect suggestions. Moreover, a previous test reflected incorrect load order of resources in the waterfall.
It's worth noting the way that Pingdom determines load time. Knowing that my contentful paint times in GTMetrix range from 200ms to 500ms, I have every reason to believe that Pingdom's load time indicates the contentful paint time- certainly not fully loaded time.
GTMetrix is probably a better tool to judge the outcome of many different metrics but also not without its faults. It's fraught with inconsistency leaving users wanting to pull their hair out in desperation, not knowing which test results to rely on and which not!
I'll talk about metrics in greater detail shortly, save to say that a GTMetrix test provides, among other things, a detailed waterfall together with scores/ grades extracted from Google's PageSpeed Insights and Yahoo's YSlow.
What's nice here is that the tool provides a fully loaded time while the waterfall is useful enough to determine the load order of HTTP requests being made, what they are and the time it takes to load the resources.
The timings tab shows various timings which I'll discuss in detail shortly, the most important of which are time to first byte and contentful paint time which is indicative of perceived load time.
Reducing HTTP Requests - A Misnomer
In their endeavor to prove their efficiency and usefulness, website speed test tools will invariably tell you to reduce the number of HTTP requests as is evidenced in recommendations such as combining scripts and CSS files.
But reducing requests doesn't necessarily affect perceived speed. That depends on the order in which the resources are loaded.
Take Forbes for example, a site that not only dominates Google SERP but is also one of the largest on the internet.
The number of requests certainly affects the fully loaded time but as you'll discover shortly, that is irrelevant because users don't require all resources to load immediately as long as they have enough to interact with the site when it starts loading.
Of importance is that the contentful paint time remains super fast at 469ms and if you judge the site based purely on loading it in your browser you'll have to admit that the perceived load time is ultra fast.
Website Speed Test Tools Don't Account For Modern Web Technologies And Score Based Optimizations Are Therefore Flawed
By their very nature, website speed test tools must be generic. Considering the millions of sites that reside on the internet, each built using different themes and configurations and hosted on many vastly different platforms, it's just not feasible to build an individualized testing tool.
It's understandable, therefore, that Google PageSpeed score may be incorrectly determined due to factors that don't apply to your particular website, additionally flagging incorrect suggestions. Sad but true!
Take for example a situation where score is reduced due to uncombined HTTP requests (e.g. JavaScripts and CSS files) when in fact the server technology is based on the HTTP/2 protocol which allows for multiplexing and parallel file downloading which negates the need for concatenation.
Similarly, incorrect flagging by Google PageSpeed Insights, GTMetrix and Pingdom occurs when suggesting the removal of resources from the render blocking path when, in fact, the HTTP/2 protocol again allows for multiplexing and parallel downloading of such files. (This is exactly why WP Rocket specifically advises against concatenating resources on HTTP/2 enabled servers).
Optimizations based on reducing the number of HTTP requests bears little relevance where HTTP/2 is at work. With HTTP/2, servers are able to push resources to your browser without the need for individual requests, improving speed in the process.
But conversely, a caveat that must be considered carefully is browsers that don't support HTTP/2. Such browsers fall back to the HTTP/1 protocol and if you have users that have not yet caught up with modern browsers, you best not neglect the old style optimizations.
I would suggest you determine carefully where your users are coming from and what technology they are using. You can see this in Google analytics but caniuse.com has the ability to evaluate your analytics in order to check what kind of technology your users are browsing with.
Yet another ridiculous suggestion is the addition of expires headers to external resources (such as externally called fonts and Google Analytics script) over which you have no control.
Taking things further, scoring based on image compression in respect of images that have already been optimized to their maximum is just ludicrous. Any further compression would be akin to a person of 20/20 vision being prescribed spectacles of -2 diopter.
And to kill user experience altogether, the mere thought of lazy loading images is laughable.
Then there's also the score based suggestion based on the leveraging of browser caching. I mention this with a caveat because this is actually a very useful optimization for repeat visitors (discussed further on), however it doesn't affect visits to a site for the first time, with the main problem lying in the fact that, firstly this is not always clarified properly and secondly penalizing score based on short expires headers for assets that must always remain updated, is absurd!
So attempting to improve score based on such flawed assumptions will likely prove a complete waste of time and effort, with some of the suggestions possibly improving fully loaded time (which is unnecessary) but will never improve what matters most for users - perceived performance.
Understanding The Important Metrics And How To Apply Optimizations That Make A Real Difference To Speed
Contrary to what many believe, the fully loaded time of a site is relatively unimportant - within reason.
The WP Engine site is a classic example.
Being in the hosting business, this site is highly optimized. But to the uninformed it may look like a poor performer.
I mean 24.6 seconds is a long time to wait for a site to load and I think I'd be quite safe in assuming that any user who had to wait that long for content would have long since moved onto the next site.
The reality, however, is that the site becomes usable in 1.3 seconds.
To clarify, content becomes visible in above the fold content in 1.3 seconds as can be seen from the contentful paint time. In the background, however, there are a number of processes that continue to run but are not immediately required for visitors to start interacting with the site. This is a classic illustration of perceived load time in action.
So let's understand how all of this actually works.
Time To First Byte (TTFB)
TTFB is the time it takes for the browser to receive the first byte of information after a request for a website is made and is often referred to as server response time.
Because content cannot be rendered without the necessary data, TTFB is a key performance indicator.
Now there are some optimizations we can make to improve TTFB:
- Hosting that provides great web server technology - The WordPress speed optimization guide concurs that hosting is the #1 factor that affects speed. And TTFB is directly dependent on great hosting. Sure, caching and some other optimizations may help a little, but getting to the root cause of slow server response requires that you address your hosting. Type 2 diabetics take all sorts of oral and intravenous medications that generate huge profits, literally keeping big pharma companies in clover! In the majority of cases though, these meds are just a band aid. They give people a reason to continue eating badly (which fuels profits even further) when, in fact, addressing what goes down the gullet can literally "cure" the condition. The same goes for WordPress speed optimization. If you want to fix website speed, you must address the root cause. The Cloudways stack is one of the best around. It combines the stability of Apache in the front with the Speed of NGINX at the back and sandwiches Varnish cache in between to create ultra fast hosting with the benefit of dedicated resources.
- Using the most recent PHP version - PHP 7.x is considerably faster than it predecessor. Again, your hosting provider needs to support this.
- Caching - After hosting, caching static content will considerably improve TTFB. I also recommend server side caching such as Varnish and Redis. As mentioned already, Varnish is built into the Cloudways stack (and can be disabled if need be). Redis caches database queries in memory thereby speeding up database calls. It works in a similar manner to memcached. Redis is a free addon offered by Cloudways.
- Offload assets to a CDN - If you decide to use a CDN, I would suggest Stackpath (ex Max CDN). If you host with Cloudways, their free Breeze cache plugin integrates seemlessly with their own CDN (which is actually Stackpath). Just to clarify something important - Cloudflare (not Cloudways) is not a true CDN. While they do distribute content to multiple edge servers in their network, your entire domain is cached as opposed to individual assets being offloaded to a CDN server. Personally, I was able (in the past) to reduce TTFB with the use of a Cloudflare "cache all" rule (because it caches dynamic content) but it's not something I'd suggest. Presently I only use Cloudflare for their DNS hosting.
- Don't concatenate CSS files - Something else I've found (that may or may not apply to your setup) is that concatenating CSS files increases TTFB times. While it may reduce requests, I've found that it comes at the expense of TTFB and contentful paint time. Bear in mind that I use a Genesis theme which can't be beaten in terms of lightweight coding and quality and Cloudways is also HTTP/2 enabled. The only way to tell whether concatenation works for you is to test, test, test.
- Remove or dequeue unnecessary CSS - I have found that TTFB can be reduced considerably by loading only the CSS that is essential for your site. Take this site for example. I use Beaver Builder because Gutenberg doesn't allow me to create certain formatting that I like. But WordPress now includes the Gutenberg editor in its core code and all the hooked Gutenberg CSS was, by default, being loaded on every page of my site. Removing this added weight improved TTFB and contentful paint time. If you don't use Gutenberg, add this code to the end of your functions.php file to dequeue it.
//Remove Gutenberg hooked css
add_action( 'wp_enqueue_scripts', function() {
wp_dequeue_style( 'wp-block-library' );
} );
So, does TTFB make a difference to load time? And SEO?
You bet!
As mentioned already, the sooner that data can be transferred between server and browser, the faster the rendering will be.
Furthermore, Google only looks at TTFB in it's ranking algorithm so if you want to ensure you aren't "marked down" in SERP, aim for TTFB under 200ms.
TTFB on this site is a cool 121ms, tested from Dallas USA.
The best way to optimize TTFB is to ensure that your server is fast.
Unfortunately, you have no control over server speed if you host on a shared server.
The best way to ensure highest server speed is to host in the cloud.
I switched from Siteground to Cloudways not only because of speed but also because Siteground’s renewal fees are just obscene for shared hosting.
Cloudways gives you dedicated resources and a choice of over 60 data centers (depending on which cloud infrastructure you use) for a fraction of the cost!
Review Signal collect regular conversations on Twitter and turn them into meaning reviews. Their cloud hosting review places Cloudways in second spot.
I trust Review Signal above all other reviews because their data comes from totally unbiased and benign conversations on Twitter where users are not trying to sell anything.
Sign Up with PROMO CODE: WPMM25OFF for 25% off your first 2 months hosting fees if you decide to host with Cloudways.
First Paint Time
First paint time is the time it takes for the browser to paint the first pixel and render anything on the page.
Because each site is different, it is impossible to determine exactly what is represented with the first paint. It could be a background color, including plain white, a header or even text.
Due to this, a speedy first paint time is not indicative of a quick loading page.
Contentful Paint Time | First Meaningful Paint
This indicates when users receive any form of interactive content from the DOM. It could be text or media, as opposed to a state change (background color or styling).
Contentful paint time or first contentful paint (FCP) is indicative of perceived load time (perceived performance) - the point at which users believe the site has fully loaded.
On well optimized sites it can be common for contentful paint time and first paint time to coincide.
Optimize the following to improve first contentful paint:
- Caching - cache static HTML pages to improve speed for first time visits and leverage HTTP caching (browser caching) to vastly improve speed for repeat visits.
- Optimize the render blocking pathway as much as possible - this doesn't mean that you have to eliminate all resources from the pathway because some render blocking resources may be necessary for smooth and effective page loading!
- Minify HTML, CSS and JS where possible.
- Minimize payloads and remove unnecessary JS and CSS calls - I mentioned unnecessary CSS removal further up. The same applies to JavaScript. If you have calls to unused scripts, comment them out or dequeue them depending on your theme setup. Developers can consider code splitting and/or tree shaking opportunities. Code splitting involves breaking up JS into bite-sized chunks and delivering only the script needed at the time it's required. Concatenating small JS files can be effective in optimizing the render pathway but for large files, you'll need to test to determine efficacy. That being said, WP Rocket provides an ideal solution whereby JS can be concatenated (even large files such as JQuery) and then deferred. Tree shaking involves the removal of parts of the script that may no longer be used. You need to know a fair amount about coding in order to use this technique. Compression is pretty much superfluous when it comes to resource processing. While file size is smaller in respect of file transfers, once decompressed the parser still has to process the full uncompressed code.
Dom Interactive Time
The Document Object Model (DOM) is how the browser structures the page's HTML internally so that it can perform the rendering process.
It is at this point that the HTML has been fully loaded and processed (parsed) and indicates the time immediately preceding when the user agent sets the document readiness to interactive. (Thanks to Patrick Sexton - Varvy for the great description).
Although the HTML has been parsed, other resources such as JS and CSS haven't been dealt with yet. That occurs in the next step.
Dom Content Loaded Time
At this stage, DOM interactive has been achieved and there is no CSS blocking the execution of scripts.
Developers often use this as a starting point to execute JavaScript. It stands to reason, therefore, that a delay in DOM loaded time can delay rendering and it is for this reason that the parsing of JavaScript should either be deferred or loaded asynchronously.
A good caching plugin will be able to defer script at your request.
Onload Time
Don't mistake this for fully loaded time.
Onload occurs when all resources for the page have been fully downloaded.
It can happen though, that a certain script initiates a call for additional resources.
This is why there's a difference between Onload time and Fully Loaded time.
Why You Should Concentrate On Optimizing Above The Fold Content
The term "above the fold" (ATF) is derived from newspaper headlines and content that remain visible when the paper is folded for public display on news stands.
The same concept applies to websites except that the term refers to the content that is displayed on a device without having to scroll.
It's the content that's designed to hook or engage your user, making it the most important piece of content on your page.
So it makes sense to ensure that this primary real estate loads quickly and efficiently.
But what exactly are the most crucial aspects to consider when optimizing for above the fold content (critical rendering path)?
- Eliminate or optimize render blocking resources.
- Eliminate Advertising.
- Optimize or eliminate images.
- Eliminate FOIT and FOUC while ensuring visibility of text during loading.
Eliminate Or Optimize Render Blocking Resources
- CSS - There's no disputing that render blocking CSS slows down your site. To alleviate this you can minify CSS files which removes all white space and unnecessary comments thereby reducing file size. This can be followed up with combining separate CSS files into a single file (merging or concatenating). This will reduce the number of HTTP requests and round trips required to render the page and should theoretically improve loading times. However, this also depends on your individual setup. Combining large CSS files could have the opposite effect so it's imperative to test what works effectively. Lastly, printing the critical CSS (needed to render above the fold content) into the head of your HTML document makes it available during the parsing process without the need for a separate request, thereby clearing the render blocking pathway and theoretically speeding up load times. Again, test this strategy on your own setup.
- Google Fonts - Being called by CSS, Google fonts are typically render blocking. To exacerbate matters further, calling the external CSS file using the @import method (which is normally found right at the beginning of the HTML document) causes the browser to make a round trip in order to look for and fetch the file thereby delaying rendering. It's better to use the standard method to call Google fonts using
<link href="https://fonts.googleapis.com/css?family=yourfont&display=swap" rel="stylesheet">in the head of the HTML document. When grabbing the link from Google fonts, you'll notice that &display=swap is added by default to the string, emphasizing Google's position regarding the importance of a proper font loading strategy to augment above the fold optimization. You may want to consider hosting your Google fonts locally but doing so requires fast and reliable hosting. Please don't attempt to host fonts on a shared hosting platform.
- Google Fonts - Being called by CSS, Google fonts are typically render blocking. To exacerbate matters further, calling the external CSS file using the @import method (which is normally found right at the beginning of the HTML document) causes the browser to make a round trip in order to look for and fetch the file thereby delaying rendering. It's better to use the standard method to call Google fonts using
- JavaScript - The reason JS is render blocking is because most sites call external JS files from the <head> of the HTML document. And in most instances, these JS files are not required to load the above the fold content. JQuery is a particularly large file and is oftentimes responsible for blocking the critical render path due to it being prematurely called. This is not the only culprit, though. Google recommends two very effective ways to handle the calling of JS without blocking the parsing of HTML.
- Using the async attribute on external scripts. Async causes the script to be loaded in parallel with the parsing of HTML and it therefore doesn't block rendering.
- Defer the loading of external JS files (that are not required to render above the fold content) to the end of the HTML document (just before the </body> tag). Defer causes the script to be executed after the page has finished parsing.
Sound complicated?
It is! But there's a simple way to achieve all of this without you having to do any heavy lifting yourself.
Eliminate Advertising
Personally I'd never monetize my site with ads. I find they interfere with user experience and are highly distracting for users at the best of times.
If you must have ads on your site, don't include them in the above the fold area. Ads are slow to load at the best of times and including them above the fold will have a negative impact on contentful paint times and more importantly, user experience.
Optimize Or Eliminate Images
Pixel based graphics are problematic in that the larger the image, the more pixels they use, giving rise to increased file size.
The larger the file size the slower images will load leading to increased paint times and poor user experience. So it stands to reason that the use of images above the fold comes at the expense of speed and user experience.
I'm not saying don't use them at all, just that they ought to be very well optimized.
But what if I told you that there is, however, an image format that is not resolution dependent and will load faster than standard raster graphics such as jpg and png?
Well there is. And this may be a great alternative if you absolutely must include images above the fold.
Scalable Vector Graphics (SVG) defines graphics in XML format and are recommended by W3C since 2001 and have many advantages over other common image formats such as jpg and png.
SVG images can be created and edited with any text editor
SVG images can be searched, indexed, scripted, and compressed
SVG images are scalable
SVG images can be printed with high quality at any resolution
SVG images are zoomable
SVG graphics do NOT lose any quality if they are zoomed or resized
SVG is an open standard
SVG files are pure XMLw3schools.com
Here's an example of an SVG graphic ...
And here's how it was inserted into the page.
<!DOCTYPE html> <html> <body> <svg height="210" width="500"> <polygon points="100,10 40,198 190,78 10,78 160,198" style="fill:lime;stroke:purple;stroke-width:5;fill-rule:evenodd;"/> </svg> </body> </html>
Eliminate FOIT
When it comes to loading webfonts, neither FOIT nor FOUT / FOUC are desirable. And which one of these evils is the lesser, is (personally) subjective.
Without intervention, popular browsers allow 3 seconds for webfonts to load before reverting to nominated fallbacks or system fonts, meaning that users on a slow connection may ultimately be subject to both. Eek!
Since May 2019, Google have been including the &display=swap property in their <link href ...> URL.
This means that font display during loading will default to fallback / system fonts until such time that the preferred font has been downloaded and is ready for use, where after it will replace system fonts (FOUT).
I would be inclined to assume, therefore, that Google's preference for FOUT as a means to keeping text visible during loading clearly confirms their preferred position. To support this, font visibility during loading is flagged and reflects in Google PageSpeed score when performing an Insights test.
I'm also of the opinion that non compliant sites will fall out of favor in Google SERP (if not immediately then ultimately).
For those who host fonts locally, the font-display property (with various preferred values) is also available for use with the @font-face descriptor when calling fonts from a local stylesheet.
Yes, the use of font-display: swap may translate to users (depending on certain factors) seeing fallback / system fonts until preferred fonts become usable during the loading process, but I would have to concede that this is probably better than forcing FOIT upon them.
There may be those who will try to dissuade you from keeping text visible during loading and motivate this on the assumption that fonts should be render blocking in order to avoid FOUC. But in my opinion that comes at the HUGE expense of your users' perception as those on sub-optimal connections are forced to wait on a blank screen (FOIT) until the parsing of CSS makes way for the HTML render.
Yikes! What a terrible compromise.
Provide Instant Loading For Repeat Visitors.
Ever notice how a previously visited site loads almost instantaneously?
Browser caching ensures that specific resources (e.g. fonts, images, scripts) are stored on the user's machine for a time specified in the expires headers. These expires headers live in your site's .htaccess file and instruct browsers to retain certain assets for a specified time, after which they expire.
This means that a browser making repeat requests for a site doesn't have to wait for those assets to be downloaded repeatedly from the server allowing them to be loaded from the browser's cache / store / memory.
Browser caching provides the fastest possible load times for users as the site loads mainly from their local machine.
[As an aside, browser caching translates to reduced server requests, lower resource (and bandwidth) usage and reduced hosting costs for those on cloud or similar hosting plans].
You can add expires to your .htaccess file manually or even better with a good caching plugin.
Use the following code to add expires headers manually to .htaccess. The expire times will be suitable for most sites but you can alter these according to your own preference.
<IfModule mod_expires.c> ExpiresActive on ExpiresDefault "access plus 1 month" # CSS ExpiresByType text/css "access plus 1 year" # Data interchange ExpiresByType application/json "access plus 0 seconds" ExpiresByType application/xml "access plus 0 seconds" ExpiresByType text/xml "access plus 0 seconds" # Favicon (cannot be renamed!) ExpiresByType image/x-icon "access plus 1 week" # HTML components (HTCs) ExpiresByType text/x-component "access plus 1 month" # HTML ExpiresByType text/html "access plus 0 seconds" # JavaScript ExpiresByType application/javascript "access plus 1 year" # Manifest files ExpiresByType application/x-web-app-manifest+json "access plus 0 seconds" ExpiresByType text/cache-manifest "access plus 0 seconds" # Media ExpiresByType audio/ogg "access plus 1 month" ExpiresByType image/gif "access plus 1 month" ExpiresByType image/jpeg "access plus 1 month" ExpiresByType image/png "access plus 1 month" ExpiresByType image/webp "access plus 1 month" ExpiresByType video/mp4 "access plus 1 month" ExpiresByType video/ogg "access plus 1 month" ExpiresByType video/webm "access plus 1 month" # Web feeds ExpiresByType application/atom+xml "access plus 1 hour" ExpiresByType application/rss+xml "access plus 1 hour" # Web fonts ExpiresByType application/font-woff "access plus 1 month" ExpiresByType application/font-woff2 "access plus 1 month" ExpiresByType application/vnd.ms-fontobject "access plus 1 month" ExpiresByType application/x-font-ttf "access plus 1 month" ExpiresByType font/opentype "access plus 1 month" ExpiresByType image/svg+xml "access plus 1 month" </IfModule>
That's All Folks ...
Well, that all I have for now. I hope you've learned something from this post.
If you know of something that I've left out in error, hit me up in the comments.
Do you think I've given you enough to realize that you should only optimize for users and never for Google PageSpeed score, YSlow score or any other score based optimizations?
Leave a Reply