User-centric metrics are the most important factors in success. This blog will provide you with some advice for best practices when it comes to improving these user centric metrics.
Over the last several years, Google has made a strong push for webmasters to make their sites more user-friendly by emphasizing site speed as a key factor.
I’m not simply referring to the little ranking improvement that comes with faster site performance. Take a look at the new resources, material, and tools that Google is releasing to assist developers in making their sites faster:
- web.dev – Accessibility, best practices, and performance improvement guides
- A solution that used user-centric performance measurements to provide improved pagespeed information
- WebP is an image format that is smaller than regular jpeg and PNG files.
- Guess.js — Page prefetching based on machine learning
- On developers.google.com, there are detailed speed improvement recommendations.
- AMP (Accelerated Mobile Pages) is a contentious mobile performance enhancement methodology.
- Brotli is a Gzip compression enhancement.
On top of that, significant businesses like Cloudflare are driving the web ahead by making these sorts of things easy to install, and mainly for free, on their edge server network.
We’re living in a golden period for page performance optimization, with more information being shared than ever before and implementation becoming more straightforward.
What’s more, why should you care?
Proper page performance optimization has a tremendous influence on organizations. According to recent studies, reducing page load times from 5.7 seconds to 2.4 seconds might more than treble your conversion rate.
Does increasing income from your website by three times its current level seem interesting to huge enterprises with lofty goals to meet? Obviously, it does!
Run your homepage through this Google tool to examine the possible effect site performance improvement may have on your site. Once your site has been analyzed, there is a useful competition analysis tool as well as a revenue projection tool that calculates the possible revenue gain if speed is improved.
So, if you’ve already done the fundamentals in terms of site speed optimization (Gzip compression, browser caching, good hosting, and so on), and you’re searching for some more advanced advice on how to boost site performance, you’ve come to the correct spot.
I’ll show you some more methods to profit from site speed optimization beyond the fundamentals, with an emphasis on increasing user-centric performance indicators and the essential rendering route.
What are user-centric performance measurements, and what do they mean?
I strongly advise you to read Google’s paper on user-centric performance metrics. The metrics we’ll be looking at are those present in both the updated PageSpeed Insights and Google’s Lighthouse tools.
And, if you’re wondering, what is the crucial rendering path?
The steps that a browser takes to render and show information on a web page are referred to as the crucial rendering route.
If you’re not sure what the important rendering route is, I strongly advise you to read the following articles:
When it comes to site performance optimization, it’s crucial to concentrate on the key rendering route. You’re doing it all wrong if you’re optimizing page load time rather than user-centric metrics assessed by technologies like Lighthouse.
For example, if a website takes six seconds to load but the visitor can view and interact with it in one second, that’s not too awful.
From the user’s viewpoint, if a page loads in six seconds but the user can’t see any content or interact with the page until five seconds have gone, that’s quite bad.
That’s a rather far-fetched analogy, but you get the idea. By concentrating on the perceived load times, which is all that counts to a user, you may optimize the essential rendering route.
Now for some pointers on how to make your pages load faster.
Optimizing a File
Render-Blocking Files Must Be Removed
One of the finest things you can do to optimize the essential rendering route and important metrics like your First Contentful Paint is to remove render-blocking files (FCP). Put this at the top of your to-do list if there’s one area you wish to improve!
What exactly is render-blocking?
When externally connected JS and CSS (cascading style sheets) hinder the browser from completing parsing the HTML and presenting the user the page’s content, this is known as render blockage.
When a browser parses HTML and discovers externally linked CSS and JS files, it stops reading HTML and begins requesting, receiving, downloading, and parsing those resources. The page will stay blank until these files have been downloaded and processed.
This may result in significant delays, particularly when the CSS or JS download sizes are big.
There are three key stages to resolving this issue, which are outlined below:
1. Critical CSS inline
The first thing you want to do to fix this is to inline any critical CSS in the <head> of the page. As you may have guessed, critical CSS is the CSS that is required to show above the fold content to the user.
When this CSS is inlined at the very top of the page in the <head>, the browser will parse it and then apply it to any HTML it finds before reaching a render-blocking file.
Visit web.dev for additional information.
2. CSS that isn’t essential is deferred
We need to delay any CSS that isn’t essential for displaying above-the-fold content now that vital CSS has been loaded.
To do this, use the rel=preload property to load CSS (cascading style sheets) in a little different manner than normal.
<link rel=”preload” href=”styles.css” as=”style” onload=”this.onload=null;this.rel=’stylesheet’”> <noscript><link rel=”stylesheet” href=”styles.css”></noscript>
The preload property makes CSS load asynchronously, whereas the onload attribute makes CSS load after the page has done loading.
WARNING: Do not attempt this unless your important CSS has been inlined beforehand. You’re going to receive a FOUT if you don’t (flash of unstyled content)
Bonus tip: If your browser doesn’t support the preload attribute yet, you can use the loadCSS library to JS polyfill it. Although browser support is growing, Firefox is the only browser that does not presently support it.
3. Postpone non-essential JS
Next, we need to address any JS that is stopping the browser from rendering content. A browser’s default behavior while loading JS is as follows:
By postponing JS, the browser’s behavior takes on a more familiar shape:
It’s as easy as adding the word ‘defer’ to the tag.
<script defer src=”example-script.js”>
If you have a tiny JS file that is required for page loading, try inlining it in the same way you would with crucial CSS.
4. Add Render-blocking Files to the Tag’s End
Now, to make sure that any externally linked CSS (cascading style sheets) do not block the rendering of content move your non-critical CSS (cascading style sheets) to the very end of the page just before the closing the </body> tag.
This is also something I advocate for your delayed JS files. While this shouldn’t affect current browsers that support the defer property, certain older browsers don’t and may load the JS in a render-blocking manner as a result.
5. Remove any CSS that is no longer in use.
An obvious way to improve Optimizing a File is to remove anything that is not ever actually used. CSS is one of the major culprits for this where CSS (cascading style sheets) are loaded globally across the site even though the CSS may not actually be required on that page.
On an ecommerce site, for example, CSS for the checkout page should not be loaded on the home page.
How can I detect CSS that isn’t being used?
I personally like to utilize Chrome Dev Tools to locate wasted bytes in files. Open Chrome Dev Tools (CMD + ALT + I on Mac) and go to the Coverage report.
Click the record button and reload your website once you’re in there.
After that, you’ll get a lovely visual representation of the proportion of waste in each file you’ve loaded on the website.
Unused CSS Removing Tools
There are a number of services that will optimize your CSS so that it only contains the information that is necessary on that page:
Keep in mind that this should be done page by page and with a lot of testing. The majority of tools will provide you with clean CSS (cascading style sheets) that only apply to what it found inside the DOM when it was examined. After that time, if you inject more HTML into the DOM, such as a popup, the CSS to style that popup will not be included inside the clean CSS file.
6. Make Font Icons Look Better
Designers and developers may now give life to their websites even if they don’t have outstanding looking iconography thanks to font icon packages.
There are, however, workarounds!
Using a site like Fontello or Fontastic to create your own icon font files is my personal preferred approach. These sites make it as easy as dragging and dropping the SVG or web font files you desire to the site, producing the font files, and then uploading them to your own site to create your own icon font files.
After you’ve done this, you’ll only be utilizing the font icons that your site really uses, which means consumers will see speedier load speeds.
7. Fonts for the Web Should Be Optimized
Custom typefaces are becoming more popular on the internet. Making a site look fantastic with your own typography is getting a lot simpler thanks to free font libraries like Google Fonts and commercial choices like Adobe Fonts (formerly dubbed Typekit).
Unfortunately, if fonts are sluggish to load, they may break the essential rendering route, particularly if they are loaded from a third-party server that may be slower than your own.
FOUT (flash of unstyled text) and FOIT (flash of unstyled text) are two examples of unattractive circumstances (flash of invisible text). This is when the browser displays your backup system default fonts before entirely loading the font, leaving the text unstyled, or it waits for the font to finish downloading before showing anything.
If you’re thinking about the crucial rendering route in FOIT, you could have noticed a problem.
When we wait for a typeface to completely download before showing it to users, the perceived load time increases dramatically since the user will see an almost blank page until it has finished loading.
Unstyled text isn’t ideal when using FOUT, but at least the user sees something! The distinctions between FOUT and FOIT, which are chosen by default by each browser, are as follows:
- For up to three seconds, Chrome conceals text. Then, until it’s ready, it utilizes a system typeface.
- For up to three seconds, Firefox conceals text. Then, until it’s ready, it utilizes a system typeface.
- When the custom font is ready, Edge employs a method to change out the fonts.
- Until the custom font is available, Safari conceals all text on the page.
Thankfully, there are techniques to override the default behavior while simultaneously optimizing your web fonts.
Here’s a wonderful resource for learning how to optimize web fonts. But, in a nutshell, here’s what you should be doing:
- Set the font-display property to switch using the font-display property. This tells the browser to show an unstyled font right immediately, which speeds up the essential rendering phase. More information may be found here.
- In the <head> of the page at the very top, preload your fonts. This tells the browser to start loading the font straight away, reducing the time that the user will see unstyled fonts.
- Because various browsers prefer different fonts, we must list all fonts and then use the format element to provide resource clues.
- If you’re using a CDN, consider self-hosting your fonts so you can control how quickly they load and aren’t hindered by a slower third-party hosted font. To check how it affects loading, use lighthouse reports or the network tab in Chrome Dev Tools.
- Consider employing a Cloudflare worker to automatically self-host Google Fonts on the fly if you’re using Cloudflare.
- Take a look at this plugin if you’re using WordPress. It will host Google fonts for you, as well as preload, prepare, and implement the font-display attribute. Simple!
8. Image Enhancement Techniques
One of the most significant factors influencing page size is images. Reducing the total size of the page is an excellent strategy to improve the essential rendering process.
Unfortunately, high-resolution photography and large banners have traditionally slowed down page load times, particularly on mobile devices with slower 3G or 4G connections.
WebP pictures, produced by Google WebP, lower image file sizes by around 25–35 percent on compatible browsers, however I’ve personally witnessed even smaller reductions. It makes sense to do this if you have an image-heavy ecommerce site since it will save server bandwidth utilization while also making the site load quicker.
You may use the Node.js library explained here or Google provides a selection of WebP conversion libraries that you can use on your site to convert photos to WebP.
The main problem with WebP is that it isn’t supported by all browsers. If you merely start utilizing WebP images site-wide for browsers that don’t support it yet, everyone using an unsupported browser will receive blank pictures… It’s not perfect!
The solution? The <picture> tag! Again, in the great CSS tricks article, you can find how to use this tag to support browsers that do and do not support WebP.
SVG is a scalable vector format (meaning the quality remains the same regardless of size), it’s fast, and it can even be animated!
You should anticipate file diagrams, logos, and drawings to be substantially smaller when using the SVG format; you can learn more about it here. Given the popularity of bespoke graphics in design, SVG should be part of your web development arsenal.
Do you want to see how powerful SVG is? Visit the Stripe website; they’re used all around.
Examine some of your schematics, logos, and images. If they aren’t already in SVG format, have them converted so that the page size is reduced.
Images to Load Slowly
This is perhaps the most apparent, and it’s something that a lot of websites are already doing (and Chrome will soon support it by default!).
Given the size of pictures, it’s best to load them just when they’re needed, such as when the image is visible in the browser viewport.
Lazy loading does this. Only the photos at the top of the page will be loaded when the page loads. They will load as the user scrolls and additional photos come into view. Easy to use and effective! Read Google’s documentation and use a framework that makes use of the Intersection Observer API.
It’s a more performance-friendly method of lazy loading, with the extra benefit of being supported by Googlebot’s latest upgrade.
9. Opt for a Better DNS Service
Improving DNS lookup timings on your own site is an excellent method to increase all user-centric speed metrics’ load times since it is the first thing that must happen when the page opens.
If you’re still utilizing your hosting provider’s default DNS, you’re losing out on a huge chance to optimize the essential rendering route.
Cloudflare is my go-to DNS management service. It is the quickest DNS service available, has a fantastic admin area, and is completely free. Take a look at DNSPerf if you need some assistance choosing a better DNS service; it will show you which is quicker.
Remove any animations that are above the fold.
Web design is increasingly using animations. That’s fantastic! When implemented effectively, they may enhance the user experience and improve the overall browsing experience.
When items fade in above the fold, however, all of your hard work optimizing the essential rendering route is thrown out the window. Even with a short 0.3–0.6s transition time, if you’re fading or sliding in an element above the fold, you’ve simply delayed your first major paint by that much.
This tip is quite straightforward: don’t animate crucial material above the fold. Users will want to view the material immediately rather than wait for a beautiful animation to load.
11. Prefetching of resources
What is prefetching, and how does it work?
Prefetching is a technique for informing a browser about resources that will be utilized later. When a resource is prefetched, the browser saves its contents in a local cache. When a user requests the resource, it is provided from the browser cache, which speeds up page loading and rendering.
When we spoke about font load optimization, we described one prefetching approach (called preload).
What can you do with it?
Prefetching may be used for a variety of purposes, including:
- A DNS lookup is a procedure for determining the location of a domain name.
- Web pages in their entirety
- CSS (cascading style sheets)
- Any kind of media files (fonts, audio, video, images, etc.)
Prefetching resources may be done in a variety of ways. Here’s a quick rundown of the distinctions between the two:
- The DNS lookup for the following page is performed by Preresolve.
- Preconnect It does everything of the above, plus the TCP handshake and optional TLS negotiation.
- Prefetch also makes an HTTP request, which is handy for pictures and other files since we can tell the browser that a certain image should be loaded first on the current page.
- Prerender Prerendering enables you to load a document as well as all of its resources. Prerender.io is not to be confused with prerender.io, which is a separate sort of prerendering!
Check out this CSS Tricks post for additional information on the various methods of prefetching.
Prerendering for Faster Load Times
In this section, we’re going to be specifically focusing on how to implement prerender, here is an example of what the code looks like that you need to add the <head> of your site:
<link rel=”prerender” href=”https://www.example.co.uk/example1″>
Prerender is an excellent tool to have in your site performance optimization toolkit since it allows you to make page load times seem nearly instantaneous to the user. Because the browser has already completely loaded all assets to load the page before the user has browsed to it, this occurs.
All you have to do is forecast which page they will click next and then begin prerendering that page before they click it.
While this is clearly beneficial in terms of load times, it must be utilized with prudence. If you start prerendering a lot of URLs, you’ll soon waste a user’s data plan and server resources, particularly if the user never went to the URL in the first place.
A prerender approach may be implemented in a variety of ways:
- ‘Shortly-in-time’ prefetching — When a user hovers over a link just before clicking, you start prerendering a page. When a user lingers over a link, it takes around 300–400 milliseconds for them to actually click it. So, while the user hovers, you may start prerendering the following URL. You may then increase user-centric metrics by a little amount while also making your page load times seem instantaneous if you’ve done additional optimization.
- Predictive prefetching — This is when you use past data on what people tend to click on after browsing a page to determine what they should do next. For instance, you could do this using Google Analytics data. We can start loading a certain category page in the background if a user visits the home page and then goes to a specific category page.
- Idle prefetching – You could prefetch all linked to URLs inside a user’s viewport while the user’s browser is idle.
Addy Osmani deserves credit for his prediction fetching suggestion.
Fortunately, there are a few different tools you can utilize to get started with the prerender feature right now.
Use Instant.page to implement Just-in-Time Preloading.
With a tool called instant.page, you can quickly build a just-in-time preloading technique. Adding the script to your website is all it takes to get started.
Guess.js Predictive Prefetching
Use Quicklink to implement Idle Prefetching.
Quicklink is just another fantastic free product from the Google team. Once again, setup is fast and easy.
Quicklink makes an effort to speed up navigating to future pages. It:
- Within the viewport, it detects links (using Intersection Observer)
- Waits for the browser to be idle (using requestIdleCallback)
- Checks if the user is connected to a sluggish connection (using navigator.connection.effectiveType) or has data-saving turned on (using navigator.connection.saveData)
- Prefetches URLs to the links (using <link rel=prefetch> or XHR). Provides some control over the request priority (can switch to fetch() if supported).
Personally, I like this technique of doing prefetching since it takes into account the user’s network as well as if they have data-saver turned on.
There’s also a WordPress plugin you can use to get this running on your site; just install it and you’re good to go!
Cloudflare Edge Caching is a service provided by Cloudflare.
Although I am a great supporter of Cloudflare, you may notice that your TTFB (time to first byte) decreases when you use the CDN.
This is due to Cloudflare’s default policy of not caching HTML on the edge. When a user accesses a page on your site, Cloudflare sends a request to your server for the page’s HTML.
Your TTFB may be delayed by roughly 100ms as a result of this. You don’t want a slower TTFB since it comes before all of our other user-centric measures, including first significant paint and first contentful paint, which will be delayed as well.
If you don’t use any form of HTML/page caching on your origin server, the problem becomes considerably worse.
With the cache everything page rule, Cloudflare does provide HTML caching (or page caching). After you’ve done so, Cloudflare will start caching the origin’s response HTML until it’s purged, thereby eliminating latency between the origin and Cloudflare.
You could use the cache everything page rule to put rules all across your site, and then use other page rules to change the cache level to ‘bypass’ for more dynamic pages like your site admin section.
Consequences of Dynamic Elements
However, there are several situations in which this will not work. If you have a dynamic ecommerce site with dynamic components like the cart, header, checkout, and account pages, Cloudflare will display visitors whatever they have cached, eliminating the dynamic nature of these pages/sections. In the worst-case situation, visitors will start viewing other users’ basket and account pages!
There are workarounds available. One option is to use AJAX to load these dynamic items client-side. WooCommerce is a wonderful illustration of this, since the bulk of the cart components are all AJAX-based. If you use this, Cloudflare will send the HTML to the user, but the browser will work with the origin server asynchronously to populate dynamic sections of the site.
If this isn’t the case, you’ll need to either establish a user cache or skip the edge cache based on a cookie that indicates whether or not the user is logged in.
Most CMS, thankfully, offer a cookie that you can utilize to avoid the cache; an example of this for WordPress may be seen here. The bad news is that since this is a business plan feature, it will cost £200 a month to use (along with other great features).
Using a Cloudflare Worker to Get Around It
You may, however, use Cloudflare workers to get around this.
Here’s an example of a worker that can help you with this. It also includes a WordPress plugin that adds support for HTTP headers, which the worker uses to determine whether or not the cache should be bypassed.
When combined with some of the essential rendering route optimizations discussed in this article, you should notice considerable reductions in load times.
Hopefully, you’ll be able to take some of the above suggestions and put them into action on your site to enhance performance and conversion rates. While there are many things you can do to increase site performance beyond the essentials, after you’ve done them plus some of the above, you should see a big improvement.
If you have any queries, please leave them in the comments section below or send me a tweet at @SamUnderwoodUK.