Core web Vitals: Web Performance and Usability

Cologne Web Performance Optimization Meetup #34
Core Web Vitals
Optimizing Speed and Usability
for Google's Core Web Vitals
Thanks to wao.io by Avenga for supporting the event!
Ingo Steinke
Creative Web Developer

Ingo Steinke
Creative Web Developer,
Web Performance Expert,
freelancer @ planted.green
co-hosting @cgnWebPerf
ingo-steinke.com
@fraktalisman

Core Web Vitals: Web Performance and Usability
“Web Vitals is an initiative by Google to provide unified
guidance for quality signals that are essential to
delivering a great user experience on the web. Core Web
Vitals are the subset of Web Vitals that apply to all web
pages, should be measured by all site owners, and will
be surfaced across all Google tools.”
web.dev/vitals/#core-web-vitals

What's new anyway?
Why the hype?
“Most performance advice is the same we already knew,
or should have known, unless we never cared about
usability and only ever optimized for Time-to-First-Byte?”

LCP: Largest Contentful Paint, FID: First Input Delay, CLS: Cumulative Layout Shift
TBT
Total Blocking Time

Measuring and Monitoring Web Vitals
● PageSpeed Insights
● Lighthouse
● WebPageTest
● GTMetrix
● Google Search Console

PageSpeed Insights:

Lighthouse:

Measuring Core Web Vitals: WebPageTest

Measuring Core Web Vitals: GTMetrix

Monitoring Core Web Vitals: Google Search Console

LCP: Largest Contentful Paint
● What does it measure?
● Why does it matter?
● How to optimize?

Largest Contentful Paint measures
interruptions due to waiting
From the user's point of view, loading a particular page doesn't represent a
natural break: they haven’t yet achieved their goal, which may make them less
tolerant of delays. The Largest Contentful Paint metric measures when a
page-to-page navigation appears complete to a user.
Aim to keep LCP under 2.5 seconds for 75% of page loads!
blog.chromium.org/2020/05/the-science-behind-web-vitals.html

Largest Contentful Paint (LCP) vs.
First Contentful Paint (FCP)
“First Contentful Paint measures how long it takes for initial DOM content to
render, but it does not capture how long it took the largest (usually more
meaningful) content on the page to render.” (Houssein Djirdeh, Google)
web.dev/optimize-lcp/

Common Causes for
Poor Largest Contentful Paint
● Slow server response times
● Slow resource load times
● Render-blocking JavaScript / CSS
● Client-side rendering
web.dev/optimize-lcp/

Slow Server Response Times
➢ optimize server,
➢ cache assets,
➢ use a CDN,
➢ use resource hints:
preconnect, dns-prefetch
<IfModule mod_expires.c>
ExpiresActive on
ExpiresDefault
"access plus 5 minutes"
ExpiresByType image/jpeg
"access plus 1 month"
<link rel="dns-prefetch" href="https://fonts.gstatic.com/" >
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
smashingmagazine.com/2019/04/optimization-performance-resource-hints/

<img loading=”lazy”
srcset=”a.jpg b.jpg 2x”
Slow Resource Load Times
➢ optimize, compress, minify
➢ cache
➢ preload, lazy load
➢ responsive images, adaptive serving
navigator.connection.effectiveType // e.g. '4g'
navigator.connection.saveData // data-saver setting
navigator.hardwareConcurrency // CPU core count
navigator.deviceMemory // Device Memory

Render-Blocking Assets
➢ split, inline, minify, defer
.hero-image { background-size: cover; } /* inline critical css */
</style>
<link rel=stylesheet media=screen href="styles.css">
<link rel=stylesheet media=print onload="this.media='screen'" href="later.css">
Use the Coverage tab in Chrome DevTools to find “unused CSS” on your web page.
Remove any unused CSS, or better move it to another stylesheet if used on another
page of your site. Load styles, that are not needed for initial rendering, asynchronously.
Tools: loadCSS, Critical, CriticalCSS, Penthouse, Critters (webpack plugin).

Client-Side Rendering
⚠️ use pre-rendering /
server-side rendering (SSR) ?
“A server-rendered page may look like it can be interacted with,
but it can't respond to any user input until it is “hydrated” (all the
client-side JavaScript has executed). This can make Time to
Interactive (TTI) worse.” (Houssein Djirdeh, Google)

FID: First Input Delay

First Input Delay (FID) vs.
Time To Interactive (TTI) to
measure low responsiveness
“Time to Interactive measures the time it takes for a page to be fully
interactive, when event handlers are registered for most page elements, and
user interaction is processed within 50ms. First Input Delay is different in that
it’s able to track user input that happens before the page is fully interactive. As
a purely real user metric, it cannot be simulated in a lab test. It requires user
interaction in order to be measured.” (Ziemek Bućko)
onely.com/blog/what-is-first-input-delay/

web.dev/fid/
Input Delay Optimization
➢ optimize JavaScript code
➢ reduce execution time
➢ minimize main thread work
➢ reduce request count and transfer size
➢ (don't) use asynchronous event handling
"would improve the metric but likely make the experience
worse" (Philip Walton)

TBT: Total Blocking Time
TBT
Total Blocking Time
?

Total Blocking Time (TBT)
as a replacement for FID
TBT
Total Blocking Time
?
“Total Blocking Time is a Lighthouse Performance metric introduced in 2020
that quantifies your page's load responsiveness to user input. In the simplest
terms, TBT measures the total amount of time your webpage was blocked,
preventing the user from interacting with your page. It is one of the Web Vitals
and is a replacement for the field-only First Input Delay metric.”
gtmetrix.com/total-blocking-time.html

CLS: Cumulative Layout Shift

youtube.com/watch?v=AQqFZ5t8uNc
Cumulative Layout Shift:
“a giant chicken that kicks your content away”
(Addy Osmani)

Cumulative Layout Shift measures
errors from instability
“If an element suddenly moves, your eyes have to find its new position.
Users may end up clicking a link or an ad or a "Buy Now" button unintentionally!
Layout shift significantly disrupts the user's intended journey. Cumulative Layout
Shift measures how frequent and severe unexpected layout shifts are on a page.
Recommended aim for a CLS: less than 0.1 for 75% of page loads.”
https://blog.chromium.org/2020/05/the-science-behind-web-vitals.html

How to prevent Layout Shift
➢ define image dimensions
➢ reserve fixed height containers for
portals / ads / third-party content
➢ use a hero header
➢ use web fonts properly or not at all
to prevent flash of invisible /unstyled text (FOIT/FOUT)
zachleat.com/web/css-tricks-web-fonts/
<img
width=”200”
height=”200”
src=”example.com”
alt=”not shifty”
/>

Conclusion
What's new anyway?
What’s new if you already optimize your page speed? Not much, unless you haven’t
cared about usability and user experience as well? Care about your users, optimize
time to interactive, and prevent layout shift!
My personal prediction: we as developers and designers should also start to care
about sustainability and reduce our website’s carbon footprint! Hopefully, this might
become another important ranking factor in the future.

Discussion
● TBT is the total time of any tasks that take over 50ms. So if you had 3 tasks that take
35ms, 55ms and 80ms the TBT would be 35ms (55-50 and 80 - 50)
● CLS vs. web fonts
○ use variable fonts
○ preload regular font, other (bold, italic) to discover later if needed
○ HTTP Response Header makes browser request it (no server push):
link: <https://example.com/regular.woff2>; rel="preload";
as="font"; type="font/woff2"; crossorigin
● image dimensions vs. art direction and older browsers
○ width height must only put the proper ratio
○ use aspect ratio/intrinsic ratio for the image dimension problem
○ aspect ratio attribute, control by media queries,
○ intrinsic ratio trick with padding-bottom for old devices
○ css-tricks.com/aspect-ratio-boxes/

Links
This presentation is mostly based on other people's work, mainly by Google's Addy Osmani
and Houssein Djirdeh, but I also owe to the German WordPress community and many more:
➔ wpdus.de/meetup-52/ (German)
➔ https://addyosmani.com/
➔ twitter.com/hdjirdeh
➔ web.dev/optimize-lcp/
➔ web.dev/optimize-cls/
➔ web.dev/http-cache/
➔ smashingmagazine.com/2019/04/optimization-performance-resource-hints/
➔ blog.chromium.org/2020/05/the-science-behind-web-vitals.html
➔ developers.google.com/web/fundamentals/performance/get-started/httpcaching-6
➔ dev.to/ingosteinke/optimizing-speed-and-usability-for-google-s-core-web-vitals-1286
➔ zachleat.com/web/css-tricks-web-fonts/
➔ github.com/filamentgroup/loadCSS
➔ github.com/addyosmani/critical
➔ criticalcss.com
➔ github.com/pocketjoso/penthouse
➔ github.com/GoogleChromeLabs/critters

Save the date:
Wednesday, 5 May 2021 at 19:00 CET
Online Meetup
Thanks to Avenga Germany and wao.io for Support

Core web Vitals: Web Performance and Usability

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Core web Vitals: Web Performance and Usability

Similar to Core web Vitals: Web Performance and Usability (20)

Recently uploaded

Recently uploaded (20)

Core web Vitals: Web Performance and Usability