In May 2020 Google is updating their search ranking algorithm to include their new “Page Experience” metric. In a rare and welcome twist, Google has signposted in great detail what goes into this new metric. After reading Google’s docs on “Page Experience”, I wanted to apply these new learnings to my personal website (findram.dev). The process of updating my site only took an afternoon! In this post I will show you the steps I took and the results!

Core Web Vitals

Google’s Page Experience metric draws from five signals: i) Core Web Vitals, ii) Mobile-Friendly, iii) Safe Browsing, iv) HTTPS and v) No Intrusive Interstitials. Points (ii) to (v) have been included in Google’s search rankings for a while now, so we will just focus on the new one: Core Web Vitals.

Core Web Vitals are a set of metrics for measuring the real-world user experience of visiting a website. The three current Core Web Vitals focus on: loading, interactivity, and visual stability. Web.dev have a fantastic series which explains each of the Vitals. Check it out here.

How do I benchmark my website’s performance?

We want to identify the lowest hanging fruit. The easiest way to do this is to test your website using a page-speed analyser. To test a site in production you can use the following tools:

• https://search.google.com/search-console — if you are the owner of the site
• https://developers.google.com/speed/pagespeed/insights/ — this includes benchmark and real-world speed data from real users

To test a site in development you can use the Google Chrome Lighthouse tool in Chrome Devtools (press F12 and select the “Lighthouse” tab).

I ran the Lighthouse tool on findram.dev before doing any improvements — The results for mobile are below. We will focus on mobile score, as it is the hardest to perfect (download speed and processing power are both inferior on mobile). FYI the performance score for desktop was 92.

Improving Core Web Vital #1 — Largest Contentful Paint 🎨

The easiest core web vital to improve— and potentially the most neglected is Loading. Not surprisingly, loading time has a big impact on bounce-rate (see Google ‘mobile page speed’ report). Fortunately, there is plenty of low hanging fruit to improve LCP, especially on mobile.

Here are the steps I took to reduce LCP, in order of decreasing impact:

1. Convert images to modern formats and compress to an appropriate size
   Modern image formats (like .webp) are used in only a tiny fraction of websites, even though their file sizes are 25–35% lower! I also discovered that many of my images were uploaded in high-res (1500x1500 pixels). This is wasteful, regardless of the file format…
   
   
2. Serve static and media files from a CDN (like AWS Cloudfront)
   Originally I was severing static images from the same webserver as the Django application. I know, I know, this is bad practice — but in my defense this entire website was a one day build.
   Now I am instead using `django-storages` to deploy and serve static and media files from AWS S3. I also setup an AWS Cloudfront CDN to cache and serve these assets from AWS edge locations. This means that visitors from Perth or London or New York will still be served images and media files from nearby locations, instead of from Sydney.
   
   
3. Serve static and media files using HTTP 2 instead of HTTP 1
   HTTP/1 has worked fine for 25 years. It’s problem is that it is an ordered and blocking protocol that allows a limited number of concurrent connections. This means that your browser might have to download batches of assets in sequence, rather than all at once.
   
   HTTP/2 on the other hand is fully multiplexed and non-blocking. Take a look at this demo to see the difference between the two. Interestingly, only around 50% of webservers currently use HTTP/2!
   
   If you use AWS Cloudfront, serving assets with HTTP 2 requires just changing one setting in your Cloudfront configuration!
   
   
4. Remove unused CSS and Javascript
   I found that this had only a small benefit for me. The main culprit was the bootstrap css stylesheet. Being in the <head> section of my HTML, it will block page rendering until the CSS file is downloaded. I experimented with moving the stylesheet into the <body> section, but this resulted in big Layout Shift due to CSS styles being applied after the first render.
   
   In truth, the optimal solution would be for me to remove bootstrap entirely. After all, I use only about 5 bootstrap classes in total, and I can easily define these styles myself in the critical CSS path.

Improving Core Web Vital #2— First Input Delay ⏳

First Input Delay measures the delay between when you click on something (like a link or a button), and when your browser responds to your action. A delay occurs when your browser’s main thread is busy doing something else, like executing all of your awesome Javascript.

Here are the steps I took to reduce FID:

1. Remove unnecessary third-party scripts
   In my case I discovered that I was loading jquery and popper.js even though I was not using them in any part of the website. Removing those gave a nice little speed boost.
   
   I found that the biggest culprit of FID was on findram.dev was the Google analytics script which would fire after the First Contentful Paint. But I see this as fair trade-off so I left it in.
   

Improving Core Web Vital #3 — Cumulative Layout Shift ⬇️

Websites with bad Layout Shift annoy the hell out of me. We all know that experience when you load a web-page and start reading, and then suddenly all the text jumps down the page because of an image loading above. At this point I usually just leave the site.

I recommend reading this awesome empirical study on CLS and outcomes (conversion rate, bounce rate, etc.).

Not surprisingly, CLS is a much bigger issue on mobile. I assume this is because the standard “stacked” responsive layout on mobile views causes layout shift to impact more DOM elements.

Also not surprisingly, CLS has a significant adverse correlation to bounce rate and session length. I find that using a grid layout in CSS mitigates the impact of CLS. Conversely floating CSS elements tend to make CLS more difficult to manage.

Here are the steps I took to reduce CLS:

1. Actually, none — The original CLS score for findram.dev was 0.01 … basically perfect 😇
   

The Results 🏆

The simple improvements above resulted in the Performance score for mobile increasing from 71 to 91. I’m fairly pleased with that!

FYI For desktop, it increased to 99!

One last note — Google really emphasises that perfecting your Core Web Vitals is still no substitute for good content. And of course this is true. Developers and designers should primarily concern themselves with creating enriching content and pleasing user experiences.

BUT nevertheless — if you have a spare afternoon, I recommend benchmarking your site and seeing where you can improve 😃