Improving performance by preloading fonts
and dequeuing render blocking stylesheets
Preloading fonts
I’ve listened to the Shop Talk Show for a number of years. On a recent episode about performance improvements with Ben Schwarz, my ears pricked up when Ben mentioned shaving three to five seconds off website load time by preloading fonts. The steps are very simple.
By taking these steps on our local development version of Butterworth Horticulture, we managed to decrease the page load time by five seconds on 3G (slow) and 0.77s on cable.
First test
Second test
What’s better is the second load time also decreased quite dramatically.
This means even after all the stylesheets, scripts and other rendering blocking resources are cached from the first page load, preloading fonts still decreases load time on further page loads. On our site it decreased from 1.01s to 0.53s. That’s half a second faster, for every subsequent page load.
If you’re thinking half a second doesn’t seem like like much, I encourage you to check out WPO stats, which is a great resource showing how much revenue can increase from even the smallest of reduction to load time.
We now plan to rollout these improvements to all our client websites.
Only load stylesheets you require
When a browser visits a website, it loads the HTML first and streams through it; selecting assets, based on priority. When analysing a site using Chrome’s Developer Tools Network performance tab, I noticed a stylesheet was being queued up that I didn’t recognise:
This is a WordPress stylesheet, used by the Gutenberg block editor. We’ve tried out Gutenberg, we like it and we have plans to use it in future, but we don’t use it on any existing projects. We use the Classic Editor plugin to restore the WYSIWIG editor.
However, even with this plugin active and the settings set to ‘Default editor for all users: Classic Editor’ and ‘Allow users to switch editors: No’, this stylesheet was still being enqueued. It’s a small stylesheet – only 4.5kb – but even though it says .min.css in the name, it isn’t minified and as a high priority resource it’s holding up the rest of the page from loading even though none of the styles from it will ever be used on our website. When a page is minified, it means stripping out all of the extra line breaks and white space characters, which make code human readable to work with. They all take extra bytes to send down the wire and process, so stripping out the files means it loads faster when processed by a computer.
@vguerrerobosch posted a comment on Gutenberg’s GitHub repository explaining how to dequeue this stylesheet. However this isn’t exactly foolproof. What if a user decides to include Gutenberg on some pages in future? Friend of Preface Studios and developer, Todor Gaidarov, wrote a few more steps in the code to check this for us.
We have submitted a suggestion to the Classic Editor plugin to implement this step. Hopefully, if this happens, all users who visit WordPress 5.x websites running Classic Editor won’t have to download and parsing a necessary stylesheet before they can view the content of the website.
Preloading fonts
I’ve listened to the Shop Talk Show for a number of years. On a recent episode about performance improvements with Ben Schwarz, my ears pricked up when Ben mentioned shaving three to five seconds off website load time by preloading fonts. The steps are very simple.
By taking these steps on our local development version of Butterworth Horticulture, we managed to decrease the page load time by five seconds on 3G (slow) and 0.77s on cable.
First test
Second test
What’s better is the second load time also decreased quite dramatically.
This means even after all the stylesheets, scripts and other rendering blocking resources are cached from the first page load, preloading fonts still decreases load time on further page loads. On our site it decreased from 1.01s to 0.53s. That’s half a second faster, for every subsequent page load.
If you’re thinking half a second doesn’t seem like like much, I encourage you to check out WPO stats, which is a great resource showing how much revenue can increase from even the smallest of reduction to load time.
We now plan to rollout these improvements to all our client websites.
Only load stylesheets you require
When a browser visits a website, it loads the HTML first and streams through it; selecting assets, based on priority. When analysing a site using Chrome’s Developer Tools Network performance tab, I noticed a stylesheet was being queued up that I didn’t recognise:
This is a WordPress stylesheet, used by the Gutenberg block editor. We’ve tried out Gutenberg, we like it and we have plans to use it in future, but we don’t use it on any existing projects. We use the Classic Editor plugin to restore the WYSIWIG editor.
However, even with this plugin active and the settings set to ‘Default editor for all users: Classic Editor’ and ‘Allow users to switch editors: No’, this stylesheet was still being enqueued. It’s a small stylesheet – only 4.5kb – but even though it says .min.css in the name, it isn’t minified and as a high priority resource it’s holding up the rest of the page from loading even though none of the styles from it will ever be used on our website. When a page is minified, it means stripping out all of the extra line breaks and white space characters, which make code human readable to work with. They all take extra bytes to send down the wire and process, so stripping out the files means it loads faster when processed by a computer.
@vguerrerobosch posted a comment on Gutenberg’s GitHub repository explaining how to dequeue this stylesheet. However this isn’t exactly foolproof. What if a user decides to include Gutenberg on some pages in future? Friend of Preface Studios and developer, Todor Gaidarov, wrote a few more steps in the code to check this for us.
We have submitted a suggestion to the Classic Editor plugin to implement this step. Hopefully, if this happens, all users who visit WordPress 5.x websites running Classic Editor won’t have to download and parsing a necessary stylesheet before they can view the content of the website.
Want us to improve the load speed of your bespoke website?
Share
