User experience: the new ranking factor

It’s rare for a search engine like Google to release details on how it’s highly guarded ranking algorithm works, but they’ve done just that. 

At the beginning of May 2020, the Chrome dev team announced Core Web Vitals. It’s a set of metrics and tools to help business owners, marketers and developers to measure user experience signals and identify opportunities to improve the user experience (UX) of their websites. 

There was more to come. A few weeks later, Google released an article on its webmaster google blog, “providing an early look at an upcoming search ranking change that incorporates these page experience metrics.” And it announced plans to “introduce a new signal that combines Core Web Vitals with our existing signals for page experience to provide a holistic picture of the quality of a user’s experience on a web page.” 

It’s long been rumoured that Google already used some UX metrics, like bounce rate and CTR, as ranking signals, but until now there was nothing definitive. We now know just how important it is to give the best UX to our site visitors and how we need to do it.

Is this a case of Google giving website owners a helping hand following the world wide disruption caused by COVID-19? Or is it simply making sure it’s providing the best possible experience for its users? 

Whatever the motive, Google is giving us a head start on optimising our sites ready for the update. Sites which don’t meet high experience standards will undoubtedly be hit with a penalty or ranking drop in the future. So take note – it’s coming sometime in 2021.

What is UX anyway?

In Google’s eyes, ‘user experience’ differs slightly from the term as it is understood by UX professionals. In this case it’s less about visual design and layout and more about what a page does to give users its experience (e.g. speed and security). 

The page experience ranking algorithm consists of several pre-existing Google search ranking factors dating back to 2014 and includes refined metrics around speed and usability (i.e Core Web Vitals). More about that later.

• Mobile-friendly update (April 2015), 
• Page Speed Update (July 2018), 
• HTTPS ranking boost (August 2014),
• Intrusive interstitials penalty (January 2017),
• Safe browsing penalty (November 2016)  

The new metrics and pre-existing factors, allow Google to better understand how a user will perceive the experience of a specific web page. It considers things so as how quickly a page loads, whether it’s mobile-friendly, if it runs on HTTPS, the presence of intrusive ads and if content jumps around as the page loads.

Miss any of these goals and a web page may be deemed to have a ‘bad’ page experience and will be ranked accordingly. Fortunately, there is help at hand, as Google has already gone to the trouble to detail calls Core Web Vitals.

Taking care of your ‘Core Web Vitals’

Core Web Vitals are real-world, user-centred metrics gathered from your webpages. They give scores on aspects of your pages including load time, interactivity and the stability of content as it loads. 

The page scores fall under these metrics: 

Largest Contentful Paint (LCP): measures loading performance.

An important user-centric metric used to measure the perceived load speed. LCP marks the point in the page load timeline, when the page’s main content is likely to have been loaded. A fast LCP helps reassure the user that the page is useful. To provide good user experience, LCP should occur within 2.5 seconds of when the page first starts loading.

First Input Delay (FID): measures interactivity. 

Measures how long it takes a page to become interactive and/or responsive. To provide good user experience, pages should have an FID of less than 100 milliseconds.

Cumulative Layout Shift (CLS): measures visual stability. 

Focuses on how much your page moves around when it’s loading. Ideally, there shouldn’t be any movement and to provide good user experience, pages should maintain a CLS of less than 0.1.

Here’s an example of CLS:

How to optimise for user experience

The ‘user experience’ update is an overarching theme that sits at the top of many past updates such as the HTTPS ranking boost in 2014, as well as 2017’s mobile-friendly update and the Page Speed Update in 2018. They must be covered off as a prerequisite. 

How to optimise your Core Web Vitals

Once you’ve taken care of past updates, you should move on to Google’s new Core Web Vitals. 

To help you, Google has recently updated its search console with the Core Web Vitals report. This allows webmasters and owners to see which pages within your site are missing their targets and will help you to validate any fixes. 

LCP

The LCP metric reports the render time of the largest content element that is visible within the viewport window. Google feels that once the biggest part of the page has loaded, the page is at its most useful to the user. 

Here are some of the most common causes of poor LCP times:

Slow server response times

The longer it takes a browser to receive content from the server, the longer it takes to render anything on the screen. A faster server response time directly improves every single page-load metric, including LCP. Before anything else, improve how and where your server handles your content. Use Time to First Byte (TTFB) to measure your server response times. 

You can improve your TTFB in a number of different ways:

• Optimise your server
• Route users to a nearby CDN
• Cache assets
• Serve HTML pages cache-first
• Establish third-party connections early

Render-blocking JavaScript and CSS

Most WordPress sites – such as the one you’re on now – use a theme and plugins that add JavaScript and CSS files to the front-end of your website. These scripts can possibly increase your site’s page load time, and at the same time, block a page from rendering.

This happens because web browsers will load scripts and CSS before the remaining HTML on the page. This means that users on a slower connection or mobile network will have to wait a few milliseconds more to see the page. It all adds up to bad user experience.

These scripts and stylesheets are referred to as ‘render-blocking’ JavaScript and CSS. To fix the problem, try to use fewer plugins and reduce the amount of JavaScript and CSS files used.

Slow resource load times

We know that an increase in CSS or JavaScript-blocking time will have a negative impact on performance and that the time it takes to load many other types of resources can also affect paint times.

For example:

• <img> elements
• <image> elements inside an <svg> element
• <video> elements (if specified, the poster image is used to measure LCP)
• An element with a background image loaded via the url() function (as opposed to a CSS gradient)
• Block-level elements containing text nodes or other inline-level text elements

If rendered above-the-fold, the additional time it takes to load these elements will have a direct effect on LCP, adding precious milliseconds.

There are a few ways to ensure these files are loaded as fast as possible:

• Optimise and compress images
• Preload important resources
• Compress text files
• Deliver different assets based on the network connection (adaptive serving)
• Cache assets using a service worker

Client-side rendering

As frameworks like React, Angular, and Vue have made it easier to build single-page applications, many sites use client-side JavaScript logic to render pages directly in the browser.

However, if large JavaScript bundles are used when optimisations aren’t in place, users may not see or be able to interact with any content on the page until all the critical JavaScript has finished downloading and executing. This will have effect LCP.

Consider the following optimisations when building a client-side rendered site:

• Minimize critical JavaScript
• Use server-side rendering
• Use pre-rendering

To learn more about optimising for LCP, take a look at: https://web.dev/optimize-lcp/

First Input Delay (FID):

The main cause of poor FID is heavy JavaScript execution. So by optimising how JavaScript parses, compiles and executes on your web page, you can directly reduce FID, pulling back time and giving an overall better experience to users.

Remember, the browser cannot respond to most user input while it’s executing JavaScrip, which means that it also can’t respond to user interactions while the main thread is busy. 

To try and improve this you could:

• Reduce JavaScript execution time
• Break up Long Tasks
• Optimize your page for interaction readiness
• Use a web worker

To learn more about optimising for First Input Delay (FID), check out: https://web.dev/optimize-fid/

Cumulative Layout Shift (CLS)

As we know, CLS measures the instability and movement of content by measuring and scoring how a page layout shifts while it’s rendering. It looks at how much visible content shifted in the viewport window as well as the distance the elements impacted were shifted:

The most common causes of poor CLS are:

• Images without dimensions
• Ads, embeds, and iframes without dimensions
• Dynamically injected content
• Web Fonts causing FOIT/FOUT
• Actions waiting for a network response before updating DOM

To learn more about optimising for Cumulative Layout Shift (CLS), go to: https://web.dev/optimize-cls/

The final countdown

The new ranking signal won’t be going live till sometime in 2021 and Google promises to give six months notice before it does so. This allows you time to check your Core Web Vitals reports to determine what needs addressing, page by page. Fail to do so and your Google rankings could suffer. 

Further reading …

Here’s some Core Web Vitals tools which might help you:

• Lighthouse in DevTools is now at version 6.0
• PageSpeed Insights incorporates the new metrics
• New Chrome User Experience Report API lets you access up to 28 days of historical data for your URLs
• Experience section in DevTools Performance panel
• Search Console’s new Core Web Vitals report for a summary of how your site performs
• Web Vitals Chrome Extension for quick access to metrics from the browser