These slides were presented at the SEMrush webinar "SEO Bytes with Nitin: Conquer web vitals & everything around site speed for great UX/SEO". Video replay and transcript are available at https://www.semrush.com/webinars/seo-bytes-with-nitin-conquer-web-vitals-and-everything-around-sitespeed-for-great-ux-seo/
2. Table of content
Table of Contents
1. The Growing Importance of Speed in SEO
2. Google’s Page Experience Update
3. An Introduction to Web Vitals
4. What You Can Do to Prepare
4. You can learn a lot by keeping an eye on
what tools and external comms Google is
investing in.
5. Speed Update Rolls
Out for Mobile
Rankings
9th July 2018
Page Speed Used in
Desktop Rankings
9th April 2010
Google’s Test My
Site Tool Updated
25th February 2019
Google Search
Console Rolls Out
Speed Report
4th November 2019
PageSpeed Insights
Incorporates CrUX
Data
12th November 2019
Core Web Vitals
Launched
5th May 2020
Page Experience
Update Announced
28th May 2020
A snapshot of Google’s activity around site speed over the last 10 years:
7. Page experience is “a set of signals that
measure how users perceive the
experience of interacting with a web
page beyond its pure information value.”
8. • There is a new page in the Google Search documents on Google Developers
dedicated to ‘page experience,’ which sits alongside key topics like indexing,
JavaScript and mobile-friendliness.
• The page experience algorithm update will be released in 2021.
• We will be given 6 months notice before it rolls out.
• We will have work to do. Google only pre-announces updates and provides
information like this when there are specific things we can improve. Remember
mobile-first indexing?
What We Know About
Page Experience So Far
9. Query relevance is still key for ranking,
but page experience will determine
rankings for sets of pages with similar
informational value.
12. The 3 Most
Annoying Things
About Websites
Interactivity Visual StabilityLoading
Experiencing a never-ending
loading wheel, or a blank
page which slowly populates
with different tiles, like a very
slow and painful virtual jigsaw
being pieced together before
your eyes.
Seeing the thing you want
right in front of you and
clicking on it, with no
response. And then endlessly
clicking in the vain hope that
something might eventually
happen.
Going to click a button and
the screen shifts at the last
minute and you end up
clicking on a new thing
instead, then you have to go
back to find the thing you
actually wanted.
13. Web Vitals is “an initiative by Google to
provide unified guidance for quality
signals that, we believe, are essential to
delivering a great user experience on the
web.”
14. • Core Web Vitals are three metrics that help us to measure the user’s
experience of a page as it loads; not just objective load times.
• These will focus on three key areas of UX: loading performance, interactivity
and visual stability.
• They will be annually updated to cover even more elements of user experience
that are not yet being measured, such as smoothness and privacy.
What We Know About
Web Vitals So Far
15. Web Vitals are a quantifiable way of
measuring user experience, this is why
Google has chosen them.
16. • First contentful paint (FCP): measures the time when any part of the page's
content is rendered on the screen.
• First meaningful paint (FMP): measures the time when the primary content is
visible, which is usually the hero content. (This has been replaced with LCP in
Lighthouse.)
• Largest contentful paint (LCP): measures the time when the largest text block
or image element is rendered on the screen.
• Time to Interactive (TTI): measures the time when a page is visually rendered,
its initial scripts (if any) have loaded, and it's capable of reliably responding to
user input quickly.
• First input delay (FID): measures the time from when a user first interacts with
your site to when the browser is actually able to respond.
• Total blocking time (TBT): measures the total amount of time between FCP
and TTI where the main thread was blocked for long enough to prevent input
responsiveness.
• Cumulative layout shift (CLS): measures the cumulative score of all
unexpected layout shifts that occur between when the page starts loading and
when its lifecycle state changes to hidden.
Key User-centric Speed
Metrics to Measure
28. FCP tracks the rendering of the initial DOM content, but not the most important
content. This is where LCP comes in to track the loading of meaningful content.
• Improve server response times and reduce TTFB. Utilising CDNs, link
rel=“preconnect” and caching static resources can help here.
• Optimise render-blocking resources like JavaScript and CSS. Defer loading of
any non-critical resources and minify code to reduce main thread blocking.
• Reduce the file size of resources like images. Implementing compression,
caching and CDNs can work well.
• Prioritise the loading of critical resources by using link rel=“preload”.
• Minimise client-side rendering by using server-side rendering or pre-rendering
where possible.
Optimising for LCP
(Largest Contentful
Paint)
Render your main content faster
29. FID can’t be simulated with lab data, as it requires real user input to test
interactivity and responsiveness. TBT can be an indicator of FID.
• Reduce the amount of heavy JavaScript execution. Reduce main thread
blockages by minifying, compressing, code-splitting and deferring JavaScript.
• Analyse third-party scripts in terms of main thread usage and defer loading of
non-critical ones like tracking tags below-the-fold.
• Test interactivity of server-side rendered content as pixels can be painted
before re-hydration on the client side occurs and interaction is possible.
Optimising for FID (First
Input Delay)
Respond to user interactions faster
30. CLS measures how much visible content shifts within the user’s viewport, and to
what extent, rather than being a timed metric.
• Specify image and embed dimensions with the ‘width’ and ‘height’ attributes, or
use a CSS aspect ratio box to block out the required space. This is important
to assess on responsive sites which often leave this out.
• Assign static space to ad spaces, push non-sticky ads below the viewport and
add placeholders to reserved spaces rather than collapsing empty ones.
• Avoid inserting new dynamic content above existing content unless this is in
response to user interaction. This includes pop-ups and interstitials.
• Reduce layout shifts caused by FOUT/FOIT by using font-display and the Font
Loading API.
Optimising for CLS
(Cumulative Layout
Shift)
Avoid sudden layout shifts
32. • JavaScript: Audit JavaScript bundles, implement code splitting, use
asynchronous loading, combine external files for fewer requests.
• Web Fonts: Compress web font files, self-host fonts where possible, match
fallback fonts to main ones, use font-display to avoid FOIT, use rel=preload for
key fonts.
• Code File Size: Minify code, reduce the number of on-page resources, use
concatenation, utilise text compression.
• Images: Compress images, specify image dimensions, use the srcset attribute,
use a CDN for image-heavy websites, lazy-load non-crucial images.
• Redirects: Avoid client-side redirects, audit existing redirects on the server and
CMS, implement a responsive design to reduce redirects required, check all
file types for redirects including images, JS and CSS files.
The Biggest
Contributors to Page
File Size & Download
Times