Are you running a WordPress website but tearing your hair out because of its slow speed, response time and long page load times?
Do you want to improve your Google rankings and keep more users on your site by increasing your speed?
Read on for answers to these pressing issues.
You will learn the exact techniques, optimizations and plugin settings that helped NetMagnet.cz increase its Google PageSpeed Insights score from 59 to a beautiful 93 (out of 100).
For example, on our homepage, which was the slowest of the entire site, we managed to improve the immediate abandonment rate by a relative 8.5%. (The increase in page views is also nice, but it is not due to a mere increase in speed.)
Why are we dealing specifically with WordPress? Because it’s the most popular content management system, powering over 40% of all websites on the planet, but it’s also the slowest by various measures (at least compared to other popular systems). It can take long seconds to load a simple page in it, especially if you buy a “super cool” template from the WordPress template marketplace, in which you clip the whole site and add a bunch of plugins. But we’ll get to that…
Table of Contents
- Why does slow WordPress reduce profits?
- Our WordPress speed optimization
- Other options for optimizing WordPress speed
Why does slow WordPress reduce profits?
According to an analysis of 10 billion visits to major e-commerce sites, it was found that:
- A 100mspage load time slowdown can reduce conversion rates by 7%.
- Slowing down by 2 seconds increased the instantaneous abandonment rate by 100%.
- When the page didn’t load within 3 seconds, 53% of users ran out of patience and closed the page.
Google did a similar experiment where a 0.5 second slowdown in loading a search results page reduced traffic by 20%.
Conservative results came from Walmart, where a 1-second increase in page load time increased conversions by 2%.
Slowness of a website kills not only conversions but also SEO.
In the last few years, Google has officially announced that it will take page load speed into account for ranking search results from May 2021.
A fast website will bring not only higher conversions, but also higher traffic. How does Google measure site speed?
Meet Core Web Vitals
To help web developers really start optimizing their work for speed, Google has defined speed metrics called. Core Web Vitals. These measure the perceived speed of a site quite realistically and are therefore critical to a good user experience. You can easily measure them either in Chrome via Lighthouse or (more easily) via Google PageSpeed Insights, or they can also be found in Google Search Console.
Sites with good results in these 3 metrics should be prioritized by Google in search results.
Largest Contentful Paint (LCP)
He’s measuring the loading. More precisely, the loading time of the visually largest element “above the fold” (on the 1st screen after loading the page without scrolling down). That is, e.g. the opening image, the title, the longest paragraph – in short, whatever takes up the most screen space after the page has fully loaded. For a good user experience (green from Google), this largest element should load within 2.5 seconds.
Be careful not to confuse this metric with First Contentful Paint, which measures the time to load the first content. In the figures below, it is referred to as FCP.
First Input Delay (FID)
It measures interactivity, which means how long it takes for a page to process a user interaction. That is, for example, how long it takes to respond to a button click , a form checkbox check, etc. A delay of up to 100 ms is considered good interactivity.
You can’t measure this metric directly in Google PageSpeed Insights / Lighthouse because it is not repeatable and stable to measure (lab). However, the Total Blocking Time (TTB) metric correlates well with this metric and can be measured in the lab via Google PageSpeed Insights / Lighthouse.
Cumulative Layout Shift (CLS)
Measures visual stability. Content may scroll down as the page loads, which is undesirable for the user. Typically this happens when loading images, but also fonts, etc.
I’m sure you know. You open a page, you want to quickly tap a button. You flick your mouse and stretch your finger. But just before your finger hits the mouse, an ad pops up above the button, and you tap the ad instead of the button, and you’re in a completely different place than you wanted to be.
Or you’re reading a page, and as the large images load, the text goes gradually down.
A good user experience is provided by a CLS below 0.1, which means, for example, that no more than 30% of the page area moves in total by 10% of the screen height. See the CLS documentation for a detailed calculation.
Our WordPress speed optimization
WordPress also powers our website netmagnet.cz. We cannot deny the fact that it is a nice way to manage content. Working with images is practically unrivalled among open source content management systems. However, we couldn’t put up with the slowness of WordPress anymore, so we set to work to start optimizing the speed.
How did we measure site speedup?
After each change, we measured the Google PageSpeed score for mobile (more strict than for desktop) directly through this online tool (not Lighthouse in Chrome) to minimize the influence of the local computer on the speed measurement. We measured the score of our homepage – before and after status. We repeated the measurement several times and chose the average result. The repeated measurements differed sometimes by up to 7 points, so we need to take the results with a slight margin.
For internal comparison, we also measured the speed of the static subpages of our Services website. The scores were consistently about 2-5 points higher.
So how did we optimize the speed of WordPress?
1. Change of web hosting
The netmagnet.cz website was running on Wedos. Previously, we used to host the almost cheapest WordPress on this hosting, but we have sobered up from these efforts. It’s not worth the few tens of CZK a month we save.
We have launched an identical copy of our website netmagnet.cz on the new Hetzner web hosting. With this hosting we have only fresh but good experience. Both the original site and its copy on the subdomain used the same DNS servers and ran on HTTPs, so that the webhosting itself remained virtually the only speed factor.
Result of speed optimization
Comment
- The difference in score was virtually unmeasurable. Sometimes the new webhost came out better, sometimes worse.
- In terms of feel, however, the web has become significantly faster. The website on Wedos sometimes suffered from glitches, page loading sometimes “stuck” for 10-20 seconds, on the new hosting we have not noticed anything like that even in 3 months of operation.
- On the new hosting, the speed of administration has increased several times.
2. Deploying the PageSpeed Mod
PageSpeed Insights is used to measure site speed. But the PageSpeed mod is also called a module for Apache or nginx web servers, which can “automagically” increase the speed of a website. It is also developed by Google. Mod PageSpeed takes the HTML code that the site would normally send to the browser, but modifies it a bit beforehand. It performs various compression, caching, etc., and thus can increase the loading speed of the site quite substantially.
It has about 40 filters(see examples) that can be switched on or off after setting. We used the following:
recompress_images– replaces images referenced in HTML code with their optimized variants. Among other things:- converts jpeg to modern webp format (preserves compatibility in code by fallback to progressive JPG)
- minify png, jpg, webp
- converts gif to png
inline_images– inlines critical images that should be displayed above the fold (in the 1st screen after the page loads)convert_png_to_jpeg– convert PNG to JPG will ensure smaller size and will be done only if the image is not sensitive to noise and does not have transparent pixelscollapse_whitespace,remove_comments– delete unnecessary whitespace and comments
Turning on the filters is very simple, in the case of Apache just write in the .htaccess file:
<IfModule pagespeed_module>
ModPagespeed on
ModPagespeedEnableFilters recompress_images
ModPagespeedEnableFilters inline_images,convert_png_to_jpeg
ModPagespeedEnableFilters collapse_whitespace,remove_comments
</IfModule>The PageSpeed mod can e.g. minify and merge JavaScript and CSS, improve cachability, automatically lazyload images, etc. See examples.
For an ideal setup, however, you need to know what you’re doing. Some optimizations can even slow the site down or make it less user-friendly in certain situations. For other optimizations, the Pagespeed Mod is short again (e.g. response time, images in CSS).
However, the above filters should help in most cases.
Result of speed optimization
Note
The PageSpeed mod is unfortunately not common to every web host. No regular web host we’ve ever worked with offers it.
But fortunately, our web hosting, which we offer only to Net Magnet clients, offers Mod PageSpeed support and we can happily optimize the speed 🙂
3. Autoptimize plugin
The previous change of hosting and PageSpeed will work for any website, but now let’s optimize WordPress directly.
There are many plugins that optimize the speed of WordPress. We consider W3 Total Cache to be a staple and had it installed before this experiment. We achieved the next level of speed with the Autoptimize plugin. We consider these 2 free plugins to be the best and complement each other appropriately.
Autoptimize optimizes JavaScript, CSS stylesheets, HTML code and images to download this data to the browser as quickly as possible and display the page to the user as quickly as possible. The plugin optimizes similar things to PageSpeed, but does more thanks to its integration into WordPress.
If you also install the plugin, you need to set what it should optimize. Beware, turning everything on indiscriminately can even slow down WordPress! We’ve turned it on:
Autoptimize plugin settings
JavaScript
Default settings up to ⬜ Aggregate JS-files? It is important to load some JavaScript files that affect web rendering quickly, others can wait. That’s why we don’t want to merge them. Moreover, on the HTTP/2 protocol, merging files doesn’t help much (and can be counterproductive).
CSS and Critical CSS
Although CSS style merging alone shouldn’t be as necessary due to good HTTP/2 support, without ✅ Aggregate CSS-files some other optimizations cannot be enabled. These in aggregate increase the PageSpeed score by several points.
Critical CSS styles prove to be crucial for fast loading of a web page (and Core Web Vitals metrics). These are the fewest possible styles that can render the page above the “fold” – i.e. the visible part of the page without using a scroll – in the most complete graphic possible. Typically, these styles are the header, main title, main image, and first part of the page content – simply those elements that the user wants to see as soon as possible.
These critical styles are placed at the beginning of the page’s HTML code so that the browser can load them as quickly as possible and use them to render the page. A full CSS file with all the styles for all the subpages takes orders of magnitude longer to download and display (we’re talking hundreds of milliseconds) and isn’t even needed for a rough load of the 1st screen.
Critical CSS styles don’t have to be written manually. The easiest and free way to get them is with tools like Critical Path CSS Generator. You enter a page into it, the tool will render it and determine the CSS styles needed to display the section above the fold.
Autoptimize also offers automatic and continuous generation of critical CSS, which is an ideal option, but you have to pay for this extra service. Or you have to manually generate critical CSS styles for each page and place them as high as possible in the HTML header.
HTML and Misc
✅ Optimize HTML Code removes unnecessary white space. It saves a few bytes and shouldn’t bother anyone, but you should test it.
The other options have been left in their default state. We don’t use CDN because it is a paid service and our website doesn’t need it at the moment.
Images
On the next tab Images we enabled ✅ Lazy-load images?, which causes images to be downloaded to the browser when they are supposed to be displayed to the user, instead of the classic way of loading the page. Although the PageSpeed Mod can also do automatic lazy-load images, we let Autoptimize do it in the end.
Result of speed optimization
Note
Autoptimize helped significantly improve the Time to Interactive, Largest Contentful Paint, First Contentful Paint, and Speed Index metrics. However, due to critical CSS styles, some pages had errors that needed to be addressed in the next step.
4. Manual image editing and other optimizations
Neither the Autoptimize plugin nor the PageSpeed Mod optimize images in CSS. That’s why we have created much smaller .webp variants to all images in CSS styles, which we serve to the browser instead of the original images, if the browser supports this modern format. We detect webp support thanks to the Modernizr library.
We further optimized:
- .htaccess file – setting of caching static images and documents in the browser using
ExpiresByTypedirectives. - Extracting non-essential JS from HTML code to external JS with lower priority.
- Add
rel="preconnect"andrel="preload"attributes for Google Fonts. - Fixed minor problems in the web display caused by previous optimizations.
Result of speed optimization
Note
Core Web Vitals metrics have remained the same and Total Blocking Time has gotten worse, however I would see more of a measurement variance as the cause here. We are still in the green zone.
You can optimize the web almost indefinitely. But to increase the speed further, we would have to, for example:
- Dig deeper into WordPress and re-write some of the slow functions (e.g. menu listing).
- Recode parts of the site, especially the header where the menu and language switcher loads.
- Overall, limit calls to the database and manually cache the results.
- Optimize the size of the main CSS styles.
- Use hosting with nginx instead of Apache.
- etc. etc. etc.
But beware of the interpretation of metrics. Only results taken at similar times can be compared to each other. For example, the results of the current test of netmagnet.cz came out slightly worse than a few months ago, when we did the optimization and measurement, although we did not change anything on the website. The difference in measurements may be due to:
- changes on shared web hosting and its variable load
- the method of calculating Core Web Vitals and PageSpeed metrics, which has changed significantly in the past
- temporarily worse availability of embedded third-party scripts
- updating the display kernel of the speed measurement tools
- etc.
Other options for optimizing WordPress speed
What other optimizations do we recommend that just weren’t part of this experiment?
W3 Total Cache
As mentioned above, we have had the W3 Total Cache plugin installed for a long time and it is not part of this test. I only list it for completeness, so that you don’t forget about it (or any other caching plugin) when optimizing.
What are caching plugins like W3 Total Cache good for? WordPress when loading more complex pages (e.g. product list, article list, …) has to reach into the database for data, link it with other data, sort, format, etc. All this can slow down the page loading. However, when the data doesn’t change much, we don’t have to retrieve and reassemble the data each time, but can save the finished result. And this result ready for fast serving to the browser is called cache. The cache is valid until the original data changes or some time has elapsed.
According to our experience, an otherwise unoptimized WordPress on an average hosting can be significantly faster thanks to a caching plugin. North response time (time to first byte) of normal pages can be reduced from 800 to 250 ms. Take the numbers with a grain of salt. You may get more speedup, but sometimes none, or even the site may slow down. Also, sometimes the cache may not cache properly, so then the page loads fast, but with old data. Test and measure!
Precise coding / fast template
Fast hosting and optimization plugins can be useless if WordPress is running on a badly coded template with a lot of plugins, which kills the agility completely. We have experience with multiple purchased templates with PageSpeed scores in the 0-9/100 range.
Cool visual effects can fool you, as they are quite often accompanied by the slowness of the web. It’s best to test your template through Google PageSpeed Insights and don’t buy those with a score below 50. On your hosting the score will quite possibly be even lower and even a value around 50 without optimizations is nice.
On the other hand, a website coded correctly can achieve a decent PageSpeed score even without accelerating plugins. And as you can see, after relatively simple optimizations you can achieve ideal scores.
