Yoav Weiss on web.dev

How SPA architectures affect Core Web Vitals

2021-09-14T00:00:00Z

Since first introducing the Web Vitals initiative in May of 2020, we on the Chrome team have received a lot of great questions and feedback about the program.

Perhaps the topic we've received the most questions about, which is also probably the hardest question to answer, is how to measure Core Web Vitals in a single-page application (SPA), as well as how SPA architectures affect Core Web Vitals scores.

These questions are hard to answer because the problem is quite nuanced, so in this post we're going to do our best to answer the most common questions, providing as much detail and context as we can.

Before getting into specifics, though, it's important to state that Google does not have any preference as to what architecture or technology is used to build a site. We believe that SPAs and multi-page applications (MPAs) are both capable of delivering high quality experiences to users, and our intention with the Web Vitals initiative is to provide metrics that measure the experience independent of the technology. While this is not possible in every case today (due to limitations in the web platform), we are actively working on closing those gaps.

Frequently asked questions #

Do Core Web Vitals metrics include SPA route transitions? #

No. Each of the Core Web Vitals metrics is measured relative to the current, top-level page navigation. If a page dynamically loads new content and updates the URL of the page in the address bar, it will have no effect on how the Core Web Vitals metrics are measured. Metric values are not reset, and the URL associated with each metric measurement is the URL the user navigated to that initiated the page load.

Can the Core Web Vitals metrics treat SPA route changes the same as traditional page loads? #

Unfortunately, no. Not yet anyway.

There is no standardized way of building an SPA today, and even among the popular SPA and routing libraries, the user experience can be quite different from app to app:

Some SPAs update the URL only when loading new "full page" content, whereas other sites update the URL for tiny content changes or even just UI state changes.
Some SPAs update the URL using the History API, whereas others use hash changes in order to support older browsers (and others do not update the URL at all).
Some SPAs load content and then update the URL, whereas others update the URL before loading content.
Some SPAs load content all at once, synchronously, in a single JavaScript task, whereas others transition content in, asynchronously, across multiple tasks (with no clear transition end event).
Some SPAs always load content from the network, whereas others preload all content upfront so that route changes load instantly from memory.

These differences make defining and identifying what constitutes an SPA route change, or even an SPA itself, very difficult to do at scale.

In some cases an SPA route change is logically identical to an MPA page load, and in such cases it would be great if the existing Core Web Vitals metrics could be applied.

However, without solid heuristics to reliably identify "real" route changes from all other URL changes—as well as clear signals marking the beginning and end of such transitions—reporting Core Web Vitals metrics in these cases would muddy the data and make it less useful or representative of the real user experience on the site.

Is it harder for SPAs to do well on Core Web Vitals than MPAs? #

There is nothing inherent in the SPA architecture that would prevent a page in an SPA from loading just as quickly—and scoring just as well on all of the Core Web Vitals metrics—as a similar page in an MPA.

However, properly optimized MPAs do have some advantages in meeting the Core Web Vitals thresholds that SPAs currently do not. The reason is because with the MPA architecture, each "page" is loaded as a full-page navigation (rather than dynamically fetching content and inserting it into the existing page), which means users who visit an MPA are more likely to load more than one page from the site, which in turn means that a larger percentage of the distribution of all page loads for an MPA will involve some or all of the sub-resources being cached.

Granted, for an MPA to perform better on the Core Web Vitals metrics than an SPA requires a few things to be true:

The MPA needs to have optimized sub-resource caching in order to ensure same-origin page loads are indeed faster than cross-origin page loads at the 75th percentile.
Users who visit MPAs need to visit multiple pages in order for the site to receive the caching benefits that result in faster page loads.

Since Core Web Vitals assessments consider the 75th percentile of page visits, having more, well-performing page visits in the dataset will increase the likelihood that the visit at the 75th percentile of the distribution will be within the recommended thresholds.

Note that an important thing to consider when comparing Core Web Vitals scores is how the data is aggregated—that is, whether the dataset in the distribution includes all pages from your site or origin, or just page loads for a particular page URL.

When aggregating the scores of all pages in an origin, individual fast pages can improve the 75th percentile for the origin as a whole. However, when aggregating by individual pages, the scores of one page will not affect the scores of the next. In other words, when aggregating the scores of an MPA by page, fast cache loads seen on the checkout page will not improve the scores of slow initial loads experienced on the site's landing page.

You can check your site's score for different aggregation methods using PageSpeed Insights or the Chrome User Experience Report API, which reports scores for both individual page URLs and the entire origin.

Another way the SPA architecture can affect Core Web Vitals scores is for metrics that consider the full lifespan of a page. Since users visiting SPAs tend to stay on the same "page" for the entire session, metrics that accumulate over time can be harsher on SPAs than MPAs.

In April 2021, we announced changes to the CLS metric that partially addressed this problem. Previously CLS would accumulate over the entire page lifespan, whereas now it only accumulates over a specific window of time—essentially the worst burst of layout shifts on a given page.

However, even with the new CLS definition, SPAs are still at a disadvantage because the CLS value doesn't "reset" after a route transitions like it does with full page loads in an MPA. This can also lead to confusion because layout shifts that occur after a route transition will be attributed to the URL of the page when it was loaded, not the URL in the address bar at the time of the shift (more details below).

If SPA architectures improve the user experience, shouldn't that improvement be reflected in the metrics? #

Yes, it should. Though as mentioned previously, quantifying just how much the experience has improved is difficult to do at scale, given all the different ways SPAs are implemented on the web today.

The truth is the web performance industry (Google included) has historically not invested nearly as much time and effort into developing user-centric metrics for the post-load performance of a page as it has for the page load itself. This isn't because post-load performance isn't important, it's because post-load UX and interactions are so much more varied and less well-defined—making it hard to design metrics for them.

But even if we did have well defined post-load metrics to measure SPA performance, we wouldn't want to ignore the load experience just because the post load experience got better.

One of the goals of the Web Vitals initiative is to promote and incentivize good user experiences across as many aspects of loading and using a web page as possible. We don't want to encourage scenarios where bad experiences are justified if you can have enough good experiences to make up for them. Users want pages to load fast and transition to new content fast, and we've tried to design metrics that favor those types of experiences.

So while it's true that an MPA version of a site may fare better on the Core Web Vitals metrics at the 75th percentile than an SPA version of the exact same site, the SPA version should still strive to meet the "good" threshold. If the SPA version doesn't meet the "good" threshold for most users, then the initial load experience is probably still not perceived as good—even if the subsequent, in-page navigation experience is excellent.

In the future we plan to develop metrics that encourage great, post-load experiences, and we believe this is the best path to incentivize high-quality SPAs in a way that doesn't compromise the initial load experience. We have already delivered a new metric named Interaction to Next Paint (INP) that measures interaction latency throughout the entire page lifecycle, and we're actively working on other post-load metrics as well, including metrics that measure SPA route transitions (see below).

We switched our site from an MPA to an SPA and our scores regressed. Is that expected? #

It depends. There are a number of reasons why your scores could change after a major architecture migration, but a decrease in the number of warm cache loads could account for some of the change.

A quick way to check would be to test both an MPA and SPA version of one of your landing pages with Lighthouse. If the Lighthouse score is lower on any of the Core Web Vitals metric for the SPA version, then it's likely that the load experience did get worse after the update.

Should I switch my site from an SPA to an MPA to score better on Core Web Vitals? #

Probably not. You should only switch from an SPA to an MPA if you are not happy with your SPA stack and you have reason to believe an MPA will provide a better user experience.

Over time, as the Core Web Vitals metrics improve and cover more of the full browsing experience, teams with well-built SPAs that provide great UX should expect to see their Core Web Vitals scores reflect that.

If Core Web Vitals scores are only reported for an SPA's landing pages, how can I debug issues that occur on "pages" after a route transition? #

Google tools that report field data for the Core Web Vitals metric (like Search Console and PageSpeed Insights) get their data from the Chrome User Experience Report (CrUX). And CrUX aggregates data either by origin or by page URL (that is, the page URL at load time).

For all the reasons already listed above, CrUX is not able to aggregate data by SPA route. However, as a site owner who is familiar with your own architecture, it is possible to measure this yourself, and many analytics tools allow you to signal when an SPA route change is occurring and they update your measurement data accordingly.

When measuring Web Vitals metrics with an analytics tool, make sure you're measuring both the current route URL as well as the original page URL. This will allow you to both debug individual issues that occur throughout the page lifecycle as well as aggregate by original page URL in order to match how Google tools measure and report on the metrics.

For more details and best practices on this topic, see: Debug performance in the field.

What is Google doing to ensure MPAs do not have an unfair advantage compared to SPAs? #

As mentioned above, a properly-optimized MPA can, in some cases, report better Web Vitals scores at the 75th percentile due to the fact that it will likely have a higher percentage of cached page visits. Conversely, real improvements to the user experience in properly-optimized SPAs are not currently being captured by any of the Core Web Vitals metrics.

At Google, we recognize that this creates incentives that do not fully align with the goals of the Web Vitals initiative, and we are actively looking at ways to fix this. Currently, we're exploring two potential solutions, one short term and one longer term:

Assess cross-origin and same-origin page visits separately.
Design new APIs that enable better SPA measurement.

Assess cross-origin and same-origin page visits separately #

Today the Core Web Vitals metrics aggregate all page visits into a single bucket—they do not differentiate between new versus returning visits or landing pages versus checkout pages or any other aggregation type where cache state could have an effect on performance.

One way to normalize the differences between SPA and MPA performance would be to apply different weighting to different types of visits, potentially even with completely different threshold recommendations.

While we definitely do want to reward effective cache implementations, we don't want fast intra-site navigations to be able to cover up for slow landing page loads. We also don't want to incentivize sites to break up long pages into a collection of shorter pages just for the sake of improving metric scores.

By separately assessing cross-origin and same-origin page visits we can help ensure that both types of experiences are important without letting the relative popularity of one type on a given site skew the distribution of any particular metric.

Design new APIs that enable better SPA measurement #

Another solution that is actively being worked on (in parallel to the above) is a new App History API, which would help standardize current SPA patterns and make it easier to measure and understand SPA usage at scale.

The App History API introduces a new navigate event, which has two key features specific to SPA measurement:

A userInitiated flag, which will only be set to true if the navigation was initiated via a link click, form submission, or the browser's back or forward UI.
A transitionWhile() method, which takes a promise allowing the developer to signal when the work they've initiated to perform the navigation is complete.

The userInitiated flag can be used to determine a semantic starting point for an SPA route transition, indicating clear user intent. The transitionWhile() promise resolving can help the browser correlate paints with the specific route transition, such that it may be able to determine the largest contentful paint related to that transition.

Building on top of the idea presented in the previous section, it might even be possible to aggregate SPA route transition time into the same bucket as same-origin page loads in an MPA. This is exciting because it would allow a site migrating from an MPA to an SPA to actually compare the performance before and after.

Of course, more research is needed before we'll know whether we can accurately make these determinations. If you have suggestions or feedback on these proposals, please email web-vitals-feedback@googlegroups.com.

Final thoughts #

Google is deeply committed to improving the Web Vitals metrics, and ensuring they measure and incentivize high-quality experiences that are important to users. That being said, we do acknowledge that measurement gaps exist today. The metrics do not currently cover every aspect of user experience, but we are actively working to close these gaps.

Despite the current limitations, we believe the areas the existing metrics do capture are critical to the health and success of the web, and to the extent that sites (regardless of architecture) do not meet the recommended thresholds, we believe there is room for improvement.

I hope this post has helped shed some light on this complex and nuanced subject. As always, if you have feedback on the current or future Web Vitals metrics, please email web-vitals-feedback@googlegroups.com.

Preloading responsive images

2019-09-30T00:00:00Z

Browser support

Chrome 73, Supported 73
Firefox 78, Supported 78
Edge 79, Supported 79
Safari, Not supported

This article gives me an opportunity to discuss two of my favorite things: responsive images and preload. As someone who was heavily involved in developing both of those features, I'm super excited to see them working together!

Responsive images overview #

Suppose you're browsing the web on a screen that's 300 pixels wide, and the page just requested an image that's 1500 pixels wide. That page just wasted a lot of your cellular data because your screen can't do anything with all of that extra resolution. Ideally, the browser should fetch a version of the image that's just a little wider than your screen size, say 325 pixels. This ensures a high-resolution image without wasting data. And, even better, the image will load faster. Responsive images enable browsers to fetch different image resources to different devices. If you don't use an image CDN you need to save multiple dimensions for each image and specify them in the srcset attribute. The w value tells the browser the width of each version. Depending on the device, the browser can choose the appropriate one:

<img src="small.jpg" srcset="small.jpg 500w, medium.jpg 1000w, large.jpg 1500w" alt="…">

Preload overview #

Preload lets you tell the browser about critical resources that you want to load as soon as possible, before they are discovered in HTML. This is especially useful for resources that are not easily discoverable, such as fonts included in stylesheets, background images, or resources loaded from a script.

<link rel="preload" as="image" href="important.png">

Responsive images + preload = faster image loads #

Responsive images and preload have been available for the last few years, but at the same time something was missing: there was no way to preload responsive images. Starting in Chrome 73, the browser can preload the right variant of responsive images specified in srcset before it discovers the img tag!

Depending on your site's structure, that could mean significantly faster image display! We ran tests on a site that uses JavaScript to lazy-load responsive images. Preloading resulted in images loading 1.2 seconds faster.

`imagesrcset` and `imagesizes` #

To preload responsive images, new attributes were recently added to the <link> element: imagesrcset and imagesizes. They are used with <link rel="preload"> and match the srcset and sizes syntax used in <img> element.

For example, if you want to preload a responsive image specified with:

<img src="wolf.jpg" srcset="wolf_400px.jpg 400w, wolf_800px.jpg 800w, wolf_1600px.jpg 1600w" sizes="50vw" alt="A rad wolf">

You can do that by adding the following to your HTML's <head>:

<link rel="preload" as="image" href="wolf.jpg" imagesrcset="wolf_400px.jpg 400w, wolf_800px.jpg 800w, wolf_1600px.jpg 1600w" imagesizes="50vw">

This kicks off a request using the same resource selection logic that srcset and sizes will apply.

Use cases #

Preloading dynamically-injected responsive images #

Let's say you're dynamically-loading hero images as part of a slideshow and know which image will be displayed first. In that case, you probably want to avoid waiting for the script before loading the image in question, as that would delay when users can see it.

You can inspect this issue on a website with a dynamically-loaded image gallery:

Open this example website in a new tab.
Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Network tab.
In the Throttling drop-down list, select Fast 3G.
Disable the Disable cache checkbox.
Reload the page.

This waterfall shows that the images only start loading after the browser has finished running the script, introducing unnecessary delay to the time the image is initially displayed to the user.

Using preload helps here because the image starts loading ahead of time and is likely to already be there when the browser needs to display it.

This waterfall shows that the first image started loading at the same time as the script, avoiding unnecessary delays and resulting in faster displaying images.

To see the difference that preloading makes, you can inspect the same dynamically-loaded image gallery but with preloaded first image by following the steps from the first example.

Preloading background images using image-set #

If you have different background images for different screen densities, you can specify them in your CSS with the image-set syntax. The browser can then choose which one to display based on the screen's DPR.

background-image: image-set( "cat.png" 1x, "cat-2x.png" 2x);

The problem with CSS background images is that they are discovered by the browser only after it has downloaded and processed all the CSS in the page's <head>, which can be a lot of CSS…

You can inspect this issue on an example website with responsive background image.

In this example, the image download doesn't start until the CSS is fully downloaded, resulting in unnecessary lag to the image's display.

Responsive image preloading provides a simple and hack-free way to load those images faster.

<link rel="preload" as="image" imagesrcset="cat.png 1x, cat-2x.png 2x">

Note that by excluding the href attribute, you can ensure the browsers that do not support imagesrcset on the <link> element, but do support image-set in CSS, will not download an incorrect source. However, they will also not benefit from the preload in this case.

You can inspect how the previous example behaves with preloaded responsive background image.

Here the image and CSS start downloading at the same time, avoiding delays and resulting in a faster loading image.

Preloading responsive images in action #

Preloading your responsive images can speed them up in theory, but what does it do in practice?

To answer that I created two copies of a demo PWA shop: one that does not preload images, and one that preloads some of them. Since the site lazy loads images using JavaScript, it's likely to benefit from preloading the ones that will be in the initial viewport.

That gave me the following results for no preload and for image preload. Looking at the raw numbers we see that Start Render stayed the same, Speed Index slightly improved (273 ms, as images arrive faster, but don't take up a huge chunk of the pixel area), but the real metric which captures the difference is the Last Painted Hero metric, which improved by 1.2 seconds. 🎉🎉

Of course, nothing captures the visual difference quite like a filmstrip comparison:

The filmstrip shows that images arrive significantly faster when preloaded, resulting in a hugely-improved user experience.

Preload and `<picture>`? #

If you're familiar with responsive images, you may be wondering "What about <picture>?".

The Web Performance Working Group is talking about adding a preload equivalent for srcset and sizes, but not the <picture> element, which tackles the "art direction" use-case.

Why is this use-case being "neglected"?

While there's interest in solving that use case as well, there are still a number of technical issues to sort out which means that a solution here would have significant complexity. On top of that, it seems like for the most part, the use-case can be addressed today, even if in a hacky way (see below).

Given that, the Web Performance WG decided to ship srcset first and see if the demand for equivalent picture support arises.

If you do find yourself in a position to preload <picture> you may be able to use the following technique as a workaround.

Given the following scenario:

<picture>
    <source srcset="small_cat.jpg" media="(max-width: 400px)">
    <source srcset="medium_cat.jpg" media="(max-width: 800px)">
    <img src="large_cat.jpg">
</picture>

The <picture> element's logic (or the image source selection logic, to be precise), would be to go over the media attributes of the <source> elements in order, find the first one that matches, and use the attached resource.

Because responsive preload has no notion of "order" or "first match", the breakpoints need to be translated into something like:

<link rel="preload" href="small_cat.jpg" as="image" media="(max-width: 400px)">
<link rel="preload" href="medium_cat.jpg" as="image" media="(min-width: 400.1px) and (max-width: 800px)">
<link rel="preload" href="large_cat.jpg" as="image" media="(min-width: 800.1px)">

Preload and `type` #

The <picture> element also supports matching on the first type, to allow different image formats to be provided and the browser to pick the first image format it supports. This use case is not currently supported with preload.

For sites using this, avoiding preload is the best option, and instead having the preload scanner pick these up from the <picture> and <source> elements instead. This is a best practice anyway, particular with the support of Priority Hints which allows the appropriate image to be prioritised in a better manner than preload alone.

Effects on Largest Contentful Paint (LCP) #

Since images can be candidates for Largest Contentful Paint (LCP), preloading them may improve your website's LCP. Using the techniques above, you can also ensure that your responsive images will load more quickly.

Regardless of whether the image you're preloading is responsive, be aware that preloads work especially well when the image resource isn't discoverable in the initial markup payload. For websites that send complete markup from the server, you may not realize a huge benefit. However, if your website renders markup on the client—which sidesteps the browser's preload scanner—there's an opportunity on the table to preload potential LCP images to improve performance.

Summary #

Responsive image preload gives us new and exciting possibilities to preload responsive images in ways that were previously only possible using hacks. It's an important new addition to the speed-conscious developer's toolbox and enables us to make sure the important images we want to get in front of our users as soon as possible will be there when we need them.