Real humans want good web experiences. What does that look like in practice?
Well, one recent study cited by Google in a blog post about Core Web Vitals found that mobile web users only kept their attention on the screen for 4-8 seconds at a time.
Read that again.
You have less than 8 seconds to deliver interactive content and get a user to complete a task.
Enter Core Web Vitals (CWV). These three metrics are designed to measure site performance in human experience. The open-source Chromium project announced the metrics in early May 2020 and they were swiftly adopted across Google products.
How do we qualify performance in user-centric measurements?
- Is it loading?
- Can I interact?
- Is it visually stable?
Fundamentally, Core Web Vitals measure how long it takes to complete the script functions needed to paint the above-the-fold content. The arena for these Herculean tasks is a 360 x 640 viewport. It fits right in your pocket!
This war-drum for unaddressed tech debt is a blessing to a lot of product owners and tech SEO professionals who have been backlogged in favor of new features and shiny baubles.
Is the Page Experience update going to be Mobileggedon 4.0?
Probably not.
But when your page passes CWV assessments, users are 24% less likely to abandon page loads. These efforts benefit every source and medium, and most importantly – real humans.
The Page Experience Update
For all the buzz, CWV will be elements in a ranking signal. Expected to roll out gradually mid-June through August 2021, the Page Experience Ranking will be comprised of:
- Core Web Vitals.
- Mobile-Friendly.
- Safe Browsing.
- HTTPS.
- No Intrusive Interstitials.
Updated documentation clarifies that the rollout will be gradual and that “sites generally should not expect drastic changes.”
Important things to know about the update:
- Page Experience is evaluated per URL.
- Page experience is based on a mobile browser.
- AMP is no longer required for Top Stories carousels.
- Passing CWV is not a requirement to appear in Top Stories carousels.
A New Page Experience Report in Search Console
Search Console now includes a Page Experience report. The fresh resource includes backdated data for the last 90 days.
In order for a URL to be “Good,” it must meet the following criteria:
- The URL has Good status in the Core Web Vitals report.
- The URL has no mobile usability issues according to the Mobile Usability report.
- The site has no security issues.
- The URL is served over HTTPS.
- The site has no Ad Experience issues, or the site was not evaluated for Ad Experience.
The new report offers high-level widgets linking to reports for each of the five “Good” criteria.
Workflow for Diagnosing & Actioning CWV Improvements
First, an important caveat regarding Field vs Lab data.
Field Data is performance data collected from real page loads your users are experiencing in the wild. You may also hear Field Data referred to as Real User Monitoring.
Core Web Vitals assessments and the Page Experience Ranking Signal will use Field Data gathered by the Chrome User Experience Report (Crux).
Which Users Are Part of the Chrome User Experience Report?
Crux data is aggregated users who meet three criteria:
- The user opted-in to syncing their browsing history.
- The user has not set up a Sync passphrase.
- The user has usage statistic reporting enabled.
Crux is your source of truth for Core Web Vitals Assessment.
You can access Crux data using Google Search Console, PageSpeed Insights (page-level), Public Google BigQuery project, or as an origin-level dashboard in Google Data Studio.
Why would you use anything else? Well, CWV Field Data is a restricted set of metrics with limited debugging capabilities and requirements for data availability.
Why Doesn’t My Page Have Data Available From Crux?
When testing your page, you may see “The Chrome User Experience Report does not have sufficient real-world speed data for this page.”
This is because Crux data is anonymized. There must be enough page loads to report without the reasonable possibility of the individual user being identified.
Web Core Vitals are best identified using field data and then diagnosed/QAed using lab data.
Lab Data allows you to debug performance with end-to-end and deep visibility into UX. It’s called “lab” as this emulated data is collected within a controlled environment with predefined device and network settings.
You can get lab data from PageSpeed Insights, web.dev/measure, Chrome DevTool’s Lighthouse panel, and Chromium-based crawlers like a local NodeJS Lighthouse or DeepCrawl.
Let’s dive into a workflow process.
1. Identify Issues With Crux Data Grouped by Behavior Patterns in Search Console.
Start with Search Console’s Core Web Vitals report to identify groups of pages that require attention. This data set uses Crux data and does you the kindness of grouping together example URLs based on behavior patterns.
If you solve the root issue for one page, you’re likely to fix it for all pages sharing that CWV woe. Typically, these issues are shared by a template, CMS instance, or on-page element. GSC does the grouping for you.
Focus on Mobile data, as Google is moving to a Mobile-First Index and CWV is set to affect mobile SERPs. Prioritize your efforts based on the number of URLs impacted.
Click into an issue to see example URLs that exhibit the same behavior patterns.
Save these example URLs for testing throughout the improvement process.
2. Use PageSpeed Insights to Marry Field Data With Lab Diagnostics.
Once you’ve identified pages that need work, use PageSpeed Insights (powered by Lighthouse and Chrome UX Report) to diagnose lab and field issues on a page.
Remember that lab tests are one-off emulated tests. One test is not a source of truth or a definitive answer. Test multiple example URLs.
PageSpeed Insights can only be used to test publicly available and indexable URLs.
If you’re working on noindex or authenticated pages, Crux data is available via API or BigQuery. Lab tests should use Lighthouse.
3. Create a Ticket. Do the Development Work.
I encourage you as SEO professionals to be part of the ticket refinement and QA processes.
Development teams typically work in sprints. Each sprint includes set tickets. Having well-written tickets allows your development team to better size the effort and get the ticket into a sprint.
In your tickets, include:
User Story
Follow a simple format:
As a < type of user/site/etc >, I want < action > in order to < goal >.
Eg.: As a performant site, I want to include inline CSS for node X on page template Y in order to achieve the largest contentful paint for this page template in under 2.5 seconds.
Acceptance Criteria
Define when the goal has been achieved. What does “done” mean? Eg.:
- Inline any critical-path CSS used for above-the-fold content by including it directly in .
- Critical CSS (read as: that related to node X) appears above JS and CSS resource links in the .
Testing URLs/Strategy
Include the grouped example URLs you copied down from Search Console. Provide a set of steps for QA engineers to follow.
Think about which tool is used, what metric/marker to look for, and the behavior indicating a pass or fail.
Links to Developer Document
Use first-party documentation when available. Please no fluffy blogs. Please? Eg.:
4. QA Changes in Staging Environments Using Lighthouse.
Before code is pushed to production, it’s often put in a staging environment for testing. Use Lighthouse (via Chrome DevTools or local node instance) to measure Core Web Vitals.
If you’re new to testing with Lighthouse, you can learn about ways to test and testing methodology in A Technical SEO Guide to Lighthouse Performance Metrics.
Keep in mind that lower environments typically have fewer resources and will be less performant than production.
Rely on the acceptance criteria to home in on whether the development work completed met the task given.
Largest Contentful Paint
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.
Key Behaviors: Pages using the same page templates typically share the same LCP node.
Goal: 75% of page loads achieve LCP in < 2.5 seconds.
Available as: Lab and Field Data.
What Can Be LCP?
The LCP metric measures when the largest text or image element in the viewport is visible.
Possible elements that can be a page’s LCP node include:
elements.
elements inside an - poster images of
- background images loaded via url() CSS function.
- Text nodes inside block-level elements.
Expect to see additional elements like
How to identify LCP using Chrome DevTools
- Open the page in Chrome emulating a Moto 4G.
- Navigate to the Performance panel of Dev Tools (Command + Option + I on Mac or Control + Shift + I on Windows and Linux).
- Hover over the LCP marker in the Timings section.
- The element(s) that correspond to LCP is detailed in the Related Node field.
What Causes Poor LCP?
There are four common issues causing poor LCP:
- Slow server response times.
- Render-blocking JavaScript and CSS.
- Slow resource load times.
- Client-side rendering.
Source issues for LCP are painted in broad strokes at best. Unfortunately, none of the single phrases above will likely be enough to pass along to your dev team with meaningful results.
However, you can give the issue momentum by homing in on which of the four origins is in play.
Improving LCP is going to be collaborative. Getting it fixed means sitting in on dev updates and following up as a stakeholder.
Diagnosing Poor LCP Because of Slow Server Response Time
Where to look: Crux Dashboard v2 – Time to First Byte (TTFB) (page 6)
IF you see consistently poor TTFB in your field data, then it’s slow server response time dragging LCP.
How to Fix Slow Server Response Time
Server response time is made of numerous factors bespoke to the site’s technology stack. There are no silver bullets here. Your best course of action is to open a ticket with your development team.
Some possible ways to improve TTFB are:
- Optimize the server.
- Route users to a nearby CDN.
- Cache assets.
- Serve HTML pages cache-first.
- Establish third-party connections early.
Diagnosing Poor LCP Because of Render-Blocking JavaScript and CSS
Where to look: Lighthouse (via web.dev/measure, Chrome DevTools, Pagespeed Insights, or nodeJS instance). Each of the solutions below include a relevant audit flag.
How to Fix Render-blocking CSS
CSS is inherently render-blocking and impact critical rendering path performance. By default, CSS is treated as a render-blocking resource.
The browser downloads all CSS resources, regardless of blocking or non-blocking behavior.
Minify CSS.
If your site uses a module bundler or build tool, find the plugin that will systematically minimize the scripts.
Defer non-critical CSS.
The Code Coverage report in DevTools will help you identify which styles are used on the page. If it’s not used on any pages, then remove it entirely. (No judgement, CSS files can quickly bloat into the proverbial junk drawer.)
If the styles are used on another page, make a separate style sheet for those pages which use it to call.
Inline critical CSS.
Include the critical-path CSS used for above-the-fold content (as identified by the Code Coverage report) directly in
.Use Dynamic Media Queries.
Media queries are simple filters that when applied to CSS styles break out the styles based on the types of device rendering the content.
Using dynamic media queries means instead of calculating styles for all viewports, you’re calling and calculating those values to the requesting viewport.
How to Fix Render-Blocking JavaScript
Minify and compress JavaScript files.
You’ll need to work with developers to minify and compress network payloads.
Minification involves removing unneeded whitespace and code. It’s best done systematically with a JavaScript compression tool.
Compression involves algorithmically modifying the data format for performant server and client interactions.
Defer unused JavaScript.
Code splitting chops up large chunks of JS to deliver smaller packages. You can then load those that matter to above-the-fold content first.
Minimize unused polyfills.
Remember how Googlebot was stuck in Chrome 44 for what felt like centuries? A polyfills is a piece of code used to provide modern functionality on older browsers that do not natively support it.
Now that Googlebot is evergreen, it also goes by the name tech debt.
Some compilers have built-in functionalities to remove legacy polyfills.
How to Fix Render-Blocking Third-Party Scripts
Delay it.
If the script does not contribute to above the fold content, use async or defer attributes.
Remove it.
If the script uses an