Rendering strategies: Measuring the devil's details in core web vitals - Jamie Indigo, TechSEO Boost 2021

Jamie Indigo | @Jammer_Volts | #TechSEOBoost
Rendering Strategies
Measuring the Devil's Details in Core Web Vitals

Image
credit:
Ian
Myles
Core Web Vitals are coming.

● Understand Core Web Vital metrics and measurement
● Where and how CWV occur
● Rendering strategies with their respective CWV pratfalls, and mitigation
tactics
Our quest

Metrics and Measurements
Core Web Vitals

Loading Interactivity Visual Stability
�
�
⏳
Images
via:
The
SEO's
Guide
to
Google's
Core
Web
Vitals

Field Data is performance data
collected from real page loads your
users are experiencing in the wild.
AKA Real User Monitoring (RUM)
Crux data will be used in the Page
Experience Ranking Signal.
Crux = CWV source of truth
Lab Data is performance data
collected within a controlled
environment with predefined device
and network settings.
AKA Emulated Data
Use Lab Data for debugging
performance issues and QAing fixes in
lower environments.
A quick note on Lab vs Field Data

Represents: Perceived loading
experience
Measurement: the point in the page load
timeline when the page's largest image or
text block is visible within the viewport.
Behavior: Pages using the same page
templates typically share the same LCP
node
Largest Contentful Paint (LCP)
LCP time
(in milliseconds) Color-coding
0–2,500 Green (fast)
2,500-4,000 Orange (moderate)
Over 4,000 Red (slow)

What can be LCP?
Text
blocks
Images
Video
posters

1. Open Chrome Dev Tools to
the Performance panel
2. Tick 'Web Vitals'
3. Click the 'start profiling and
reload page
Define LCP using Chrome DevTools

1. In DevTools, navigate to
the Timings section of the
Performance panel
2. Hover over the LCP marker
3. The element(s) that
correspond to LCP is
detailed in the Related
Node field
Define LCP using Chrome DevTools

Represents: Responsiveness to user input
Measurement: the time from when a user
first interacts with a page to the time when
the browser is actually able to begin
processing event handlers in response to that
interaction.
Behavior: FID is only available as field data.
First Input Delay (FID)
FID
0-100 Green (fast)
101-299 Orange (moderate)
>= 300 Red (slow)

FID is a way of measuring main thread activity

TBT Measures: Responsiveness to
user input
TBT Measurement: Total time in which
the main thread is occupied by tasks
taking more than 50ms to complete.
Use Total Blocking Time (TBT) for lab tests
TBT
0–300 Green (fast)
301-599 Orange (moderate)
Over 600 Red (slow)

Represents: Visual stability
Measurement: a calculation based on the
number of frames in which element(s)
visually moves and the total distance in
pixels the element(s) moved.
Behavior: Often an element used across
pages. Probably your cookie notice.
Cumulative Layout Shift (CLS)
CLS calculated score Color-coding
0–0.10 Green (fast)
0.11-0.24 Orange (moderate)
>= 0.25 Red (slow)

CLS is marked in the experience
row as “layout shift”
Details appear in the summary
section
Identify CLS elements using Chrome DevTools

Image
credit:
Joe
Wue

Mobile
Screen
Resolution
Stats
Worldwide
360 x 640

Core Web Vitals measure how
long it takes to complete the
the script functions needed to
paint the above the content.

It's a simple formula
User Screen Content

the process of turning
HTML into pixels
Rendering:

CWV Arena
Pixel Pipeline

The pixel pipeline
JavaScript Style Layout Paint Composite
Handles work that will result in visual changes
Examples:
● jQuery’s animate function
● Sorting a data set
● Adding DOM elements to the page

DOM
HTML
HTML
Parser
DOM
Tree
JavaScript modifies or adds
content to the DOM.
@Jammer_volts
Step 1: Parsing
turns a chunk of HTML
into DOM nodes

Body
h1 p img
Before JavaScript Body
h1 p img
After JavaScript
ol
li li
li
p img

The pixel pipeline
Style calculations are the process of figuring out which CSS rules apply to which
elements based on matching selectors.
JavaScript Layout Paint Composite
Style

DOM
HTML
Style
Sheets
HTML
Parser
CSS
Parser
DOM
Tree
Style
Rules
Attachment
@Jammer_volts
Step 2: Style
Add style calculations to
the DOM

The pixel pipeline
JavaScript Style
Once the browser knows which rules apply to an element it can begin to calculate
how much space it takes up and where relative to the size of the viewport.
The Core Web Vital metric Cumulative Layout Shift measures this.
Paint Composite
Layout

DOM
HTML
Style
Sheets
HTML
Parser
CSS
Parser
DOM
Tree
Style
Rules
Render
Tree
Attachment
Layout
Step 3: Layout
figure out where DOM
elements end up relative
to one another

p p img h1
img ol img
p

The pixel pipeline
JavaScript Style Layout
Painting is the process of filling in pixels. It involves drawing out text, colors,
images, borders, and shadows, essentially every visual part of the elements.
The drawing is typically done onto multiple surfaces, often called layers.
Largest content paint occurs here
Composite
Paint

Painting
DOM
HTML
Style
Sheets
HTML
Parser
CSS
Parser
DOM
Tree
Style
Rules
Render
Tree
Attachment
Layout
Step 4: Paint
converts layers of styled DOM
elements into pixels

The pixel pipeline
JavaScript Style Layout Paint Composite
Since the parts of the page were drawn into potentially multiple layers they need to
be drawn to the screen in the correct order so that the page renders correctly.
This is especially important for elements that overlap another, since a mistake
could result in one element appearing over the top of another incorrectly.

DOM
HTML
Style
Sheets
HTML
Parser
CSS
Parser
DOM
Tree
Style
Rules
Render
Tree
Attachment
Layout
Painting
Composite
Step 5: Composite
assembles all layers into a final
screen image

What we think
it’ll be like

What it's actually like

The end result is the same.
How we do it matters.

CWV Pratfalls and Mitigations

● Client Side
● Server Sider
● Static
● Dynamic
● Rehydration

Client Side Rendering (CSR)
<!doctype html>
<head>
<script
type="text/javascript"
src="/main.js?ver=1.1.0">
</script>
</head>
<body>
<app-root></app-root>
</body>
</html>

CSR Poor LCP: CSR
Source:
https://web.dev/lcp/

<rel="buyproduct.js">
= 99.5% success rate
Each script has a probability to fail.
With
JavaScript
Without
JavaScript

script1.js
script2.js
script3.js
script4.js
{Product name}
{Product sku}
{Product price}
{Product category}
{Product availability}
{Shipping times}
{Breadcrumbs}
{Product description}
{Product images}
{Product specs}
<!doctype html>
<head>
<script type="text/javascript"
src="/main.js?ver=1.1.0">
</script>
</head>
<body>
<app-root></app-root>
</body>
</html>

script1.js
script2.js
script3.js
script4.js
{Product name}
{Product sku}
{Product price}
{Product category}
{Shipping times}
{Breadcrumbs}
{Product images}
{Product specs}
mainbundle.js

Chains are dependencies.
Each segment of the chain is
dependent on its initiator to
execute.
If a segment of the chain fails,
all of its subsequent content
fails.
Mitigation: Avoid Critical Chains
bundle.js
script1.js
script2.js
script3.js
script4.js
{Product name}
{Product sku}
{Product price}
{Product category}
{Shipping times}
{Breadcrumbs}
{Product images}
{Product specs}

CSR Poor LCP: Render-blocking JavaScript and
CSS

2 types resources block rendering
<link rel="stylesheet">
when
● Does not have a disabled
attribute. When this attribute is
present, the browser does not
download the stylesheet.
● Does not have a media attribute
that matches the user's device.
<script>
when
● Is in the <head> of the document.
● Does not have a defer attribute.
● Does not have an async attribute.

Tell non-critical assets to wait using asynchronous or defer
attributes
<rel=”myscript.js” async>
<rel=”myscript.js” defer>
Lazy load images in Chrome with native attributes
<img src=”the-traveler.jpg” loading=”lazy”>
Mitigation: Defer non critical assets

Inline small scripts into <head> using <style>
and/or <script> tags for above the fold content
● Ideally inline CSS is immediately after critical
metadata
● Load inline scripts before third party
resources, style sheets and JS
● If the script is over 1 kB, avoid inlining it
(Inline scripts are parsed and compiled on
the main thread.)
● Remove inline functions from script bundles
Mitigation: Inline Critical Assets

CSR Poor LCP: Performance
● Google will limit CPU consumption
● Google will interrupt script
● Excessive CPU consumption negatively impacts indexing

CSR: Poor FID
Heavy JavaScript execution
const heavy = true;
While (heavy) {
console.log("FID
fail")
}

Mitigation: Only ship contributing scripts

CSR Poor CLS: Image dimensions
● Images without dimensions
● Ads, embeds, and iframes without
dimensions
Mitigation: Declare dimensions
img {
width: 100%; /* or max-width: 100%; */
height: auto;
}
Reserved slot:
Ad space
img {
width: 100%;
/* or max-width:
100%; */
height: auto;
}

*
CSR Poor CLS: Loading above existing content
Footer
Header
CLS Layout Score = impact fraction * distance fraction
Mitigation: Prioritize Above the Fold content load

CSR Poor CLS: document.write()
Modern Browsers support speculative parsing off of the main thread.
Read as: They parse ahead while scripts are being downloaded and executed.
document.write() ruins all that hard work.
Mitigation: Chances are this isn't the work of your devs. Talk to your
point of content that for "magic" third-party tool.

CSR Poor CLS: Style recalculations
Changing the DOM will cause the browser to
recalculate element styles (and possibly layouts).
Mitigation: Lessen the scope and complexity of
Style Calculations by:
● Reducing the complexity of your selectors.
● Reducing the number of elements being styled.
● Measure your Style Recalculation Cost
● Use BEM (Block, Element, Modifier) a
class-centric methodology.

A font loading late causes a full flash and re-write.
Mitigation: Preload fonts. Preload tells the browser that
you would like to fetch it sooner than the browser would
otherwise discover it because you are certain that it is
important for the current page.
<link rel="preload" href="/assets/Pacifico-Bold.woff2"
as="font" type="font/woff2" crossorigin>
CSR Poor CLS: Web Fonts causing FOIT/FOUT

At the time of
request
<!doctype html>
<head>
<title>Hello, TechSEO
Boost!
</head>
<body>
<h1>Wait.This isn’t
Boston :( </h1>
<p>Wash your hands.</p>
</body>
</html>
Server Side Rendering (SSR)

● Slow server response times
● Render-blocking JavaScript and CSS
● Resource load times
● Client-side rendering
Are all the server calculations valuable?
Do they contribute to page content?
SSR: Poor LCP
<!doctype html>
<head>
<title>Hello, TechSEO Boost!
</head>
<body>
<h1>Wait.This isn’t Boston :( </h1>
</body>
</html>

SSR Poor LCP: Media Declarations
The default media="all" (or no
declaration) matches all viewport
sizes.
Mitigation: Dynamic media queries
evaluate the viewport when the page
is loaded.
<link href="xsmall.css"
rel="stylesheet"
media="xsmall">
<link href="small.css"
rel="stylesheet"
media="small">
<link href="print.css"
rel="stylesheet"
media="print">

During the
build
Static Rendering
<!doctype html>
<head>
<title>Hello, TechSEO
Boost!
</head>
<body>
<h1>Wait.This isn’t
Boston :( </h1>
</body>
</html>

Cons
● $$$
● Tricky to get "right"
● Only works for static content – not
for content that’s meant to change
(think personalization and A/B
testing)
Pros
● Low TTFB
● Delivers parsed HTML
Static Rendering: YMMV

Dynamic Rendering
Crawler

2x
server costs, test
cases, and QA
½
visibility into what is
actually happening

"It is not reasonable."

Rehydration
Above the fold
HTML
+
Below the fold
scripts

Load what matters when it matters.

Image
credit:
John
Fowler

|￣￣￣￣￣￣￣￣￣￣￣|
DON'T BE AFRAID
TO LEARN IN PUBLIC
|＿＿＿＿＿＿＿＿＿＿＿|
(__/) ||
(•ㅅ•) ||
/ 　づ

Rendering strategies: Measuring the devil's details in core web vitals - Jamie Indigo, TechSEO Boost 2021

More Related Content

What's hot (20)

Similar to Rendering strategies: Measuring the devil's details in core web vitals - Jamie Indigo, TechSEO Boost 2021 (20)

Recently uploaded (20)

Rendering strategies: Measuring the devil's details in core web vitals - Jamie Indigo, TechSEO Boost 2021