Demian Renzulli on web.dev

How Terra improved user engagement thanks to Dark Mode

2021-12-18T00:00:00Z

Terra, one of Brazil's largest media companies with 75 million monthly users, reduced the bounce rate by 60% and increased the pages read per session by 170% on desktop for users that prefer dark mode by providing a custom dark theme.

In this article, we'll analyze Terra's journey from identifying the size of the "dark mode" cohort, to applying a custom dark theme, and finally measuring the impact of this implementation on their main KPIs.

60_%

Reduction in Bounce Rates

170_%

More pages per session

What is dark mode? #

Historically user interfaces in devices are displayed in "light mode", which usually means displaying black text on top of light interfaces. The alternative is "dark mode", with light text on a dark background, such as gray or black.

Dark Mode has benefits for user experience. Some people prefer it for aesthetic or accessibility reasons. It has other advantages, such as preserving battery life in devices. Users can express that they prefer dark mode via a setting in their devices, which depends on the operating system. For example, the following screenshot shows what the Dark Theme configuration option looks like in devices that run Android Q:

Android Q dark theme settings.

To offer a better experience to users who prefer "dark mode", you can use the prefers-color-scheme media query, with a value of light or dark. This media query reflects the user's choice in their device. You can then load a custom dark theme for those that prefer dark. For example, by loading a "dark" CSS file, and changing values such as font and background colors. The following code shows an example of that:

@media (prefers-color-scheme: dark) {
   // apply a dark theme
}

@media (prefers-color-scheme: light) {
  // apply a light theme
}

Browser support

Chrome 76, Supported 76
Firefox 67, Supported 67
Edge 79, Supported 79
Safari 12.1, Supported 12.1

Source

Identifying the "prefers light" vs "dark" user cohorts #

At the time of writing (December 2021), Chrome Platform Status determines that approximately 22% of the web traffic comes from users with the "prefer dark" setting.

This is aggregated data, so the real percentage of users who prefer dark that come to a site can vary. For that reason, to understand the size of this group it is advisable to run in house measurement.

The following code creates an analytics dimension, to measure the performance of users that prefer light vs. dark:

function getColorScheme() {
    let colorScheme = 'Unknown';
    if (window.matchMedia) {
        if (window.matchMedia('(prefers-color-scheme: dark)').matches) {
            colorScheme = 'Dark';
        } else if (window.matchMedia('(prefers-color-scheme: light)').matches) {
            colorScheme = 'Light';
        }
    }
    return colorScheme;
}

window.ga=window.ga||function(){(ga.q=ga.q||[]).push(arguments)};
ga.l=+new Date; ga('create', 'UA-ID', 'auto');
ga('set', 'color-scheme-preference', getColorScheme());
ga('send', 'pageview');

Terra implemented this code in their site and compared the behavior of both groups in mobile (Android) and desktop (Windows) devices. At that moment Terra wasn't providing a custom dark theme, so the goals of this experiment were:

Determining the size of the group of users who prefer dark.
Identifying patterns: for example, do users that prefer dark leave the site more quickly compared to those that prefer light?

Knowing this can inform decisions, for example: if it's necessary to provide a custom dark theme. These are the results Terra obtained after testing for 14 days:

Mobile (Android) #

In the case of mobile (Android) the numbers for bounce rate and pages per session didn't show big differences between the users that prefer "light", compared to those that prefer "dark":

Display Mode	Bounce Rate	Pages Per Session
Prefers Light	25.84%	3.96
Prefers Dark	26.10%	3.75

Desktop (Windows) #

In the case of desktop (Windows), the group of users that preferred "dark" stayed much less on the site: they had almost twice the bounce rate and read a little more than half of the pages than those users that preferred "light":

Display Mode	Bounce Rate	Pages Per Session
Prefers Light	13.20%	7.42
Prefers Dark	24.12%	4.68

Based on this data, Terra hypothesized that users who prefer "dark" stay less in desktop devices, due to the lack of support of a dark theme in their site.

As a next step Terra decided to work on a "dark theme" strategy to see if they could improve the engagement for the group of users that preferred dark.

Implementing a dark theme #

Most websites implement a dark theme by using the simple strategy shown previously of listening to user's configuration changes via the prefers-color-scheme media query and changing styles based on that.

Terra decided to give more control to the user: when they detect that they have the "prefer dark" setting turned on in their devices (via the media query), they show them a prompt to ask them if they want to navigate in "night mode". As long as the user doesn't deny the prompt (by clicking on the "Ignore" button), they honor the user's OS-setting, and apply a custom dark theme:

Terra shows a prompt to the user asking if they want to navigate in dark mode after detecting that they prefer dark in their devices.

As a complement of this strategy they provide additional configuration options in the "settings" screen, where the user can decide if they explicitly prefer "light", "dark", or want to rely on the underlying device settings.

Terra's themes configurations allow users to choose between "Dark" and "Light" themes or rely on the device's settings.

This is how Terra's "Night Mode" looks like:

Terra's dark theme, "Night Mode".

Measuring the impact of Terra's dark theme #

To measure the impact of the dark theme, Terra took the group of users that have the "Prefer Dark" setting turned on in their devices and compared engagement metrics when showing a "Light" vs. a "DarK" theme. Here are the results for mobile (Android) and desktop (Windows):

Mobile (Android) #

While bounce rates remained similar, pages and sessions almost doubled (from 2.47 to 5.24) when users were exposed to a dark theme:

Display Mode	Bounce Rate	Pages Per Session
Prefers Light	26.91%	2.47
Prefers Dark	23.91%	5.24

2_X

More pages per session

Desktop (Windows) #

Both metrics improved when showing a dark theme: bounce rates went from 27.25% to 10.82% and pages per session almost tripled (from 3.7 to 9.99).

Display Mode	Bounce Rate	Pages Per Session
Prefers Light	27.5%	3.7
Prefers Dark	10.82%	9.99

60_%

Reduction in Bounce Rates

170_%

More pages per session

Based on this data, Terra could confirm the benefits for the users from implementing a dark theme, and has decided to continue maintaining it as a core feature of the site.

Conclusion #

Dark Mode is a preference that users can turn on in their devices to change the style of the screens into dark themes. This technique has reported benefits from the user experience and for different aspects of the user's devices such as saving battery life.

In this article we saw how providing a custom dark theme improved engagement metrics for the group of Terra's users that have the preferred dark mode setting turned on in their devices.

For companies with the resources to implement an alternative dark theme this is the recommended approach. For those that don't have the time to invest in such a feature, Chrome is starting to roll out an Auto Dark Mode feature.

Building multiple Progressive Web Apps on the same domain

2021-06-02T00:00:00Z

In the Progressive Web Apps in multi-origin sites blog post, Demian discussed the challenges that sites built on multiple origins face when trying to build a single Progressive Web App that encompasses all of them.

An example of this type of site architecture is a ecommerce site where:

The home page is at https://www.example.com.
The category pages are hosted at https://category.example.com.
The product detail pages at https://product.example.com.

As discussed in the article, the same-origin policy imposes several restrictions, preventing the sharing of service workers, caches, and permissions across origins. For that reason, we strongly recommend avoiding this type of configuration and for those that already have sites built in this way, to consider migrating to a single origin site architecture whenever possible.

Avoid using different origins for site sections of the same site when trying to build a unified Progresive Web App.

In this post, we take a look at the opposite case: instead of a single PWA across different origins we'll analyze the case of companies that want to provide multiple PWAs, taking advantage of the same domain name, and make the user aware that those PWAs belong to the same organization or service.

As you might have noticed, we are using different, but interrelated terms, like domains and origins. Before moving forward, let's review these concepts.

Technical terms #

Domain: Any sequence of labels as defined in the Domain Name System (DNS). For example: com and example.com are domains.
Hostname: A DNS entry that resolves to at least one IP address. For example: www.example.com would be a hostname, example.com could be a hostname if it had an IP address, and com would never resolve to an IP address and so it could never be a hostname.
Origin: A combination of a scheme, hostname and (optionally) port. For example, https://www.example.com:443 is an origin.

As its name implies, same-origin policy imposes restrictions on origins, so we'll mostly refer to the term throughout the article. Nevertheless, we'll use "domains" or "subdomains" from time to time, to describe the technique being used, in order to create the different "origins".

In some cases, you might want to build independent apps, but still identify them as belonging to the same organization or "brand". Reusing the same domain name is a good way of establishing that relationship. For example:

An ecommerce site wants to create a standalone experience to let sellers manage their inventory, while making sure they understand that it belongs to the main website where the users buy products.
A sports news site wants to build a specific app for a major sporting event, to let users receive stats about their favorite competitions via notifications, and install it as a Progressive Web App, while making sure that users recognize it as an app built by the news company.
A company wants to build separate chat, mail, and calendar apps and wants them to work as individual apps, tied to the company's name.

Company that owns example.com wants to provide three independent apps or PWAs, using the same domain name to establish the relationship between them.

Using separate origins #

The recommended approach in cases like these is for each conceptually distinct app live on its own origin.

If you want to use the same domain name inside all of them, you can do that by using subdomains. For example, a company that provides multiple internet apps or services can host a mail app at https://mail.example.com and a calendar app at https://calendar.example.com, while offering the main service of their business at https://www.example.com. Another example is a sports site that wants to create an independent app completely dedicated to an important sports event, like a football championship at https://footballcup.example.com, that users can install and use independently of the main sport site, hosted at https://www.example.com. This approach might also be useful for platforms that let customers create independent apps of their own under the company's brand. For example, an app that lets merchants create their own PWAs at https://merchant1.example.com, https://merchant2.example.com, etc.

Using different origins ensures isolation between the apps, which means that each of them can manage different browser features independently, including:

Installability: Each app has its own Manifest and provides its own installable experience.
Storage: Each app has its own caches, local storage, and basically all forms of device-local storage, without sharing them with the others.
Service Workers: Each app has its own service worker for the registered scopes.
Permissions: Permissions are also scoped by origins. Thanks to that, users will know exactly which service they are giving permissions for, and features like notifications will be properly attributed to each app.

Creating such a degree of isolation is the most desirable in the use case of multiple, independent PWAs, so we strongly recommend this approach.

If apps on subdomains want to share local data with each other they will still be able to do it via cookies, or for more advanced scenarios they could consider synchronizing the storage through a server.

Building different PWAs in distinct origins, by using subdomains is a good practice.

Using the same origin #

The second approach is building the different PWAs on the same origin. This includes the following scenarios:

Non-overlapping paths #

Multiple PWAs or conceptual "web apps", hosted on the same origin, with non-overlapping paths. For example:

https://example.com/app1/
https://example.com/app2/

Overlapping/nested paths #

Multiple PWAs on the same origin, one of whose scope is nested inside the other:

https://example.com/ (the "outer app")
https://example.com/app/ (the "inner app")

The service worker API and manifest format allow you to do either of the above, using path-level scoping. However, in both cases, using the same origin presents many problems and limitations, the root of which stems from the fact that the browser won't fully consider these to be distinct "apps", therefore this approach is discouraged.

Using paths (overlapping or not) to provide two independent PWAs (“app1”, “app2”) under the same origin is discouraged.

In the next section, we analyze these challenges in more detail, and what can be done, if using separate origins is not an option.

Challenges for multiple, same-origin PWAs #

Here are some practical issues common to both same-origin approaches:

Storage: Cookies, local storage, and all forms of device-local storage are shared between apps. For that reason, if the user decides to wipe local data for one app, it will wipe all the data from the origin; there's no way to do this for a single app. Note that Chrome and some other browsers will actively prompt users to wipe local data when uninstalling one of the apps, and this will affect data for the other apps on the origin as well. Another issue is that apps will also have to share their storage quota which means if either of them takes up too much space, the other will be negatively impacted.
Permissions: Permissions are tied to the origin. That means if the user grants a permission to one app, it will apply to all apps on that origin simultaneously. That may sound like a good thing (not having to ask for a permission multiple times), but remember: if the user blocks permission to one app, it will prevent the others from requesting that permission or using that feature.
User settings: Settings are also set per-origin. For example, if two apps have different font sizes, and the user wants to adjust the zoom in only one of them to compensate for it, they won't be able to do it without applying the setting to the other apps as well.

These challenges make it difficult to encourage this approach. Nevertheless, if you can't use a separate origin (e.g. a subdomain), as discussed in the Using separate origins section, from the two same-origin options we presented, using non-overlapping paths is strongly recommended, over overlapping/nested paths.

As mentioned, the challenges discussed in this section are common to both same-origin approaches. In the next section we'll go deeper into the details of why using overlapping/nested paths is the least recommended strategy.

Additional challenges for overlapping/nested paths #

The additional issue with overlapping/nested paths approach (where https://example.com/ is the outer app and https://example.com/app/ is the inner app), is that all URLs in the inner app will actually be considered part of both the outer app and the inner app.

In practice this presents the following issues:

Installation Promotion: If the user visits the inner app (for example, in a web browser), when the outer app is already installed in the user's device, the browser won't show the install promotional banners, and the BeforeInstallPrompt event won't be triggered. The reason is that the browser will check and see whether the current page belongs to an app that's already installed, and it will conclude that it is. The workaround for this is to install the inner app manually (via "Create Shortcut" browser menu option), or to install the inner app first, before the outer app.
Notification and the Badging API: If the outer app is installed but the inner app is not, notifications and badges coming from the inner app will be erroneously attributed to the outer app (which is the nearest enclosing scope of an installed app). This feature works properly in the case where both apps are installed on the user's device.
Link Capturing: The outer app may capture URLs that belong to the inner app. This is especially likely if the outer app is installed but the inner app isn't. Similarly, links within the outer app that link to the inner app will not link capture into the inner app, since they are considered to be within the outer app's scope. Additionally, on ChromeOS and Android, if these apps are added to the Play Store (as Trusted Web Activities), the outer app will capture all links. Even if the inner app is installed, the OS will still offer the user the choice of opening them in the outer app.

Conclusion #

In this article we looked at different ways in which developers can build multiple Progressive Web Apps related to each other within the same domain.

In summary, we strongly recommend using a different origin (e.g. by using subdomains) to host independent PWAs. Hosting them in the same origin presents many challenges, mainly because the browser won't fully consider these to be distinct apps.

Separate origins: Recommended
Same origin, non-overlapping paths: Not recommended
Same origin, overlapping/nested paths: Strongly not recommended

If it's not possible to use different origins, using non-overlapping paths (e.g. https://example.com/app1/ and https://example.com/app2/ it's strongly recommended over using overlapping or nested paths, like https://example.com/ (for the outer app) and https://example.com/app/ (for the inner app).

Additional resources #

Progressive Web Apps in multi-origin sites

With many thanks for their technical reviews and suggestions: Joe Medley, Dominick Ng, Alan Cutter, Daniel Murphy, Penny McLachlan, Thomas Steiner and Darwin Huang

Photo by Tim Mossholder on Unsplash

Broadcast updates to pages with service workers

2020-12-08T00:00:00Z

In some scenarios the service worker might need to proactively communicate with any of the active tabs it controls to inform of a certain event. Examples include:

Informing the page when a new version of the service worker has been installed, so that the page can show an "Update to refresh" button to the user to access the new functionality immediately.
Letting the user know about a change on cached data that took place on the service worker side, by showing an indication, like: "The app is now ready to work offline", or "New version of the content available".

We'll call these types of use cases where the service worker doesn't need to receive a message from the page to start a communication "broadcast updates". In this guide we'll review different ways of implementing this type of communication between pages and service workers, by using standard browser APIs and the Workbox library.

Production cases #

Tinder #

Tinder PWA uses workbox-window to listen to important service worker lifecycle moments from the page ("installed", "controlled" and "activated"). That way when a new service worker comes into play, it shows an "Update Available" banner, so that they can refresh the PWA and access the latest features:

In the Tinder PWA, the service worker tells the page that a new version is ready, and the page shows users a "Update Available" banner.

Squoosh #

In the Squoosh PWA, when the service worker has cached all of the necessary assets to make it work offline, it sends a message to the page to show a "Ready to work offline" toast, letting the user know about the feature:

In the Squoosh PWA the service worker broadcasts an update to the page when cache is ready, and the page displays "Ready to work offline" toast.

Using Workbox #

Listen to service worker lifecycle events #

workbox-window provides a straightforward interface to listen to important service worker lifecycle events. Under the hood, the library uses client-side APIs like updatefound and statechange and provides higher level event listeners in the workbox-window object, making it easier for the user to consume these events.

The following page code lets you detect every time a new version of the service worker is installed, so you can communicate it to the user:

const wb = new Workbox('/sw.js');

wb.addEventListener('installed', (event) => {
  if (event.isUpdate) {
    // Show "Update App" banner
  }
});

wb.register();

Inform the page of changes in cache data #

The Workbox package workbox-broadcast-update provides a standard way of notifying window clients that a cached response has been updated. This is most commonly used along with the StaleWhileRevalidate strategy.

To broadcast updates add a broadcastUpdate.BroadcastUpdatePlugin to your strategy options in the service worker side:

import {registerRoute} from 'workbox-routing';
import {StaleWhileRevalidate} from 'workbox-strategies';
import {BroadcastUpdatePlugin} from 'workbox-broadcast-update';

registerRoute(
  ({url}) => url.pathname.startsWith('/api/'),
  new StaleWhileRevalidate({
    plugins: [
      new BroadcastUpdatePlugin(),
    ],
  })
);

In your web app, you can listen for these events like so:

navigator.serviceWorker.addEventListener('message', async (event) => {
  // Optional: ensure the message came from workbox-broadcast-update
  if (event.data.meta === 'workbox-broadcast-update') {
    const {cacheName, updatedUrl} = event.data.payload;

    // Do something with cacheName and updatedUrl.
    // For example, get the cached content and update
    // the content on the page.
    const cache = await caches.open(cacheName);
    const updatedResponse = await cache.match(updatedUrl);
    const updatedText = await updatedResponse.text();
  }
});

Using browser APIs #

If the functionality that Workbox provides is not enough for your needs, use the following browser APIs to implement "broadcast updates":

Broadcast Channel API #

The service worker creates a BroadcastChannel object and starts sending messages to it. Any context (e.g. page) interested in receiving these messages can instantiate a BroadcastChannel object and implement a message handler to receive messages.

To inform the page when a new service worker is installed, use the following code:

// Create Broadcast Channel to send messages to the page
const broadcast = new BroadcastChannel('sw-update-channel');

self.addEventListener('install', function (event) {
  // Inform the page every time a new service worker is installed
  broadcast.postMessage({type: 'CRITICAL_SW_UPDATE'});
});

The page listens to these events by subscribing to the sw-update-channel:

// Create Broadcast Channel and listen to messages sent to it
const broadcast = new BroadcastChannel('sw-update-channel');

broadcast.onmessage = (event) => {
  if (event.data && event.data.type === 'CRITICAL_SW_UPDATE') {
    // Show "update to refresh" banner to the user.
  }
};

This is a simple technique, but its limitation is browser support: at the moment of this writing, Safari doesn't support this API.

Client API #

The Client API provides a straightforward way of communicating with multiple clients from the service worker by iterating over an array of Client objects.

Use the following service worker code to send a message to the last focused tab:

// Obtain an array of Window client objects
self.clients.matchAll(options).then(function (clients) {
  if (clients && clients.length) {
    // Respond to last focused tab
    clients[0].postMessage({type: 'MSG_ID'});
  }
});

The page implements a message handler to intercept these messages:

// Listen to messages
navigator.serviceWorker.onmessage = (event) => {
     if (event.data && event.data.type === 'MSG_ID') {
         // Process response
   }
};

Client API is a great option for cases like broadcasting information to multiple active tabs. The API is supported by all major browsers, but not all of its methods are. Check browser support before using it.

Message Channel #

Message Channel requires an initial configuration step, by passing a port from the page to the service worker, to establish a communication channel between them. The page instantiates a MessageChannel object and passes a port to the service worker, via the postMessage() interface:

const messageChannel = new MessageChannel();

// Init port
navigator.serviceWorker.controller.postMessage({type: 'PORT_INITIALIZATION'}, [
  messageChannel.port2,
]);

The page listens to messages by implementing an "onmessage" handler on that port:

// Listen to messages
messageChannel.port1.onmessage = (event) => {
  // Process message
};

The service worker receives the port and saves a reference to it:

// Initialize
let communicationPort;

self.addEventListener('message', (event) => {
  if (event.data && event.data.type === 'PORT_INITIALIZATION') {
    communicationPort = event.ports[0];
  }
});

From that point it can send messages to the page, by calling postMessage() in the reference to the port:

// Communicate
communicationPort.postMessage({type: 'MSG_ID' });

MessageChannel might be more complex to implement, due to the need of initializing ports, but it's supported by all major browsers.

Next steps #

In this guide we explored one particular case of Window to service worker communication: "broadcast updates". The examples explored include listening to important service worker lifecycle events, and communicating to the page about changes in content or cached data. You can think of more interesting use cases where the service worker proactively communicates with the page, without receiving any message previously.

For more patterns of Window and service worker communication check out:

Imperative caching guide: Calling a service worker from the page to cache resources in advance (e.g. in prefetching scenarios).
Two-way communication: Delegating a task to a service worker (e.g. a heavy download), and keeping the page informed on the progress.

Additional resources #

Imperative caching guide

2020-12-08T00:00:00Z

Some websites might need to communicate to the service worker without the need of being informed about the result. Here are some examples:

A page sends the service worker a list of URLs to prefetch, so that, when the user clicks on a link the document or page subresources are already available in the cache, making subsequent navigation much faster.
The page asks the service worker to retrieve and cache a set of top articles, to have them available for offline purposes.

Delegating these types of non-critical tasks to the service worker has the benefit of freeing up the main thread for better handling more pressing tasks such as responding to user interactions.

In this guide we'll explore how to implement a one-way communication technique from the page to the service worker by using standard browser APIs and the Workbox library. We'll call these types of use cases imperative caching.

Production case #

1-800-Flowers.com implemented imperative caching (prefetching) with service workers via postMessage() to prefetch the top items in category pages to speed up subsequent navigation to product detail pages.

They use a mixed approach to decide which items to prefetch:

At page load time they ask the servicer worker to retrieve the JSON data for the top 9 items, and add the resulting response objects to the cache.
For the remaining items, they listen to the mouseover event, so that, when a user moves the cursor on top of an item, they can trigger a fetch for the resource on "demand".

They use the Cache API to store JSON responses:

Prefetching JSON product data from product listing pages in 1-800Flowers.com.

When the user clicks on an item, the JSON data associated with it can be picked up from the cache, without the need of going to the network, making the navigation faster.

Using Workbox #

Workbox provides an easy way to send messages to a service worker, via the workbox-window package, a set of modules that are intended to run in the window context. They're a complement to the other Workbox packages that run in the service worker.

To communicate the page with the service worker, first obtain a Workbox object reference to the registered service worker:

const wb = new Workbox('/sw.js');
wb.register();

Then you can directly send the message declaratively, without the hassle of the getting the registration, checking for activation, or thinking about the underlying communication API:

wb.messageSW({"type": "PREFETCH", "payload": {"urls": ["/data1.json", "data2.json"]}}); });

The service worker implements a message handler to listen to these messages. It can optionally return a response, although, in cases like these, it's not necessary:

self.addEventListener('message', (event) => {
  if (event.data && event.data.type === 'PREFETCH') {
    // do something
  }
});

Using browser APIs #

If the Workbox library is not enough for your needs, here is how you can implement window to service worker communication, using browser APIs.

The postMessage API can be used to establish a one-way communication mechanism from the page to the service worker.

The page calls postMessage() on the service worker interface:

navigator.serviceWorker.controller.postMessage({
  type: 'MSG_ID',
  payload: 'some data to perform the task',
});

The service worker implements a message handler to listen to these messages.

self.addEventListener('message', (event) => {
  if (event.data && event.data.type === MSG_ID) {
    // do something
  }
});

The {type : 'MSG_ID'} attribute is not absolutely required, but it is one way to allow the page to send different types of instructions to the service worker (that is, 'to prefetch' vs. 'to clear storage'). The service worker can branch into different execution paths based on this flag.

If the operation was successful, the user will be able to get the benefits from it but, if not, it won't alter the main user flow. For example, when 1-800-Flowers.com attempts to precache, the page doesn't need to know whether the service worker succeeded. If it does, then the user will enjoy a faster navigation. If it doesn't the page still needs to navigate to the new page. It's just going to take a little longer.

A simple prefetching example #

One of the most common applications of imperative caching is prefetching, meaning fetching resources for a given URL, before the user moves to it, in order to speed up navigation.

There are different ways of implementing prefetching in sites:

Using Link prefetch tags in pages: resources are kept in the browser cache for five minutes, after which the normal Cache-Control rules for the resource apply.
Complementing the previous technique with a runtime caching strategy in the service worker to extend the lifetime of the prefetch resource beyond this limit.

For relatively simple prefetching scenarios, like prefetching documents, or specific assets (JS, CSS, etc.), those techniques are the best approach.

If additional logic is required, for example, parsing the prefetch resource (a JSON file or page) in order to fetch its internal URLs, it's more appropriate to delegate this task entirely to the service worker.

Delegating these types of operations to the service worker has the following advantages:

Offloading the heavy lifting of fetching and post-fetch processing (which will be introduced later) to a secondary thread. By doing this, it frees the main thread to handle more important tasks such as responding to user interactions.
Allowing multiple clients (e.g. tabs) to reuse a common functionality, and even calling the service simultaneously without blocking the main thread.

Prefetch product detail pages #

First use postMessage() on the service worker interface and pass an array of URLs to cache:

navigator.serviceWorker.controller.postMessage({
  type: 'PREFETCH',
  payload: {
    urls: [
      'www.exmaple.com/apis/data_1.json',
      'www.exmaple.com/apis/data_2.json',
    ],
  },
});

In the service worker, implement a message handler to intercept and process messages sent by any active tab:

addEventListener('message', (event) => {
  let data = event.data;
  if (data && data.type === 'PREFETCH') {
    let urls = data.payload.urls;
    for (let i in urls) {
      fetchAsync(urls[i]);
    }
  }
});

In the previous code we introduced a small helper function called fetchAsync() to iterate on the array of URLs and issue a fetch request for each of them:

async function fetchAsync(url) {
  // await response of fetch call
  let prefetched = await fetch(url);
  // (optionally) cache resources in the service worker storage
}

When the response is obtained you can rely on the caching headers of the resource. In many cases though, like in product detail pages, resources are not cached (which means, they have a Cache-control header of no-cache). In cases like these you can override this behavior, by storing the fetched resource in the service worker cache. This has the added benefit of allowing the file to be served in offline scenarios.

Beyond JSON data #

Once the JSON data is fetched from a server endpoint, it often contains other URLs that are also worth prefetching, such as an image or other endpoint data that are associated with this first-level data.

Let's say that in our example, the JSON data returned is the information of a grocery shopping site:

{
  "productName": "banana",
  "productPic": "https://cdn.example.com/product_images/banana.jpeg",
  "unitPrice": "1.99"
 }

Modify the fetchAsync() code to iterate over the list of products and cache the hero image for each of them:

async function fetchAsync(url, postProcess) {
  // await response of fetch call
  let prefetched = await fetch(url);

  //(optionally) cache resource in the service worker cache

  // carry out the post fetch process if supplied
  if (postProcess) {
    await postProcess(prefetched);
  }
}

async function postProcess(prefetched) {
  let productJson = await prefetched.json();
  if (productJson && productJson.product_pic) {
    fetchAsync(productJson.product_pic);
  }
}

You can add some exception handling around this code for situations like 404s. But the beauty of using a service worker to prefetch is that it can fail without much consequence to the page and the main thread. You may also have more elaborate logic in the post-processing of the prefetched content, making it more flexible and decoupled with the data it's handling. The sky's the limit.

Conclusion #

In this article, we covered a common use case of one-way communication between page and service worker: imperative caching. The examples discussed are only meant for demonstrating one way of using this pattern and the same approach can be applied to other use cases as well, for example, caching top articles on demand for offline consumption, bookmarking, and others.

For more patterns of page and service worker communication, check out:

Broadcast updates: Calling the page from the service worker to inform about important updates (e.g. a new version of the webapp is available).
Two-way communication: Delegating a task to a service worker (e.g. a heavy download), and keeping the page informed on the progress.

Two-way communication with service workers

2020-12-08T00:00:00Z

In some cases, a web app might need to establish a two-way communication channel between the page and the service worker.

For example: in a podcast PWA one could build a feature to let the user download episodes for offline consumption and allow the service worker to keep the page regularly informed about the progress, so the main thread can update the UI.

In this guide we'll explore the different ways of implementing a two-way communication between the Window and service worker context, by exploring different APIs, the Workbox library, as well as some advanced cases.

Using Workbox #

workbox-window is a set of modules of the Workbox library that are intended to run in the window context. The Workbox class provides a messageSW() method to send a message to the instance's registered service worker and await a response.

The following page code creates a new Workbox instance and sends a message to the service worker to obtain its version:

const wb = new Workbox('/sw.js');
wb.register();

const swVersion = await wb.messageSW({type: 'GET_VERSION'});
console.log('Service Worker version:', swVersion);

The service worker implements a message listener on the other end, and responds to the registered service worker:

const SW_VERSION = '1.0.0';

self.addEventListener('message', (event) => {
  if (event.data.type === 'GET_VERSION') {
    event.ports[0].postMessage(SW_VERSION);
  }
});

Under the hood the library uses a browser API that we'll review in the next section: Message Channel, but abstracts many implementation details, making it easier to use, while leveraging the wide browser support this API has.

Using Browser APIs #

If the Workbox library is not enough for your needs, there are several lower-level APIs available to implement "two-way" communication between pages and service workers. They have some similarities and differences:

Similarities:

In all cases the communication starts on one end via the postMessage() interface and is received on the other end by implementing a message handler.
In practice, all the available APIs allow us to implement the same use cases, but some of them might simplify development in some scenarios.

Differences:

They have different ways of identifying the other side of the communication: some of them use an explicit reference to the other context, while others can communicate implicitly via a proxy object instantiated on each side.
Browser support varies among them.

Broadcast Channel API #

Browser support

Chrome 54, Supported 54
Firefox 38, Supported 38
Edge 79, Supported 79
Safari 15.4, Supported 15.4

Source

The Broadcast Channel API allows basic communication between browsing contexts via BroadcastChannel objects.

To implement it, first, each context has to instantiate a BroadcastChannel object with the same ID and send and receive messages from it:

const broadcast = new BroadcastChannel('channel-123');

The BroadcastChannel object exposes a postMessage() interface to send a message to any listening context:

//send message
broadcast.postMessage({ type: 'MSG_ID', });

Any browser context can listen to messages via the onmessage method of the BroadcastChannel object:

//listen to messages
broadcast.onmessage = (event) => {
  if (event.data && event.data.type === 'MSG_ID') {
    //process message...
  }
};

As seen, there's no explicit reference to a particular context, so there's no need of obtaining a reference first to the service worker or any particular client.

The disadvantage is that, at the moment of this writing, the API has support from Chrome, Firefox and Edge, but other browsers, like Safari, don't support it yet.

Client API #

Browser support

Chrome 40, Supported 40
Firefox 44, Supported 44
Edge 17, Supported 17
Safari 11.1, Supported 11.1

Source

The Client API allows you to obtain a reference to all the WindowClient objects representing the active tabs that the service worker is controlling.

Since the page is controlled by a single service worker, it listens to and sends messages to the active service worker directly via the serviceWorker interface:

//send message
navigator.serviceWorker.controller.postMessage({
  type: 'MSG_ID',
});

//listen to messages
navigator.serviceWorker.onmessage = (event) => {
  if (event.data && event.data.type === 'MSG_ID') {
    //process response
  }
};

Similarly, the service worker listens to messages by implementing an onmessage listener:

//listen to messages
self.addEventListener('message', (event) => {
  if (event.data && event.data.type === 'MSG_ID') {
    //Process message
  }
});

To communicate back with any of its clients, the service worker obtains an array of WindowClient objects by executing methods such as Clients.matchAll() and Clients.get(). Then it can postMessage() any of them:

//Obtain an array of Window client objects
self.clients.matchAll(options).then(function (clients) {
  if (clients && clients.length) {
    //Respond to last focused tab
    clients[0].postMessage({type: 'MSG_ID'});
  }
});

Client API is a good option to communicate easily with all the active tabs from a service worker in a relatively straightforward way. The API is supported by all major browsers, but not all its methods might be available, so make sure to check browser support before implementing it in your site.

Message Channel #

Browser support

Chrome 2, Supported 2
Firefox 41, Supported 41
Edge 12, Supported 12
Safari 5, Supported 5

Source

Message Channel requires defining and passing a port from one context to another to establish a two-way communication channel.

To initialize the channel, the page instantiates a MessageChannel object and uses it to send a port to the registered service worker. The page also implements an onmessage listener on it to receive messages from the other context:

const messageChannel = new MessageChannel();

//Init port
navigator.serviceWorker.controller.postMessage({type: 'PORT_INITIALIZATION'}, [
  messageChannel.port2,
]);

//Listen to messages
messageChannel.port1.onmessage = (event) => {
  // Process message
};

The service worker receives the port, saves a reference to it and uses it to send a message to the other side:

let communicationPort;

//Save reference to port
self.addEventListener('message', (event) => {
  if (event.data && event.data.type === 'PORT_INITIALIZATION') {
    communicationPort = event.ports[0];
  }
});

//Send messages
communicationPort.postMessage({type: 'MSG_ID'});

MessageChannel is currently supported by all major browsers.

Advanced APIs: Background Sync and Background Fetch #

In this guide we explored ways of implementing two-way communication techniques, for relatively simple cases, like passing a string message describing the operation to perform, or a list of URLs to cache from one context to the other. In this section we'll explore two APIs to handle specific scenarios: lack of connectivity and long downloads.

Background Sync #

Browser support

Chrome 49, Supported 49
Firefox, Not supported
Edge 79, Supported 79
Safari, Not supported

Source

A chat app might want to make sure that messages are never lost due to bad connectivity. The Background Sync API lets you defer actions to be retried when the user has stable connectivity. This is useful for ensuring that whatever the user wants to send, is actually sent.

Instead of the postMessage() interface, the page registers a sync:

navigator.serviceWorker.ready.then(function (swRegistration) {
  return swRegistration.sync.register('myFirstSync');
});

The service worker then listens for the sync event to process the message:

self.addEventListener('sync', function (event) {
  if (event.tag == 'myFirstSync') {
    event.waitUntil(doSomeStuff());
  }
});

The function doSomeStuff() should return a promise indicating the success/failure of whatever it's trying to do. If it fulfills, the sync is complete. If it fails, another sync will be scheduled to retry. Retry syncs also wait for connectivity, and employ an exponential back-off.

Once the operation has been performed, the service worker can then communicate back with the page to update the UI, by using any of the communication APIs explored earlier.

Google search uses Background Sync to persist failed queries due to bad connectivity, and retry them later when the user is online. Once the operation is performed, they communicate the result to the user via a web push notification:

Background Fetch #

Browser support

Chrome 74, Supported 74
Firefox, Not supported
Edge 79, Supported 79
Safari, Not supported

Source

For relatively short bits of work like sending a message, or a list of URLs to cache, the options explored so far are a good choice. If the task takes too long the browser will kill the service worker, otherwise it's a risk to the user's privacy and battery.

The Background Fetch API allows you to offload a long task to a service worker, like downloading movies, podcasts, or levels of a game.

To communicate to the service worker from the page, use backgroundFetch.fetch, instead of postMessage():

navigator.serviceWorker.ready.then(async (swReg) => {
  const bgFetch = await swReg.backgroundFetch.fetch(
    'my-fetch',
    ['/ep-5.mp3', 'ep-5-artwork.jpg'],
    {
      title: 'Episode 5: Interesting things.',
      icons: [
        {
          sizes: '300x300',
          src: '/ep-5-icon.png',
          type: 'image/png',
        },
      ],
      downloadTotal: 60 * 1024 * 1024,
    },
  );
});

The BackgroundFetchRegistration object allows the page listen to the progress event to follow the progress of the download:

bgFetch.addEventListener('progress', () => {
  // If we didn't provide a total, we can't provide a %.
  if (!bgFetch.downloadTotal) return;

  const percent = Math.round(
    (bgFetch.downloaded / bgFetch.downloadTotal) * 100,
  );
  console.log(`Download progress: ${percent}%`);
});

The UI is updated to indicate the progress of a download (left). Thanks to service workers, the operation can continue running when all tabs have been closed (right).

Next steps #

In this guide we explored the most general case of communication between page and service workers (bidirectional communication).

Many times, one might need only one context to communicate with the other, without receiving a response. Check out the following guides for guidance how to implement unidirectional techniques in your pages from and to the service worker, along with use cases and production examples:

Imperative caching guide: Calling a service worker from the page to cache resources in advance (e.g. in prefetching scenarios).
Broadcast updates: Calling the page from the service worker to inform about important updates (e.g. a new version of the webapp is available).

Workers overview

2020-12-08T00:00:00Z

This overview explains how web workers and service workers can improve the performance of your website, and when to use a web worker versus a service worker. Check out the rest of this series for specific patterns of window and service worker communication.

How workers can improve your website #

The browser uses a single thread (the main thread) to run all the JavaScript in a web page, as well as to perform tasks like rendering the page and performing garbage collection. Running excessive JavaScript code can block the main thread, delaying the browser from performing these tasks and leading to a poor user experience.

In iOS/Android application development, a common pattern to ensure that the app's main thread remains free to respond to user events is to offload operations to additional threads. In fact, in the latest versions of Android, blocking the main thread for too long leads to an app crash.

On the web, JavaScript was designed around the concept of a single thread, and lacks capabilities needed to implement a multithreading model like the one apps have, like shared memory.

Despite these limitations, a similar pattern can be achieved in the web by using workers to run scripts in background threads, allowing them to perform tasks without interfering with the main thread. Workers are an entire JavaScript scope running on a separate thread, without any shared memory.

In this post you'll learn about two different types of workers (web workers and service workers), their similarities and differences, and the most common patterns for using them in production websites.

Web workers and service workers #

Similarities #

Web workers and service workers are two types of workers available to websites. They have some things in common:

Both run in a secondary thread, allowing JavaScript code to execute without blocking the main thread and the user interface.
They don't have access to the Window and Document objects, so they can't interact with the DOM directly, and they have limited access to browser APIs.

Differences #

One might think that most things that can be delegated to a web worker can be done in a service worker and vice versa, but there are important differences between them:

Unlike web workers, service workers allow you to intercept network requests (via the fetch event) and to listen for Push API events in the background (via the push event).
A page can spawn multiple web workers, but a single service worker controls all the active tabs under the scope it was registered with.
The lifespan of the web worker is tightly coupled to the tab it belongs to, while the service worker's lifecycle is independent of it. For that reason, closing the tab where a web worker is running will terminate it, while a service worker can continue running in the background, even when the site doesn't have any active tabs open.

Use cases #

The differences between both types of workers suggest in which situations one might want to use one or the other:

Use cases for web workers are more commonly related to offloading work (like heavy computations) to a secondary thread, to avoid blocking the UI.

Example: the team that built the videogame PROXX wanted to leave the main thread as free as possible to take care of user input and animations. To achieve that, they used web workers to run the game logic and state maintenance on a separate thread.

Service workers tasks are generally more related to acting as a network proxy, handling background tasks, and things like caching and offline.

Example: In a podcast PWA, one might want to allow users to download complete episodes to listen to them while offline. A service worker, and, in particular, the Background Fetch API can be used to that end. That way, if the user closes the tab while the episode is downloading, the task doesn't have to be interrupted.

The UI is updated to indicate the progress of a download (left). Thanks to service workers, the operation can continue running when all tabs have been closed (right).

Tools and libraries #

Window and worker communication can be implemented by using different lower level APIs. Fortunately, there are libraries that abstract this process, taking care of the most common use cases. In this section, we'll cover two of them that take care of window to web workers and service workers respectively: Comlink and Workbox.

Comlink #

Comlink is a small (1.6k) RPC library that takes care of many underlying details when building websites that use Web Workers. It has been used in websites like PROXX and Squoosh. A summary of its motivations and code samples can be found here.

Workbox #

Workbox is a popular library to build websites that use service workers. It packages a set of best practices around things like caching, offline, background synchronization, etc. The workbox-window module provides a convenient way to exchange messages between the service worker and the page.

Next steps #

The rest of this series focuses on patterns for window and service worker communication:

Imperative caching guide: Calling a service worker from the page to cache resources in advance (e.g. in prefetching scenarios).
Broadcast updates: Calling the page from the service worker to inform about important updates (e.g. a new version of the website is available).
Two-way communication: Delegating a task to a service worker (e.g. a heavy download), and keeping the page informed on the progress.

For patterns of window and web worker communication check out: Use web workers to run JavaScript off the browser's main thread.

How Mercado Libre optimized for Web Vitals (TBT/FID)

2020-09-21T00:00:00Z

Mercado Libre is the largest e-commerce and payments ecosystem in Latin America. It is present in 18 countries and is a market leader in Brazil, Mexico, and Argentina (based on unique visitors and pageviews).

Web performance has been a focus for the company for a long time, but they recently formed a team to monitor performance and apply optimizations across different parts of the site.

This article summarizes the work done by Guille Paz, Pablo Carminatti, and Oleh Burkhay from Mercado Libre's frontend architecture team to optimize one of the Core Web Vitals: First Input Delay (FID) and its lab proxy, Total Blocking Time (TBT).

90_%

Reduction in Max Potential FID in Lighthouse

9_%

More users perceiving FID as "Fast" in CrUX

Long tasks, First Input Delay, and Total Blocking Time #

Running expensive JavaScript code can lead to long tasks, which are those that run for more than 50ms in the browser's main thread.

FID (First Input Delay) measures the time from when a user first interacts with a page (e.g. when they click on a link) to the time when the browser is actually able to begin processing event handlers in response to that interaction. A site that executes expensive JavaScript code will likely have several long tasks, which will end up negatively impacting FID.

To provide a good user experience, sites should strive to have a First Input Delay of less than 100 milliseconds:

While Mercado Libre's site was performing well in most sections, they found in the Chrome User Experience Report that product detail pages had a poor FID. Based on that information, they decided to focus their efforts on improving the interactivity for product pages in the site.

Mobile and Desktop versions of a Mercado Libre product detail page.

These pages allow the user to perform complex interactions, so the goal was interactivity optimization, without interfering with valuable functionality.

Measure interactivity of product detail pages #

FID requires a real user and thus cannot be measured in the lab. However, the Total Blocking Time (TBT) metric is lab-measurable, correlates well with FID in the field, and also captures issues that affect interactivity.

In the following trace, for example, while the total time spent running tasks on the main thread is 560 ms, only 345 ms of that time is considered total blocking time (the sum of the portions of each task that exceeds 50ms):

Mercado Libre took TBT as a proxy metric in the lab, in order to measure and improve the interactivity of product detail pages in the real world.

Here's the general approach they took:

Use WebPageTest to determine exactly which scripts were keeping the main thread busy on a real device.
Use Lighthouse to determine the impact of the changes in Max Potential First Input Delay (Max Potential FID).

Use WebPageTest to visualize long tasks #

WebPageTest (WPT) is a web performance tool that allows you to run tests on real devices in different locations around the world.

Mercado Libre used WPT to reproduce the experience of their users by choosing a device type and location similar to real users. Specifically, they chose a Moto 4G device and Dulles, Virginia, because they wanted to approximate the experience of Mercado Libre users in Mexico. By observing the main thread view of WPT, Mercado Libre found that there were several consecutive long tasks blocking the main thread for 2 seconds:

Main thread view of Mercado Libre's product detail pages.

Analyzing the corresponding waterfall they found that a considerable part of those two seconds came from their analytics module. The main bundle size of the application was large (950KB) and took a long time to parse, compile, and execute.

Waterfall view of Mercado Libre's product detail pages.

Use Lighthouse to determine Max Potential FID #

Lighthouse doesn't allow you to choose between different devices and locations, but it's a very useful tool for diagnosing sites and obtaining performance recommendations.

When running Lighthouse on product detail pages, Mercado Libre found that the Max Potential FID was the only metric marked in red, with a value of 1710ms.

Based on this, Mercado Libre set a goal to improve their Max Potential FID score in a laboratory tool like Lighthouse and WebPageTest, under the assumption that these improvements would affect their real users, and therefore, show up in real user monitoring tools like the Chrome User Experience Report.

Optimize long tasks #

First iteration #

Based on the main thread trace, Mercado Libre set the goal of optimizing the two modules that were running expensive code.

They started optimizing the performance of the internal tracking module. This module contained a CPU-heavy task that wasn't critical for the module to work, and therefore could be safely removed. This led to a 2% reduction in JavaScript for the whole site.

After that they started to work on improving the general bundle size:

Mercado Libre used webpack-bundle-analyzer to detect opportunities for optimization:

Initially they were requiring the full Lodash module. This was replaced with a per-method require to load only a subset of Lodash instead of the whole library, and used in conjunction with lodash-webpack-plugin to shrink Lodash even further.

They also applied the following Babel optimizations:

Using @babel/plugin-transform-runtime to reuse Babel's helpers throughout the code, and reduce the size of the bundle considerably.
Using babel-plugin-search-and-replace to replace tokens at build time, in order to remove a large configuration file inside the main bundle.
Adding babel-plugin-transform-react-remove-prop-types to save some extra bytes by removing the prop types.

As a result of these optimizations, the bundle size was reduced by approximately 16%.

Measure impact #

The changes lowered Mercado Libre's consecutive long tasks from two seconds to one second:

In the top waterfall of WPT there’s a long red bar (in the Page is Interactive row) between seconds 3 and 5. In the bottom waterfall, the bar has been broken into smaller pieces, occupying the main thread for shorter periods of time.

Lighthouse showed a 57% reduction in Max Potential First Input Delay:

Second iteration #

The team continued digging into long tasks in order to find subsequent improvements.

The Waterfall (not pictured) helped Mercado Libre identify which libraries were using the main thread heavily (Browser Main Thread row) and the Page is Interactive row clearly shows that this main thread activity is blocking interactivity.

Based on that information they decided to implement the following changes:

Continue reducing the main bundle size to optimize compile and parse time (e.g. by removing duplicate dependencies throughout the different modules).
Apply code splitting at component level, to divide JavaScript in smaller chunks and allow for smarter loading of the different components.
Defer component hydration to allow for a smarter use of the main thread. This technique is commonly referred to as partial hydration.

Measure impact #

The resulting WebPageTest trace showed even smaller chunks of JS execution:

And their Max Potential FID time in Lighthouse was reduced by an additional 60%:

Visualize progress for real users #

While laboratory testing tools like WebPageTest and Lighthouse are great for iterating on solutions during development, the true goal is to improve the experience for real users.

The Chrome User Experience Report provides user experience metrics for how real-world Chrome users experience popular destinations on the web. The data from the report can be obtained by running queries in BigQuery, PageSpeedInsights, or the CrUX API.

The CrUX dashboard is an easy way to visualize the progress of core metrics:

Mercado Libre's FID progress between Jan 2020 and April 2020. Before the optimization project, 82% of the users were perceiving FID as fast (below 100ms). After, more than 91% of the users were perceiving the metric as fast.

Next steps #

Web performance is never a finished task, and Mercado Libre understands the value these optimizations bring to their users. While they continue applying several optimizations across the site, including prefetching in product listing pages, image optimizations, and others, they continue adding improvements to product listing pages to reduce Total Blocking Time (TBT), and by proxy FID, even more. These optimizations include:

Iterating on the code splitting solution.
Improving the execution of third-party scripts.
Continuing improvements in asset bundling at the bundler level (webpack).

Mercado Libre has a holistic view of performance, so while they continue optimizing interactivity in the site, they have also started assessing opportunities for improvement on the other two current Core Web Vitals: LCP (Largest Contentful Paint) and CLS (Cumulative Layout Shift) even more.

Adaptive loading with service workers

2020-06-23T00:00:00Z

Users access websites through a wide variety of devices and network connections. Even in major cities, where mobile networks are fast and reliable, one can end up experiencing slower load times, for example, when commuting in the subway, in a car, or just when moving around. In regions like emerging markets, this phenomenon is even more common, not only due to unreliable networks, but also because devices tend to have less memory and CPU processing power.

Adaptive loading is a web performance pattern that lets you adapt your site based on the user's network and device conditions.

The adaptive loading pattern is made possible by service workers, the Network Information API, the Hardware Concurrency API, and the Device Memory API. In this guide we explore how you can use service workers and the Network Information API to achieve an adaptive loading strategy.

Production case #

Terra is one of the biggest media companies in Brazil. It has a large user base, coming from a wide variety of devices and networks.

To provide a more reliable experience to all their users, Terra combines service workers and the Network Information API to deliver lower quality images to users on 2G or 3G connections.

The company also found that the scripts and assets (like banners) loaded by ad networks were especially detrimental to users navigating in 3G or slower connections.

As is the case with many publishers, Terra serves AMP versions of their pages to users coming from search engines and other link sharing platforms. AMP pages are usually lightweight and help mitigate the impact of ads in performance by deprioritizing their load with respect to the main content of the page.

Taking that into consideration, Terra decided to start serving AMP versions of their pages not only to users coming from search engines, but also to those navigating their site in 3G connections or slower.

To achieve that, they use the Network Information API in the service worker to detect if the request comes from 3G or slower. If that's the case, they change the URL of the page to request the AMP version of the page instead.

Thanks to this technique, they send 70% less bytes to users on slower connections. The time spent in AMP pages is higher for 3G users and ads in AMP pages have a better CTR (click-through-rate) for that group.

Implement adaptive loading with Workbox #

In this section we'll explore how Workbox can be used to implement adaptive loading strategies.

Workbox provides several runtime caching strategies out of the box. They are used to indicate how the service worker generates a response after receiving a fetch event.

For example, in a Cache First strategy the Request will be fulfilled using the cached response (if available). If there isn't a cached response, the Request will be fulfilled by a network request and the response will be cached.

import {registerRoute} from 'workbox-routing';
import {CacheFirst} from 'workbox-strategies';

registerRoute(
  new RegExp('/img/'),
  new CacheFirst()
);

Caching strategies can be customized with Workbox plugins. These allow you to add additional behaviors by manipulating requests and responses during the lifecycle of a request. Workbox has several built-in plugins for common cases and APIs, but you can also define a custom plugin, and introduce some custom logic of your choice.

To achieve adapting loading, define a custom plugin, called, for example, adaptiveLoadingPlugin:

const adaptiveLoadingPlugin = {
  requestWillFetch: async ({request}) => {
    const urlParts = request.url.split('/');
    let imageQuality;

    switch (
      navigator && navigator.connection
        ? navigator.connection.effectiveType
        : ''
    ) {
      //...
      case '3g':
        imageQuality = 'q_30';
        break;
      //...
    }

    const newUrl = urlParts
      .splice(urlParts.length - 1, 0, imageQuality)
      .join('/')
      .replace('.jpg', '.png');
    const newRequest = new Request(newUrl.href, {headers: request.headers});

    return newRequest;
  },
};

The previous code does the following:

Implements a requestWillFetch() callback: This is called whenever a network request is about to be made, so you can alter the Request.
Checks the connection type, by using the Network Information API. Based on the status of the network, it creates a new URL part, indicating the quality of the image to fetch (e.g. q_30 for 3G users).
Creates a new URL based on the dynamic newPart value, and returns the new Request to be made, based on that URL.

Next, pass the plugin to a cacheFirst strategy containing a regular expression to match image URLs (e.g. /img/):

workbox.routing.registerRoute(
  new RegExp('/img/'),
  workbox.strategies.cacheFirst({
    cacheName: 'images',
    plugins: [
      adaptiveLoadingPlugin,
      workbox.expiration.Plugin({
        maxEntries: 50,
        purgeOnQuotaError: true,
      }),
    ],
  }),
);

As a result, when requests for images are intercepted, the runtime caching strategy will try to fulfill the request from the cache. If it's not available, it will run the logic in the plugin, to decide which image quality to fetch from the network.

Finally the response will be persisted in the cache, and sent back to the page.

Cloudinary Workbox Plugin #

Cloudinary, a video and image hosting service, has a Workbox Plugin that encapsulates the functionality explained in the previous section, making it even easier to implement.

The plugin is designed to work with the Workbox webpack plugin. To implement it, use the GenerateSW() class:

new workboxPlugin.GenerateSW({
  swDest: 'sw.js',
  importScripts: ['./cloudinaryPlugin.js'],
  runtimeCaching: [
    {
      urlPattern: new RegExp('^https://res.cloudinary.com/.*/image/upload/'),
      handler: 'CacheFirst',
      options: {
        cacheName: 'cloudinary-images',
        plugins: [
          {
            requestWillFetch: async ({request}) =>
              cloudinaryPlugin.requestWillFetch(request),
          },
        ],
      },
    },
  ],
});

The previous code does the following:

Uses the GenerateSW() class to configure webpack to generate a service worker in the destination indicated in swDest.
Imports the cloudinary plugin script.
Defines a Cache First runtime caching strategy for requests for images to the Cloudinary CDN.
Passes the Cloudinary Workbox Plugin to adjust the image quality according to the network conditions.

Explore more adaptive loading strategies #

You can go beyond this, by mapping device signals, like hardware concurrency and device memory to device categories and then serving different assets depending on the device type (low-, mid- or high-end).

App shell UX with service workers and streams

2020-06-23T00:00:00Z

Single-page app (SPA) is an architectural pattern in which the browser runs JavaScript code to update the existing page when the user visits a different section of the site, as opposed to loading an entire new page.

This means that the web app doesn't perform an actual page reload. The History API is used instead to navigate back and forth through the user's history and manipulate the contents of the history stack.

Using this type of architecture can provide an app shell UX that's fast, reliable, and usually consumes less data when navigating.

In multi-page apps (MPAs) each time a user navigates to a new URL, the browser progressively renders HTML specific to that page. This means a full page refresh every time you visit a new page.

While both are equally valid models to use, you might want to bring some of the benefits of the app shell UX of SPAs to your existing MPA site. In this article we'll analyze how you can achieve an SPA-like architecture in multi-page apps by combining partials, service workers, and streams.

Production case #

DEV is a community where software developers write articles, take part in discussions, and build their professional profiles.

Their architecture is a multi-page app based on traditional backend templating through Ruby on Rails. Their team was interested in some of the benefits of an app shell model, but didn't want to undertake a major architectural change or move away from their original tech stack.

Here's how their solution works:

First, they create partials of their home page for the header and the footer (shell_top.html and shell_bottom.html) and deliver them as standalone HTML snippets with an endpoint. These assets are added to the cache at the service worker install event (what's commonly referred to as precaching).
When a navigation request is intercepted by the service worker, they create a streamed response by combining the cached header and footer with the main page content that just came from the server. The body is the only actual part of the page that requires fetching data from the network.

The key element of this solution is the usage of streams, which enables incremental creations and updates of data sources. The Streams API also provides an interface for reading or writing asynchronous chunks of data, only a subset of which might be available in memory at any given time. This way, the header of the page can be rendered as soon as it's picked from the cache, while the rest of the content is being fetched from the network. As a result, the navigation experience is so fast that users don't perceive an actual page refresh, only the new content (the body) being updated.

The resulting UX is similar to the app shell UX pattern of SPAs, implemented on a MPA site.

Implement an app shell UX architecture in MPAs with Workbox #

In this section we'll cover a summary of the different parts involved in implementing an app shell UX architecture in MPAs. For a more detailed post on how to implement this on a real site, check out Beyond SPAs: alternative architectures for your PWA.

The server #

Partials #

The first step is to adopt a site structure based on HTML partials. These are just modular pieces of your pages that can be reused across your site and also delivered as standalone HTML snippets.

The head partial can contain all the logic needed to style and render the header of the page. The navbar partial can contain the logic for the navigation bar, the footer partial the code that needs to execute there, and so forth.

The first time the user visits the site, your server generates a response by assembling the different parts of the page:

app.get(routes.get('index'), async (req, res) => {
  res.write(headPartial + navbarPartial);
  const tag = req.query.tag || DEFAULT_TAG;
  const data = await requestData(…);
  res.write(templates.index(tag, data.items));
  res.write(footPartial);
  res.end();
});

By using the res (response) object's write() method, and referencing locally stored partial templates, the response can be streamed immediately, without getting blocked by any external data source. The browser takes this initial HTML and renders a meaningful interface and loading message right away.

The next portion of the page uses API data, which involves a network request. The web app can't render anything else until it gets a response back and processes it, but at least users aren't staring at a blank screen while they wait.

The service worker #

The first time a user visits a site, the header of the page will be rendered faster, without having to wait for the body of the page. The browser still needs to go to the network to fetch the rest of the page.

After the first page load, the service worker is registered, allowing you to fetch the partials for the different static parts of the page (header, navbar, footer, etc.) from the cache.

Precaching static assets #

The first step is to cache the partial HTML templates, so they are immediately available. With Workbox precaching you can store these files at the install event of the service worker and keep them up to date when changes are deployed to the web app.

Depending on the build process, Workbox has different solutions to generate a service worker and indicate the list of files to precache, including webpack and gulp plugins, a generic node module and a command line interface.

For a partials configuration like the one described earlier, the resulting service worker file should contain something similar to the following:

workbox.precaching.precacheAndRoute([
  {
    url: 'partials/about.html',
    revision: '518747aad9d7e',
  },
  {
    url: 'partials/foot.html',
    revision: '69bf746a9ecc6',
  },
  // etc.
]);

Streaming #

Next, add the service worker logic so that the precached partial HTML can be sent back to the web app immediately. This is a crucial part of being reliably fast. Using the Streams API within our service worker makes that possible. Workbox Streams abstracts the details of how streaming works. The package lets you pass to the library a mix of streaming sources, both from caches and runtime data that might come from the network. Workbox takes care of coordinating the individual sources and stitching them together into a single, streaming response.

First, set up the strategies in Workbox to handle the different sources that will make up the streaming response.

const cacheStrategy = workbox.strategies.cacheFirst({
  cacheName: workbox.core.cacheNames.precache,
});

const apiStrategy = workbox.strategies.staleWhileRevalidate({
  cacheName: API_CACHE_NAME,
  plugins: [
    new workbox.expiration.Plugin({maxEntries: 50}),
  ],
});

The first strategy reads data that's been precached, like the partial HTML templates.
The second strategy implements the stale-while-revalidate caching logic, along with least-recently-used cache expiration logic once we reach 50 entries.

Next, tell Workbox how to use the strategies to construct a complete, streaming response, by passing in an array of sources as functions to execute immediately:

workbox.streams.strategy([
  () => cacheStrategy.handle({
      request: new Request(getCacheKeyForURL("/head.html")),
    }),
  () => cacheStrategy.handle({
      request: new Request(getCacheKeyForURL("/navbar.html")),
    }),
  async ({event, url}) => {
    const tag = url.searchParams.get('tag') || DEFAULT_TAG;
    const listResponse = await apiStrategy.handle(…);
    const data = await listResponse.json();
    return templates.index(tag, data.items);
  },
  () => cacheStrategy.handle({
      request: new Request(getCacheKeyForURL("/foot.html")),
    }),
]);

The first two sources are precached partial templates read directly from the service worker's cache, so they'll always be available immediately.
The next source function fetches data from the network, and processes the response into the HTML that the web app expects.
Finally, a cached copy of the footer and closing HTML tags is streamed to complete the response.

Workbox takes the result from each source and streams it to the web app, in sequence, only delaying if the next function in the array hasn't completed yet. As a result, the user immediately sees the page being painted. The experience is so fast that when navigating the header stays in its position without making the user perceive the full page refresh. This is very similar to the UX that the app shell SPA model provides.

Instant navigation experiences

2020-06-23T00:00:00Z

Performing a task on a site commonly involves several steps. For example, purchasing a product in an e-commerce website might involve searching for a product, picking an item from the list of results, adding the item to the cart, and completing the operation by checking out.

In technical terms, moving through different pages means making a navigation request. As a general rule, you don't want to use long-lived Cache-Control headers to cache the HTML response for a navigation request. They should normally be satisfied via the network, with Cache-Control: no-cache, to ensure that the HTML, along with the chain of subsequent network requests, is (reasonably) fresh. Having to go against the network each time the user navigates to a new page unfortunately means that each navigation might be slow—at the very least, it means that it won't be reliably fast.

To speed up these requests, if you can anticipate the user's action, you can request these pages and assets beforehand and keep them in the cache for a short period of time until the user clicks on these links. This technique is called prefetching and it's commonly implemented by adding <link rel="prefetch"> tags to pages, indicating the resource to prefetch.

In this guide we'll explore different ways in which service workers can be used as a complement of traditional prefetching techniques.

Production cases #

MercadoLibre is the biggest e-commerce site in Latin America. To speed up navigations, they dynamically inject <link rel="prefetch"> tags in some parts of the flow. For example, in listing pages, they fetch the next result page as soon as the user scrolls to the bottom of the listing:

Prefetched files are requested at the "Lowest" priority and stored in the HTTP cache or the memory cache (depending on whether the resource is cacheable or not), for an amount of time that varies by browsers. For example, as of Chrome 85, this value is 5 minutes. Resources are kept around for five minutes, after which the normal Cache-Control rules for the resource apply.

Using service worker caching can help you extend the lifetime of prefetch resources beyond the five-minute window.

For example, Italian sports portal Virgilio Sport uses service workers to prefetch the most popular posts in their home page. They also use the Network Information API to avoid prefetching for users that are on a 2G connection.

As a result of this, over 3 weeks of observation Virgilio Sport witnessed load times for navigation to articles improve 78%, and the number of article impressions increase 45%.

Implement precaching with Workbox #

In the following section we'll use Workbox to show how to implement different caching techniques in the service worker that can be used as a complement to <link rel="prefetch">, or even a replacement for it, by delegating this task completely to the service worker.

1. Precache static pages and page subresources #

Precaching is the ability of the service worker to save files to the cache while it's installing.

In the following cases precaching is used to achieve a similar goal as prefetching: making navigations faster.

Precaching static pages #

For pages that are generated at build time (e.g. about.html, contact.html), or in completely static sites, one can just add the site's documents to the precache list, so they are already available in the cache every time the user accesses them:

workbox.precaching.precacheAndRoute([
  {url: '/about.html', revision: 'abcd1234'},
  // ... other entries ...
]);

Precaching page subresources #

Precaching static assets that the different sections of the site might use (e.g. JavaScript, CSS, etc.), is a general best practice and can give an extra boost in prefetching scenarios.

To speed up navigations in an e-commerce site, you can use <link rel="prefetch"> tags in listing pages to prefetch product detail pages for the first few products of a listing page. If you have already precached the product page subresources, this can make the navigation even faster.

To implement this:

Add a <link rel="prefetch"> tag to the page:

 <link rel="prefetch" href="/phones/smartphone-5x.html" as="document">

Add the page subresources to the precache list in the service worker:

workbox.precaching.precacheAndRoute([
  '/styles/product-page.ac29.css',
  // ... other entries ...
]);

2. Extend the lifetime of prefetch resources #

As mentioned earlier, <link rel="prefetch"> fetches and keeps resources in the HTTP cache for a limited amount of time, after which point the Cache-Control rules for a resource apply. As of Chrome 85, this value is 5 minutes.

Service workers allow you to extend the lifetime of the prefetch pages, while providing the added benefit of making those resources available for offline usage.

In the previous example, one could complement the <link rel="prefetch"> used to prefetch a product page with a Workbox runtime caching strategy.

To implement that:

Add a <link rel="prefetch"> tag to the page:

 <link rel="prefetch" href="/phones/smartphone-5x.html" as="document">

Implement a runtime caching strategy in the service worker for these types of requests:

new workbox.strategies.StaleWhileRevalidate({
  cacheName: 'document-cache',
  plugins: [
    new workbox.expiration.Plugin({
      maxAgeSeconds: 30 * 24 * 60 * 60, // 30 Days
    }),
  ],
});

In this case, we have opted to use a stale-while-revalidate strategy. In this strategy, pages can be requested from both the cache and the network, in parallel. The response comes from the cache if available, otherwise from the network. The cache is always kept up to date with the network response with each successful request.

3. Delegate prefetching to the service worker #

In most cases the best approach is to use <link rel="prefetch">. The tag is a resource hint designed to make prefetching as efficient as possible.

In some cases, though, it might be better to delegate this task completely to the service worker. For example: to prefetch the first few products in a client-side rendered product listing page, one might need to inject several <link rel="prefetch"> tags dynamically in the page, based on an API response. This can momentarily consume time on the page's main thread and make the implementation more difficult.

In cases like this, use a "page to service worker communication strategy", to delegate the task of prefetching completely to the service worker. This type of communication can be achieved by using worker.postMessage():

The Workbox Window package simplifies this type of communication, abstracting many details of the underlying call being done.

Prefetching with Workbox Window can be implemented in the following way:

In the page: call the service worker passing it the type of message, and the list of URLs to prefetch:

const wb = new Workbox('/sw.js');
wb.register();

const prefetchResponse = await wb.messageSW({type: 'PREFETCH_URLS', urls: […]});

In the service worker: implement a message handler to issue a fetch() request for each URL to prefetch:

addEventListener('message', (event) => {
  if (event.data.type === 'PREFETCH_URLS') {
    // Fetch URLs and store them in the cache
  }
});

Resilient search experiences

2020-06-23T00:00:00Z

Even in locations with fast networks a user might lose connection or connect to a flaky network, at some moments of the day. For example: a user is on the subway searching on the phone for a product on an e-commerce website. They type the product name, click the "search" button, and while waiting for the results, the connection is lost, leading to the standard browser offline page.

As a result, unless the user decides to come back to the site later, and repeat the same task, the site might lose a potential transaction and customer.

To provide a more resilient search experience in these cases you can use the Background Sync API, which persists failed queries so they can be retried once the connection is recovered. This technique, in combination with Web Push Notifications lets you inform the user of the search results, allowing you to keep them engaged with your service.

Production case #

For concrete application of this technique let's take a look at Google Search for Chrome in Android. When visiting the Google Search web app and going offline, instead of showing the standard network error page, the site serves a custom offline response, but allows users to enter their search query immediately. The page also prompts the user to opt-in for notifications, to receive a link to the search results page once the connection is recovered.

When the user performs a search, the service worker allows the query to be deferred and sent to Google's servers as soon as the device goes back online by using the Background Sync API, and to inform the user of the result by using the Push API.

Service workers allow Google Search to provide a meaningful offline experience and keep the user engaged, letting them complete their task.

Implement resilient search experiences with Workbox #

While Google Search implements this functionality without using Workbox, the Workbox library makes it easier by providing a Background Sync module, which takes care of many implementation details for us.

To implement a resilient search experience in Workbox, first, import the following modules in your service worker:

import {BackgroundSyncPlugin} from 'workbox-background-sync';
import {registerRoute} from 'workbox-routing';
import {NetworkOnly} from 'workbox-strategies';

Next, create an instance of the workbox.backgroundSync plugin, to automatically add failed requests to a queue, so they can be retried later:

const bgSyncPlugin = new workbox.backgroundSync.Plugin('offlineQueryQueue', {
  maxRetentionTime: 60,
  onSync: async ({queue}) => {
    let entry;
    while ((entry = await queue.shiftRequest())) {
      try {
        const response = await fetch(entry.request);
        const cache = await caches.open('offline-search-responses');
        const offlineUrl = `${entry.request.url}&notification=true`;
        cache.put(offlineUrl, response);
        showNotification(offlineUrl);
      } catch (error) {
        await this.unshiftRequest(entry);
        throw error;
      }
    }
  },
});

The plugin receives the following parameters:

offlineQueryQueue: The name of the queue that will be used to persist the failed requests in IndexedDB.
maxRetentionTime: The amount of time in minutes a request may be retried, after which point they will be discarded.
onSync: The callback that will be triggered when the connection is recovered. At that point, each failed request can be dequeued and processed, by calling queue.shiftRequest().

Finally, define a networkOnly runtime caching strategy for requests to the search URL (e.g. /search_action) and pass it the bgSyncPlugin defined previously:

workbox.routing.registerRoute(
  matchSearchUrl,
  new workbox.strategies.NetworkOnly({
        plugins: [bgSyncPlugin]
  })
);

This tells Workbox to always go to the network when the service worker intercepts a request for the search endpoint, and to delegate to the Background Sync plugin the task of managing offline scenarios.

As a result, when the user goes offline while searching, the query is automatically saved. When the connection is recovered the offline logic is triggered to process the request and inform the user of the result.

Conclusion #

In this article you learned how to implement a search experience capable of responding gracefully to offline scenarios, by combining the Background Sync API and the Push API. We used Workbox to show how to implement this feature, as it simplifies the process, but the same can be achieved by writing vanilla service worker code.

In the code samples we focused on the core part of the feature: how requests are intercepted and managed by the service worker. For a step-by-step guide on how to implement this functionality, including the offline page and the notification logic, check out the codelab at the end of this article.

Building resilient search experiences with Workbox

2020-06-23T00:00:00Z

This codelab shows you how to implement a resilient search experience with Workbox. The demo app it uses contains a search box that calls a server endpoint, and redirects the user to a basic HTML page.

Measure #

Before adding optimizations, it's always a good idea to first analyze the current state of the application.

Click Remix to Edit to make the project editable.
To preview the site, press View App. Then press Fullscreen .

In the new tab that just opened, check how the website behaves when going offline:

Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Network tab.
Open Chrome DevTools and select the Network panel.
In the Throttling drop-down list, select Offline.
In the demo app enter a search query, then click the Search button.

The standard browser error page is shown:

Provide a fallback response #

The service worker contains the code to add the offline page to the precache list, so it can always be cached at the service worker install event.

Usually you would need to instruct Workbox to add this file to the precache list at build time, by integrating the library with your build tool of choice (e.g. webpack or gulp).

For simplicity, we've already done it for you. The following code at public/sw.js does that:

const FALLBACK_HTML_URL = '/index_offline.html';
…
workbox.precaching.precacheAndRoute([FALLBACK_HTML_URL]);

Next, add code to use the offline page as a fallback response:

To view the source, press View Source.
Add the following code to the bottom of public/sw.js:

workbox.routing.setDefaultHandler(new workbox.strategies.NetworkOnly());

workbox.routing.setCatchHandler(({event}) => {
  switch (event.request.destination) {
    case 'document':
      return caches.match(FALLBACK_HTML_URL);
      break;
    default:
      return Response.error();
  }
});

The code does the following:

Defines a default Network Only strategy that will apply to all requests.
Declares a global error handler, by calling workbox.routing.setCatchHandler() to manage failed requests. When requests are for documents, a fallback offline HTML page will be returned.

To test this functionality:

Go back to the other tab that is running your app.
Set the Throttling drop-down list back to Online.
Press Chrome's Back button to navigate back to the search page.
Make sure that the Disable cache checkbox in DevTools is disabled.
Long-press Chrome's Reload button and select Empty cache and hard reload to ensure that your service worker is updated.
Set the Throttling drop-down list back to Offline again.
Enter a search query, and click the Search button again.

The fallback HTML page is shown:

Request notification permission #

For simplicity, the offline page at views/index_offline.html already contains the code to request notification permissions in a script block at the bottom:

function requestNotificationPermission(event) {
  event.preventDefault();

  Notification.requestPermission().then(function (result) {
    showOfflineText(result);
  });
}

The code does the following:

When the user clicks subscribe to notifications the requestNotificationPermission() function is called, which calls Notification.requestPermission(), to show the default browser permission prompt. The promise resolves with the permission picked by the user, which can be either granted, denied, or default.
Passes the resolved permission to showOfflineText() to show the appropriate text to the user.

Persist offline queries and retry when back online #

Next, implement Workbox Background Sync to persist offline queries, so they can be retried when the browser detects that connectivity has returned.

Open public/sw.js for edit.
Add the following code at the end of the file:

const bgSyncPlugin = new workbox.backgroundSync.Plugin('offlineQueryQueue', {
  maxRetentionTime: 60,
  onSync: async ({queue}) => {
    let entry;
    while ((entry = await queue.shiftRequest())) {
      try {
        const response = await fetch(entry.request);
        const cache = await caches.open('offline-search-responses');
        const offlineUrl = `${entry.request.url}&notification=true`;
        cache.put(offlineUrl, response);
        showNotification(offlineUrl);
      } catch (error) {
        await this.unshiftRequest(entry);
        throw error;
      }
    }
  },
});

The code does the following:

workbox.backgroundSync.Plugin contains the logic to add failed requests to a queue so they can be retried later. These requests will be persisted in IndexedDB.
maxRetentionTime indicates the amount of time a request may be retried. In this case we have chosen 60 minutes (after which it will be discarded).
onSync is the most important part of this code. This callback will be called when connection is back so that queued requests are retrieved and then fetched from the network.
The network response is added to the offline-search-responses cache, appending the &notification=true query param, so that this cache entry can be picked up when a user clicks on the notification.

To integrate background sync with your service, define a NetworkOnly strategy for requests to the search URL (/search_action) and pass the previously defined bgSyncPlugin. Add the following code to the bottom of public/sw.js:

const matchSearchUrl = ({url}) => {
  const notificationParam = url.searchParams.get('notification');
  return url.pathname === '/search_action' && !(notificationParam === 'true');
};

workbox.routing.registerRoute(
  matchSearchUrl,
  new workbox.strategies.NetworkOnly({
    plugins: [bgSyncPlugin],
  }),
);

This tells Workbox to always go to the network, and, when requests fail, use the background sync logic.

Next, add the following code to the bottom of public/sw.js to define a caching strategy for requests coming from notifications. Use a CacheFirst strategy, so they can be served from the cache.

const matchNotificationUrl = ({url}) => {
  const notificationParam = url.searchParams.get('notification');
  return (url.pathname === '/search_action' && (notificationParam === 'true'));
};

workbox.routing.registerRoute(matchNotificationUrl,
  new workbox.strategies.CacheFirst({
     cacheName: 'offline-search-responses',
  })
);

Finally, add the code to show notifications:

function showNotification(notificationUrl) {
  if (Notification.permission) {
     self.registration.showNotification('Your search is ready!', {
        body: 'Click to see you search result',
        icon: '/img/workbox.jpg',
        data: {
           url: notificationUrl
        }
     });
  }
}

self.addEventListener('notificationclick', function(event) {
  event.notification.close();
  event.waitUntil(
     clients.openWindow(event.notification.data.url)
  );
});

Test the feature #

Go back to the other tab that is running your app.
Set the Throttling drop-down list back to Online.
Press Chrome's Back button to navigate back to the search page.
Long-press Chrome's Reload button and select Empty cache and hard reload to ensure that your service worker is updated.
Set the Throttling drop-down list back to Offline again.
Enter a search query, and click the Search button again.
Click subscribe to notifications.
When Chrome asks you if you want to grant the app permission to send notifications, click Allow.
Enter another search query and click the Search button again.
Set the Throttling drop-down list back to Online again.

Once the connection is back a notification will be shown:

Conclusion #

Workbox provides many built-in features to make your PWAs more resilient and engaging. In this codelab you have explored how to implement the Background Sync API by way of the Workbox abstraction, to ensure that offline user queries are not lost, and can be retried once connection is back. The demo is a simple search app, but you can use a similar implementation for more complex scenarios and use cases, including chat apps, posting messages on a social network, etc.

Prefetching in create-react-app with Quicklink

2020-06-08T00:00:00Z

This codelab shows you how to implement the Quicklink library in a React SPA demo to demonstrate how prefetching speeds up subsequent navigations.

Measure #

Before adding optimizations, it's always a good idea to first analyze the current state of the application.

Click Remix to Edit to make the project editable.
To preview the site, press View App. Then press Fullscreen .

The website is a simple demo built with create-react-app.

Complete the following instructions in the new tab that just opened:

Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Network tab.
Select the Disable cache checkbox.
In the Throttling drop-down list, select Fast 3G to simulate a slow connection type.
Reload the app.
Type chunk into the Filter textbox to hide any resources that do not include chunk in their name.

The site uses route-based code splitting, thanks to which only the necessary code is requested at the beginning.

Clear the network requests in DevTools.
Within the app, click the Blog link to navigate to that page.

The JS and CSS chunks for the new route are loaded to render the page.

Next, you'll implement Quicklink in this site, so that these chunks can be prefetched in the home page, making the navigation faster.

This allows you to combine the best of both techniques:

Route-based code splitting tells the browser to only load the necessary chunks at a higher priority at page load time.
Prefetching tells the browser to load the chunks for in-viewport links at the lowest priority, during the browser's idle time.

Configure `webpack-route-manifest` #

The first step is to install and configure webpack-route-manifest, a webpack plugin that lets you generate a manifest file associating routes with their corresponding chunks.

Usually, you would need to install the library, but we've already done it for you. Here's the command that you would need to run:

npm install webpack-route-manifest --save-dev

config-overrides.js is a file placed in your project root directory where you can override existing behaviour of the webpack configuration, without having to eject the project.

To view the source, press View Source.

Open config-overrides.js for edit and add the webpack-route-manifest dependency at the beginning of the file:

const path = require('path');
const RouteManifest = require('webpack-route-manifest');

Next, configure the webpack-route-manifest plugin by adding the following code to the bottom of config-overrides.js:

module.exports = function override(config) {
  config.resolve = {
    ...config.resolve,
    alias: {
      '@assets': `${path.resolve(__dirname, 'src/assets')}`,
      '@pages': `${path.resolve(__dirname, 'src/pages')}`,
      '@components': `${path.resolve(__dirname, 'src/components')}`,
    },
  };

  config.plugins.push(
    new RouteManifest({
      minify: true,
      filename: 'rmanifest.json',
      routes(str) {
        let out = str.replace('@pages', '').toLowerCase();
        if (out === '/article') return '/blog/:title';
        if (out === '/home') return '/';
        return out;
      },
    }),
  );

  return config;
};

The new code does the following:

config.resolve declares variables with the internal routes to pages, assets and components.
config.plugins.push() creates a RouteManifest object and passes it the configuration so that the rmanifest.json file can be generated based on the site's routes and chunks.

The manifest.json file will be generated and made available at https://site_url/rmanifest.json.

Configure quicklink #

At this point you would need to install the Quicklink library in your project. For simplicity, we already added it to the project. Here's the command that you would need to run:

npm install --save quicklink

Open src/components/App/index.js for edit.

First, import the Quicklink higher order component (HOC):

import React, { lazy, Suspense } from 'react';
import { Route } from 'react-router-dom';

import Footer from '@components/Footer';
import Hero from '@components/Hero';
import style from './index.module.css';
import { withQuicklink } from 'quicklink/dist/react/hoc.js';

const Home = lazy(() => import(/* webpackChunkName: "home" */ '@pages/Home'));
const About = lazy(() => import(/* webpackChunkName: "about" */ '@pages/About'));
const Article = lazy(() => import(/* webpackChunkName: "article" */ '@pages/Article'));
const Blog = lazy(() => import(/* webpackChunkName: "blog" */ '@pages/Blog'));

Next, create an options object after the Blog variable declaration, to use as an argument when calling quicklink:

const options = {
	origins: []
};

Finally, wrap each route with the withQuicklink() higher order component, passing it an options parameter and the target component for that route:

const App = () => (
  <div className={style.app}>
    <Hero />
    <main className={style.wrapper}>
      <Suspense fallback={<div>Loading...</div>}>
        <Route path="/" exact component={withQuicklink(Home, options)} />
        <Route path="/blog" exact component={withQuicklink(Blog, options)} />
        <Route
          path="/blog/:title"
          component={withQuicklink(Article, options)}
        />
        <Route path="/about" exact component={withQuicklink(About, options)} />
      </Suspense>
    </main>
    <Footer />
  </div>
);

The previous code instructs to prefetch chunks for the routes wrapped with withQuicklink(), when the link comes into the view.

Measure again #

Repeat the first 6 steps from Measure. Don't navigate to the blog page yet.

When the home page loads the chunks for that route are loaded. After that, Quicklink prefetches the route's chunks for the in-viewport links:

These chunks are requested at the lowest priority and without blocking the page.

Clear the Network log again.
Disable the Disable cache checkbox.
Click the Blog link to navigate to that page.

The Size column indicates that these chunks were retrieved from the "prefetch cache", instead of the network. Loading these chunks without a Quicklink took approximately 580ms. Using the library it now takes 2ms, which represents a 99% reduction!

Speed up navigations in React with Quicklink

2020-06-08T00:00:00Z

Prefetching is a technique to speed up navigations by downloading the resources for the next page, ahead of time. Quicklink is a library that allows you to implement this technique at scale, by automatically prefetching links as they come into the view.

In multi-page apps the library prefetches documents (e.g. /article.html), for in-viewport links, so that when the user clicks on these links they can be picked up from the HTTP cache.

Single-page apps commonly use a technique called route-based code splitting. This allows the site to load the code for a given route only when the user navigates to it. These files (JS, CSS) are commonly referred to as "chunks".

With that said, in these sites, instead of prefetching documents the biggest performance gains come from prefetching these chunks before the page needs them.

Achieving this presents some challenges:

It's not trivial to determine which chunks (e.g. article.chunk.js) are associated with a given route (e.g. /article) before landing on it.
The final URL names of these chunks can't be predicted, as modern module bundlers typically use long-term hashing for versioning (e.g. article.chunk.46e51.js).

This guide explains how Quicklink solves these challenges and allows you to achieve prefetching at scale in React single page apps.

Determine chunks associated with each route #

One of the core components of quicklink is webpack-route-manifest, a webpack plugin that lets you generate a JSON dictionary of routes and chunks. This allows the library to know which files are going to be needed by each route of the application and prefetch them as the routes come into the view.

After integrating the plugin with the project, it will produce a JSON manifest file associating each route with its corresponding chunks:

{
  '/about': [
    {
      type: 'style',
      href: '/static/css/about.f6fd7d80.chunk.css',
    },
    {
      type: 'script',
      href: '/static/js/about.1cdfef3b.chunk.js',
    },
  ],
  '/blog': [
    {
      type: 'style',
      href: '/static/css/blog.85e80e75.chunk.css',
    },
    {
      type: 'script',
      href: '/static/js/blog.35421503.chunk.js',
    },
  ],
}

This manifest file can be requested in two ways:

By URL, e.g. https://site_url/rmanifest.json.
Through the window object, at window.__rmanifest.

Prefetch chunks for in-viewport routes #

Once the manifest file is available, the next step is to install Quicklink by running npm install quicklink.

Then, the higher order component (HOC) withQuicklink() can be used to indicate that a given route should be prefetched when the link comes into the view.

The following code belongs to an App component of a React app that renders a top menu with four links:

const App = () => (
  <div className={style.app}>
    <Hero />
    <main className={style.wrapper}>
      <Suspense fallback={<div>Loading…</div>}>
        <Route path="/" exact component={Home} />
        <Route path="/blog" exact component={Blog} />
        <Route path="/blog/:title" component={Article} />
        <Route path="/about" exact component={About} />
      </Suspense>
    </main>
    <Footer />
  </div>
);

To tell Quicklink that these routes should be prefetched as they come into the view:

Import the quicklink HOC at the beginning of the component.
Wrap each route with the withQuicklink() HOC, passing the page component and options parameter to it.

const options = {
  origins: [],
};
const App = () => (
  <div className={style.app}>
    <Hero />
    <main className={style.wrapper}>
      <Suspense fallback={<div>Loading…</div>}>
        <Route path="/" exact component={withQuicklink(Home, options)} />
        <Route path="/blog" exact component={withQuicklink(Blog, options)} />
        <Route
          path="/blog/:title"
          component={withQuicklink(Article, options)}
        />
        <Route path="/about" exact component={withQuicklink(About, options)} />
      </Suspense>
    </main>
    <Footer />
  </div>
);

The withQuicklink() HOC uses the path of the route as a key to obtain its associated chunks from rmanifest.json. Under the hood, as links come into the view, the library injects a <link rel="prefetch"> tag in the page for each chunk so they can be prefetched. Prefetched resources will be requested at the lowest priority by the browser and kept in the HTTP Cache for 5 minutes, after which point, the cache-control rules of the resource apply. As a result of this, when a user clicks on a link and moves to a given route, the chunks will be retrieved from the cache, greatly improving the time it takes to render that route.

Conclusion #

Prefetching can greatly improve load times for future navigations. In React single-page apps, this can be achieved by loading the chunks associated with each route, before the user lands in them. Quicklink's solution for React SPA uses webpack-route-manifest to create a map of routes and chunks, in order to determine which files to prefetch, when a link comes into the view. Implementing this technique throughout your site can greatly improve navigations to the point of making them appear instant.

How to define your install strategy

2020-05-12T00:00:00Z

In the past, app installation was only possible in the context of platform-specific applications. Today, modern web apps offer installable experiences that provide the same level of integration and reliability as platform-specific apps.

You can achieve this in different ways:

Installing the PWA from the browser.
Installing the PWA from the app store.

Having different distribution channels is a powerful way of reaching a broad number of users, but choosing the right strategy to promote your the installation of your PWA can be challenging.

This guide explores best practices for combining different installation options to increase installation rates and avoid platform competition and cannibalization. The installation offerings covered include PWAs installed from both the browser and the App Store, as well as platform-specific apps.

Why make your web app installable? #

Installed Progressive Web Apps run in a standalone window instead of a browser tab. They're launchable from the user's home screen, dock, taskbar, or shelf. It's possible to search for them on a device and jump between them with the app switcher, making them feel like part of the device they're installed on.

But having both an installable web app and a platform-specific app can be confusing for users. For some users platform-specific apps may be the best choice, but for others they can present some drawbacks:

Storage constraints: installing a new app might mean deleting others, or cleaning up space, by removing valuable content. This is especially disadvantageous for users on low-end devices.
Available bandwidth: downloading an app can be a costly and slow process, even more so for users on slow connections and expensive data plans.
Friction: leaving a website and moving to a store to download an app creates additional friction and delays a user action that could be performed directly in the web.
Update cycle: making changes in platform-specific apps might require going through an app review process, which can slow down changes and experiments (A/B tests, for example).

In some cases, the percentage of users who won't download your platform-specific app might be large, for example: those that think that they won't use the app very often, or can't justify spending several megabytes of storage or data. You can determine the size of this segment in several ways, for example by using an analytics setup to track the percentage of "mobile web only" users.

If the size of this segment is considerable, that's a good indication that you need to provide alternative ways of installing your experiences.

Promoting installation of your PWA through the browser #

If you have a high quality PWA, it may be better to promote its installation over your platform-specific app. For example, if the platform-specific app is missing functionality offered by your PWA, or if it hasn't been updated in a while. It can also be helpful to promote installation of your PWA if the platform-specific app wasn't optimized for bigger screens, such as on ChromeOS.

For some apps, driving platform-specific app installations is a key part of the business model, in that case, it makes business sense to promote installation of your platform-specific app. But, some users might be more comfortable staying on the web. If that segment can be identified, the PWA prompt can be shown only to them (what we call "PWA as fallback").

PWA as primary installable experience #

Once a PWA meets the installability criteria, most browsers show an indication that the PWA is installable. For example, desktop Chrome shows an installable icon in the address bar, and on mobile, it shows a mini-infobar:

The mini-infobar.

While that may be enough for some experiences, if your goal is to drive installations of your PWA, we highly recommend you listen for the BeforeInstallPromptEvent, and follow the patterns for promoting the installation of your PWA.

Prevent your PWA from cannibalizing your platform-specific app install rate #

In some cases, you may choose to promote the installation of your platform-specific app over your PWA, but in this case, we still recommend you provide a mechanism to allow users to install your PWA. This fallback option makes it possible for users who can't, or don't want to install your platform-specific app to get a similar, installed experience.

The first step to implement this strategy is to define a heuristic for when you'll show the user an install promotion for your PWA.

For example: A PWA user is a user that has seen the platform-specific app install prompt and not installed the platform-specific app. They have returned to the site at least five times, or they have clicked the app banner, but have continued using the website instead.

Then, the heuristic can be implemented in the following way:

Show the platform-specific app install banner.
If a user dismisses the banner, set a cookie with that information (e.g. document.cookie = "app-install-banner=dismissed").
Use another cookie to track the number of user visits to the site (e.g. document.cookie = "user-visits=1").
Write a function, such as isPWAUser(), that uses the information previously stored in the cookies along with the getInstalledRelatedApps() API to determine if a user is considered a "PWA user".
When the user performs a meaningful action, call isPWAUser(). If the function returns true and the PWA install prompt was saved previously, you can show the PWA install button.

Promoting installation of your PWA through an app store #

Apps for App stores can be built with different technologies, including PWA techniques. In Blending PWA into native environments you can find a summary of the technologies that can be used to that end.

In this section we'll classify apps in the store in two groups:

Platform-specific apps: these apps are mostly built with platform-specific code. Their sizes depend on the platform, but they're usually above 10MB on Android, and 30MB on iOS. You might want to promote your platform-specific app if you don't have a PWA, or if the platform-specific app presents a more complete feature set.
Lightweight apps: these apps can be built with platform-specific code as well, but they are commonly built with web technology, packaged in a platform-specific wrapper. Full PWAs can be uploaded to the stores as well. (This is discussed later in this article.) Some companies opt to provide these as "lite" experiences, and others have used this approach for their flagship (core) apps as well.

Promoting Lightweight Apps #

According to a Google Play study, for every 6 MB increase to an APK's size, the install conversion rate decreases by 1%. This means that the download completion rate of an app of 10 MB could be approximately 30% higher than an app of 100 MB!

To address this, some companies are leveraging their PWA to provide a lightweight version of their app in the Play Store using Trusted Web Activities (TWA). TWAs wrap your PWA in a webview like component, and the resulting app size is usually only a few megabytes.

Oyo, one of India's largest hospitality companies, built a Lite version of their app, and made it available in the Play Store using a TWA. At the time this article was written, the Oyo app was only 850 KB, just 7% the size of their Android app. And once installed, it's indistinguishable from their Android app:

OYO Lite in action.

Oyo kept both the flagship and "lite" app versions in the store, providing a choice to their users.

Providing a lightweight web experience #

Intuitively, users on low-end devices, might be more inclined to download lightweight versions of apps than users on high-end phones. Therefore, if it's possible to identify a user's device, you could prioritize the lightweight app install banner over the heavier platform-specific app version.

On the web, it's possible to obtain device signals and approximately map them to device categories (e.g. "high", "mid", or "low"). You can obtain this information in different ways, using either JavaScript APIs or client hints.

Using JavaScript #

Using JavaScript properties such as navigator.hardwareConcurrency, navigator.deviceMemory, and navigator.connection you can get information about the device CPU, memory and network status respectively. For example:

const deviceCategory = req.get('Device-Memory') < 1 ? 'lite' : 'full';`

Using client hints #

Device signals can be also inferred in HTTP request headers, through client hints. Here's how you can implement the previous code for device memory with client hints:

First, tell the browser you are interested in receiving device memory hints in the header of the HTTP response for any first-party request:

HTTP/1.1 200 OK
Content-Type: text/html
Accept-CH: Device-Memory

Then, you'll start receiving Device-Memory information in the request header of HTTP requests:

GET /main.js HTTP/1.1
Device-Memory: 0.5

You can use this information in your backends to store a cookie with the category of the user's device:

app.get('/route', (req, res) => {
  // Determine device category

 const deviceCategory = req.get('Device-Memory') < 1 ? 'lite' : 'full';

  // Set cookie
  res.setCookie('Device-Category', deviceCategory);
  …
});

Finally, create your own logic to map this information to device categories, and show the corresponding app install prompt on each case:

if (isDeviceMidOrLowEnd()) {
   // show "Lite app" install banner or PWA A2HS prompt
} else {
  // show "Core app" install banner
}

Conclusion #

The ability to have an icon in the user's home screen is one of the most engaging features of applications. Given that historically this was only possible for apps installed from app stores, companies might think that showing an app store install banner would be enough to convince users to install their experiences. Currently there are more options for letting users install an app, including offering lightweight app experiences in the stores, and letting users add PWAs to the home screen by prompting them to do it directly from the website.

Optimize CSS background images with media queries

2020-03-05T00:00:00Z

Many sites request heavy resources, like images, that are not optimized for certain screens, and send large CSS files containing styles that some devices will never use. Using media queries is a popular technique for delivering tailored stylesheets and assets to different screens to reduce the amount of data transferred to users and improve page load performance. This guide shows you how to use media queries to send images that are only as large as they need to be, a technique commonly known as responsive images.

Prerequisites #

This guide assumes that you're familiar with Chrome DevTools. You can use another browser's DevTools instead if you prefer. You'll just need to map the Chrome DevTools screenshots in this guide back to the relevant features in your browser of choice.

Understand responsive background images #

First, analyze the network traffic of the unoptimized demo:

Open the unoptimized demo in a new Chrome tab.
Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Network tab.
Reload the page.

You'll see that the only image that's being requested is background-desktop.jpg, which has a size of 1006KB:

Resize the browser window and notice that the Network Log isn't showing any new requests being made by the page. This means that the same image background is being used for all screen sizes.

You can see the styles that control the background image in style.css:

body {
  background-position: center center;
  background-attachment: fixed;
  background-repeat: no-repeat; background-size: cover;
  background-image: url(images/background-desktop.jpg);
}

Here's the meaning of each of the properties used:

background-position: center center: Center the image vertically and horizontally.
background-repeat: no-repeat: Show the image only once.
background-attachment: fixed: Avoid making the background image scroll.
background-size: cover: Resize the image to cover the entire container.
background-image: url(images/background-desktop.jpg): The URL of the image.

When combined, these styles tell the browser to adapt the background image to different screen heights and widths. This is the first step towards achieving a responsive background.

Using a single background image for all screen sizes has some limitations:

The same amount of bytes are sent, regardless of the screen size, even when, for some devices, like phones, a smaller and more lightweight image background would look just as good. In general, you want to send the smallest possible image that still looks good on the user's screen to improve performance and save user data.
In smaller devices the image will be stretched or cut to cover the entire screen, potentially hiding relevant parts of the background to users.

In the next section, you'll learn how to apply an optimization to load different background images, according to the user's device.

Use media queries #

Using media queries is a common technique to declare stylesheets that will only apply to certain media or device types. They are implemented by using @media rules, which let you define a set of breakpoints, where specific styles are defined. When the conditions defined by the @media rule are met (for example, a certain screen width), the group of styles defined inside the breakpoint will be applied.

The following steps can be used to apply media queries to the site so that different images are used, depending on the maximum width of the device requesting the page.

In style.css remove the line that contains the background image URL:

body {
  background-position: center center;
  background-attachment: fixed;
  background-repeat: no-repeat; background-size: cover;
  background-image: url(images/background-desktop.jpg);
}

Next, create a breakpoint for each screen width, based on the common dimensions in pixels that mobile, tablet, and desktop screens usually have:

For mobile:

@media (max-width: 480px) {
    body {
        background-image: url(images/background-mobile.jpg);
    }
}

For tablets:

@media (min-width: 481px) and (max-width: 1024px) {
    body {
        background-image: url(images/background-tablet.jpg);
    }
}

For desktop devices:

@media (min-width: 1025px) {
    body {
	    background-image: url(images/background-desktop.jpg);
   }
}

Open the optimized version of style.css in your browser to see the changes made.

Measure for different devices #

Next visualize the resulting site in different screen sizes and in simulated mobile devices:

Open the optimized site in a new Chrome tab.
Make your viewport narrow (less than 480px).
Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Network tab.
Reload the page. Notice how the background-mobile.jpg image was requested.
Make your viewport wider. Once it's wider than 480px notice how background-tablet.jpg is requested. Once it's wider than 1025px notice how background-desktop.jpg is requested.

When the width of the browser screen is changed, new images are requested.

In particular when the width is below the value defined in the mobile breakpoint (480px), you see the following Network Log:

The size of the new mobile background is 67% smaller than the desktop one.

Effects on Largest Contentful Paint (LCP) #

Elements with CSS background images are considered a candidate for Largest Contentful Paint (LCP), however, CSS background images are not discoverable by the browser preload scanner, which means you could be delaying your site's LCP if you're not careful.

The first option you should consider is whether your LCP candidate image could work in an <img> element with srcset and sizes attributes for responsiveness. The browser preload scanner will discover <img> elements, and send requests for them while the parser is blocked on rendering.

If you can't (or don't want to) avoid using a CSS background image, the second option would be to preload responsive images to ensure you preload the right image for the proper viewport size. The <link> elements media, imagesrcset, and imagesizes attributes hint to the browser that a given resource hint only applies in certain viewport conditions, avoiding multiple wasted preloads when you only want to load the one resource that's a fit for the current viewport.

Summary #

In this guide you've learned to apply media queries to request background images tailored to specific screen sizes and save bytes when accessing the site on smaller devices, like mobile phones. You used the @media rule to implement a responsive background. This technique is widely supported by all browsers. A new CSS feature: image-set(), can be used for the same purpose with fewer lines of code. At the time of this writing, this feature is not supported in all browsers, but you might want to keep an eye on how adoption evolves, as it can represent an interesting alternative to this technique.

Prefetch resources to speed up future navigations

2019-09-12T00:00:00Z

Research shows that faster load times result in higher conversion rates and better user experiences. If you have insight into how users move through your website and which pages they will likely visit next, you can improve load times of future navigations by downloading the resources for those pages ahead of time.

This guide explains how to achieve that with <link rel=prefetch>, a resource hint that enables you to implement prefetching in an easy and efficient way.

Improve navigations with `rel=prefetch` #

Adding <link rel=prefetch> to a web page tells the browser to download entire pages, or some of the resources (like scripts or CSS files), that the user might need in the future:

<link rel="prefetch" href="/articles/" as="document">

The prefetch hint consumes extra bytes for resources that are not immediately needed, so this technique needs to be applied thoughtfully; only prefetch resources when you are confident that users will need them. Consider not prefetching when users are on slow connections. You can detect that with the Network Information API.

There are different ways to determine which links to prefetch. The simplest one is to prefetch the first link or the first few links on the current page. There are also libraries that use more sophisticated approaches, explained later in this post.

Use cases #

Prefetching subsequent pages #

Prefetch HTML documents when subsequent pages are predictable, so that when a link is clicked, the page is loaded instantly.

For example, in a product listing page, you can prefetch the page for the most popular product in the list. In some cases, the next navigation is even easier to anticipate—on a shopping cart page, the likelihood of a user visiting the checkout page is usually high which makes it a good candidate for prefetching.

While prefetching resources does use additional bandwidth, it can improve most performance metrics. Time to First Byte (TTFB) will often be much lower, as the document request results in a cache hit. Because TTFB will be lower, subsequent time-based metrics will often be lower as well, including Largest Contentful Paint (LCP) and First Contentful Paint (FCP).

Prefetching static assets #

Prefetch static assets, like scripts or stylesheets, when subsequent sections the user might visit can be predicted. This is especially useful when those assets are shared across many pages.

For example, Netflix takes advantage of the time users spend on logged-out pages, to prefetch React, which will be used once users log in. Thanks to this, they reduced Time to Interactive by 30% for future navigations.

The effect of prefetching static assets on performance metrics depends on the resource being prefetched:

Prefetching images can significantly lower LCP times for LCP image elements.
Prefetching stylesheets can improve both FCP and LCP, as the network time to download the stylesheet will be eliminated. Since stylesheets are render blocking, they can reduce LCP when prefetched. In cases where the subsequent page's LCP element is a CSS background image requested via the background-image property, the image will also be prefetched as a dependent resource of the prefetched stylesheet.
Prefetching JavaScript will allow the processing of the prefetched script to occur much sooner than if it were required to be fetched by the network first during navigation. This can have an effect on responsiveness metrics such as First Input Delay (FID) and Interaction to Next Paint (INP). In cases where markup is rendered on the client via JavaScript, LCP can be improved through reduced resource load delays, and client-side rendering of markup containing a page's LCP element can occur sooner.
Prefetching web fonts that are not already used by the current page, can eliminate layout shifts. In cases where font-display: swap; is used, the swap period for the font is eliminated, resulting in faster rendering of the text and eliminating layout shifts. If a future page uses the prefetched font and the page's LCP element is a block of text using a web font, LCP for that element will also be faster.

Prefetching on-demand JavaScript chunks #

Code-splitting your JavaScript bundles allows you to initially load only parts of an app and lazy-load the rest. If you're using this technique, you can apply prefetch to routes or components that are not immediately necessary but will likely be requested soon.

For example, if you have a page that contains a button that opens a dialog box which contains an emoji picker, you can divide it into three JavaScript chunks—home, dialog and picker. Home and dialog could be initially loaded, while the picker could be loaded on-demand. Tools like webpack allow you to instruct the browser to prefetch these on-demand chunks.

How to implement `rel=prefetch` #

The simplest way to implement prefetch is adding a <link> tag to the <head> of the document:

<head>
  ...
  <link rel="prefetch" href="/articles/" as="document">
  ...
</head>

The as attribute helps the browser set the right headers, and determine whether the resource is already in the cache. Example values for this attribute include: document, script, style, font, image, and others.

You can also initiate prefetching via the Link HTTP header:

Link: </css/style.css>; rel=prefetch

A benefit of specifying a prefetch hint in the HTTP Header is that the browser doesn't need to parse the document to find the resource hint, which can offer small improvements in some cases.

Prefetching JavaScript modules with webpack magic comments #

webpack enables you to prefetch scripts for routes or functionality you're reasonably certain users will visit or use soon.

The following code snippet lazy-loads a sorting functionality from the lodash library to sort a group of numbers that will be submitted by a form:

form.addEventListener("submit", e => {
  e.preventDefault()
  import('lodash.sortby')
    .then(module => module.default)
    .then(sortInput())
    .catch(err => { alert(err) });
});

Instead of waiting for the 'submit' event to take place to load this functionality, you can prefetch this resource to increase the chances of having it available in the cache by the time the user submits the form. webpack allows that using the magic comments inside import():

form.addEventListener("submit", e => {
   e.preventDefault()
   import(/* webpackPrefetch: true */ 'lodash.sortby')
         .then(module => module.default)
         .then(sortInput())
         .catch(err => { alert(err) });
});

This tells webpack to inject the <link rel="prefetch"> tag into the HTML document:

<link rel="prefetch" as="script" href="1.bundle.js">

The performance benefits of prefetching on-demand chunks is a bit nuanced, but generally speaking, you could expect to see faster responses to interactions which depend on those on-demand chunks, as they will be immediately available. Depending on the nature of the interaction, this could impart a benefit to a page's INP.

Prefetching in general also factors into overall resource prioritization. When a resource is prefetched, it is done so at the lowest possible priority. Thus, any prefetched resources will not contend for bandwidth for resources needed by the current page.

Smart prefetching with quicklink and Guess.js #

You can also implement smarter prefetching with libraries that use prefetch under the hood:

quicklink uses Intersection Observer API to detect when links come into the viewport and prefetches linked resources during idle time. Bonus: quicklink weighs less than 1 KB!
Guess.js uses analytics reports to build a predictive model that is used to smartly prefetch only what the user is likely to need.

Both quicklink and Guess.js use the Network Information API to avoid prefetching if a user is on a slow network or has Save-Data turned on.

Prefetching under the hood #

Resource hints are not mandatory instructions and it's up to the browser to decide if, and when, they get executed.

You can use prefetch multiple times in the same page. The browser queues up all hints and requests each resource when it's idle. In Chrome, if a prefetch has not finished loading and the user navigates to the destined prefetch resource, the in-flight load is picked up as the navigation by the browser (other browser vendors might implement this differently).

Prefetching takes place at the 'Lowest' priority, so prefetched resources do not compete for bandwidth with the resources required in the current page.

Prefetched files are stored in the HTTP Cache, or the memory cache (depending on whether the resource is cacheable or not), for an amount of time that varies by browsers. For example, in Chrome resources are kept around for five minutes, after which the normal Cache-Control rules for the resource apply.

Conclusion #

Using prefetch can greatly improve load times of future navigations and even make pages appear to load instantly. prefetch is widely supported in modern browsers, which makes it an attractive technique to improve the navigation experience for many users. This technique requires loading extra bytes that might not be used, so be mindful when you use it; only do it when necessary, and ideally, only on fast networks.

Two ways to prefetch: `` tags and HTTP headers

2019-09-12T00:00:00Z

In this codelab, you'll implement prefetching in two ways: with <link rel="prefetch"> and with HTTP Link header.

The sample app is a website that has a promotional landing page with a special discount for the shop's best selling t-shirt. Since the landing page links to a single product, it's safe to assume that a high percentage of users will navigate to the product details page. This makes the product page a great candidate to prefetch on the landing page.

Measure performance #

First establish the baseline performance:

Click Remix to Edit to make the project editable.
To preview the site, press View App. Then press Fullscreen .
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 to simulate a slow connection type.
To load the product page, click Buy now in the sample app.

The product-details.html page takes about 600 ms to load:

Prefetch the product page with `<link rel="prefetch">` #

To improve navigation, insert a prefetch tag in the landing page to prefetch the product-details.html page:

Add the following <link> element to the head of the views/index.html file:

<!doctype html>
  <html>
    <head>
       <meta charset="UTF-8">
      <meta name="viewport" content="width=device-width, initial-scale=1.0">
      <link href="https://fonts.googleapis.com/css?family=Montserrat&display=swap" rel="stylesheet">

      <link rel="prefetch" href="/product-details.html" as="document">
	  ...
</head>

The as attribute is optional but recommended; it helps the browser set the right headers and determine whether the resource is already in the cache. Example values for this attribute include: document, script, style, font, image, and others.

To verify that prefetching is working:

To preview the site, press View App. Then press Fullscreen .
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 to simulate a slow connection type.
Clear the Disable cache checkbox.
Reload the app.

Now when the landing page loads, the product-details.html page loads too, but at the lowest priority:

The page is kept in the HTTP cache for five minutes, after which the normal Cache-Control rules for the document apply. In this case, product-details.html has a cache-control header with a value of public, max-age=0, which means that the page is kept for a total of five minutes.

Reevaluate performance #

Reload the app.
To load the product page, click Buy now in the sample app.

Take a look at the Network panel. There are two differences compared to the initial network trace:

The Size column shows "prefetch cache", which means this resource was retrieved from the browser's cache rather than the network.
The Time column shows that the time it takes for the document to load is now about 10 ms.

This is approximately a 98% reduction compared to the previous version, which took about 600 ms.

Extra credit: Use `prefetch` as a progressive enhancement #

Prefetching is best implemented as a progressive enhancement for the users who are browsing on fast connections. You can use the Network Information API to check the network conditions and based on that dynamically inject prefetch tags. That way, you can minimize data consumption and save costs for users on slow or expensive data plans.

To implement adaptive prefetching, first remove the <link rel="prefetch"> tag from views/index.html:

<!doctype html>
  <html>
    <head>
       <meta charset="UTF-8">
       <meta name="viewport" content="width=device-width, initial-scale=1.0">
       <link href="https://fonts.googleapis.com/css?family=Montserrat&display=swap" rel="stylesheet">
	   <link rel="prefetch" href="/product-details.html" as="document">
	   ...
	</head>

Then add the following code to public/script.js to declare a function that dynamically injects the prefetch tag when the user is on a fast connection:

function injectLinkPrefetchIn4g(url) {
	if (window.navigator.connection.effectiveType === '4g') {
		//generate link prefetch tag
		const linkTag = document.createElement('link');
		linkTag.rel = 'prefetch';
		linkTag.href = url;
		linkTag.as = 'document';

		//inject tag in the head of the document
		document.head.appendChild(linkTag);
	}
}

The function works as follows:

It checks the effectiveType property of the Network Information API to determine if the user is on a 4G (or faster) connection.
If that condition is fulfilled, it generates a <link> tag with prefetch as the type of hint, passes the URL that will be prefetched in the href attribute, and indicates that the resource is an HTML document in the as attribute.
Finally, it injects the script dynamically in the head of the page.

Next add script.js to views/index.html, just before the closing </body> tag:

<body>
      ...
      <script src="/script.js"></script>
</body>

Requesting script.js at the end of the page ensures that it will be loaded and executed after the page is parsed and loaded.

To make sure that the prefetching doesn't interfere with critical resources for the current page, add the following code snippet to call injectLinkPrefetchIn4g() on the window.load event:

<body>
      ...
      <script src="/script.js"></script>
      <script>
           window.addEventListener('load', () => {
                injectLinkPrefetchIn4g('/product-details.html');
           });
      </script>
</body>

The landing page now prefetches product-details.html only on fast connections. To verify that:

To preview the site, press View App. Then press Fullscreen .
Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Network tab.
In the Throttling drop-down list, select Online.
Reload the app.

You should see product-details.html in the Network panel:

To verify that the product page isn't prefetched on slow connections:

In the Throttling drop-down list, select Slow 3G.
Reload the app.

The Network panel should include only the resources for the landing page without product-details.html:

Prefetch the stylesheet for the product page with the HTTP `Link` header #

The HTTP Link header can be used to prefetch the same type of resources as the link tag. Deciding when to use one or the other mostly depends on your preference, as the difference in performance is insignificant. In this case, you'll use it to prefetch the main CSS of the product page, to further improve its rendering.

Add an HTTP Link header for style-product.css in the server response for the landing page:

Open the server.js file and look for the get() handler for the root url: /.
Add the following line at the beginning of the handler:

app.get('/', function(request, response) {
	response.set('Link', '</style-product.css>; rel=prefetch');
	response.sendFile(__dirname + '/views/index.html');
});

To preview the site, press View App. Then press Fullscreen .
Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Network tab.
Reload the app.

The style-product.css is now prefetched at the lowest priority after the landing page loads:

To navigate to the product page, click Buy now. Take a look at the Network panel:

The style-product.css file is retrieved from the "prefetch cache" and it took only 12 ms to load.

Progressive Web Apps in multi-origin sites

2019-08-19T00:00:00Z

Background #

In the past, there were some advantages to using multi-origin architectures, but for Progressive Web Apps, that approach presents many challenges. In particular, the same-origin policy, imposes restrictions for sharing things like service workers and caches, permissions, and for achieving a standalone experience across multiple origins. This article will describe the good and bad uses of multiple origins, and explain the challenges and workarounds for building Progressive Web Apps in multi-origin sites.

Good and bad uses of multiple origins #

There are a few legitimate reasons for sites to employ a multi-origin architecture, mostly related to providing an independent set of web applications, or to create experiences that are completely isolated from each other. There are also uses that should be avoided.

The good #

Let's look at the useful reasons first:

Localization / Language: Using a country-code top-level domain, to separate sites to be served in different countries (e.g. https://www.google.com.ar), or using subdomains to divide sites targeted to different locations (e.g.: https://newyork.craigslist.org) or to offer content for a specific language (e.g. https://en.wikipedia.org).
Independent webapps: Using different subdomains to provide experiences whose purpose differs considerably from the site on the main origin. For example, in a news site, the crosswords webapp could be intentionally served from https://crosswords.example.com, and installed and used as an independent PWA, without having to share any resources or functionality with the main website.

The bad #

If you're not doing any of these things, it's likely that using a multi-origin architecture will be a disadvantage when building Progressive Web Apps.

Despite this, many sites continue being structured this way for no particular reason, or for 'legacy' reasons. One example is using subdomains to arbitrarily separate parts of a site that should be part of a unified experience.

The following patterns, for example, are highly discouraged:

Site sections: Separating different sections of a site on subdomains. In news sites, it's not uncommon to see the home page at: https://www.example.com, while the sports section lives at https://sports.example.com, politics at https://politics.example.com, and so forth. In the case of an e-commerce site, using something like https://category.example.com for product categories, https://product.example.com for product pages, etc.
User Flow: Another approach that's discouraged is to separate different smaller parts of the site, like pages for the login or purchase flows in subdomains. For example, using https://login.example.com, and https://checkout.example.com.

For those cases where migrating to a single origin is not possible, what follows is a list of challenges, and (where possible), workarounds that can be considered when building Progressive Web Apps.

Challenges and Workarounds for PWAs across different origins #

When building a website on multiple origins, providing a unified PWA experience is challenging, mostly because of the same-origin policy, which imposes a number of constraints. Let's look at them one at a time.

Service workers #

The origin of the service worker script URL has to be the same as the origin of the page calling register(). This means that, for example, a page at https://www.example.com can't call register() with a service worker url at https://section.example.com.

Another consideration is that a service worker can only control pages hosted under the origin and path it belongs to. This means that, if the service worker is hosted at https://www.example.com it can only control URLs from that origin (according to the path defined in the scope parameter), but won't control any page in other subdomains such as, for example, those in https://section.example.com.

In this case, the only workaround is to use multiple service workers (one per origin).

Caching #

The Cache object, indexedDB, and localStorage are also constrained to a single origin. This means it's not possible to access the caches that belong to https://www.example.com, from, for example: https://www.section.example.com.

Here are some things you can do to manage caches properly in scenarios like this:

Leverage browser caching: Using traditional browser caching best practices is always recommended. This technique provides the added benefit of reusing cached resources across origins, which can't be done with the service worker's cache. For best practices on how to use HTTP Cache with service workers, you can take a look at this post.
Keep service worker installation lightweight: If you are maintaining multiple service workers, avoid making users pay a big installation cost every time they navigate to a new origin. In other words: only pre-cache resources that are absolutely necessary.

Permissions #

Permissions are also scoped to origins. This means that if a user granted a given permission to the origin https://section.example.com, it won't carry over to other origins, like https://www.example.com.

Since there's no way to share permissions across origins, the only solution here is to ask for permission on each of subdomain where a given feature is required (e.g. location). For things like web push, you can maintain a cookie to track if the permission has been accepted by the user in another subdomain, to avoid requesting it again.

Installation #

To install a PWA, each origin must have its own manifest with a start_url that's relative to itself. This means that a user receiving the installation prompt on a given origin (i.e: https://section.example.com) won't be able to install the PWA with a start_url on a different one (i.e: https://www.example.com). In other words, users receiving the installation prompt in a subdomain will only be able to install PWAs for the subpages, not for the main URL of the app.

There's also the issue that the same user could receive multiple installation prompts when navigating the site, if each subdomain meets the installation criteria, and prompts the user to install the PWA.

To mitigate this problem you can make sure that the prompt is shown only on the main origin. When a user visits a subdomain that passes the installation criteria:

Listen for beforeinstallprompt event.
Prevent the prompt from appearing, calling event.preventDefault().

That way, you make sure the prompt is not shown in unintended parts of the site, while you can continue showing it, for example, in the main origin (e.g. Home page).

Standalone Mode #

While navigating in a standalone window, the browser will behave differently when the user moves outside of the scope set by the PWA's manifest. The behavior depends on each browser version and vendor. For example, the latest Chrome versions open a Chrome Custom Tab, when a user moves out of the scope in standalone mode.

In most cases, there's no solution for this, but a workaround can be applied for small parts of the experience that are hosted in subdomains (for example: login workflows):

The new URL, https://login.example.com, could open inside a full screen iframe.
Once the task is completed inside the iframe (for example, the login process), postMessage() can be used, to pass any resulting information from the iframe back to the parent page.
As a final step, once the message is received by the main page, the listeners can be unregistered, and the iframe finally be removed from the DOM.

Conclusion #

Same-origin policy imposes many restrictions for sites built on top of multiple origins that want to achieve a coherent PWA experience. For that reason, to provide the best experience to users, we strongly recommend against dividing sites into different origins.

For existing sites that are already built in this way, it can be challenging to make multi-origin PWAs work correctly, but we have explored some potential workarounds. Each can come with tradeoffs, so use your judgement when deciding which approach to take on your website.

When evaluating a long-term strategy or site redesign, consider migrating to a single origin, unless there's an important reason to keep the multi-origin architecture.

With many thanks for their technical reviews and suggestions: Penny Mclachlan, Paul Covell, Dominick Ng, Alberto Medina, Pete LePage, Joe Medley, Cheney Tsai, Martin Schierle, and Andre Bandarra.

Minify CSS

2019-05-02T00:00:00Z

CSS files can contain unnecessary characters, such as comments, whitespaces, and indentation. In production, these characters can be safely removed, to reduce file size without affecting how the browser processes the styles. This technique is called minification.

Loading unminified CSS #

Take a look at the following CSS block:

body {
  font-family: "Benton Sans", "Helvetica Neue", helvetica, arial, sans-serif;
  margin: 2em;
}

/* all titles need to have the same font, color and background */
h1 {
  font-style: italic;
  color: #373fff;
  background-color: #000000;
}

h2 {
  font-style: italic;
  color: #373fff;
  background-color: #000000;
}

This content is easy to read, at the cost of producing a larger than necessary file:

It uses spaces for indentation purposes and contains comments, which are ignored by the browser, so they can be removed.
The <h1> and <h2> elements have the same styles: instead of declaring them separately: "h1 {...} h2 {...}" they could be expressed as "h1, h2{...}".
The background-color, #000000 could be expressed as just #000.

After making these changes, you would obtain a more compact version of the same styles:

body{font-family:"Benton Sans","Helvetica Neue",helvetica,arial,sans-serif;margin:2em}h1,h2{font-style:italic;color:#373fff;background-color:#000}

You probably don't want to write CSS like that. Instead, you can write CSS as usual, and add a minification step to your build process. In this guide, you'll learn how to do it by using a popular build tool: webpack.

Measure #

You'll apply CSS minification to a site that has been used in other guides: Fav Kitties. This version of the site uses a cool CSS library: animate.css, to animate different page elements when a user votes for a cat 😺.

As a first step, you need to understand what would be the opportunity after minifying this file:

Open the measure page.
Enter the URL: https://fav-kitties-animated.glitch.me and click Run Audit.
Click View report.
Click on Performance and go the Opportunities section.

The resulting report shows that up to 16 KB can be saved from the animate.css file:

Now inspect the content of the CSS:

Open the Fav Kitties site in Chrome. (It might take a while for Glitch servers to respond the first time.)
Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Network tab.
Click the CSS filter.
Select the Disable cache checkbox.
Reload the app.

The page is requesting two CSS files, of 1.9KB and 76.2KB respectively.

Click animate.css.
Click the Response tab, to see the file contents.

Note that the stylesheet contains characters for whitespaces and indentation:

Next, you'll add some webpack plugins to your build process to minify these files.

CSS Minification with webpack #

Before jumping into the optimizations, take some time understanding how build process for the Fav Kitties site works:

By default, the resulting JS bundle that webpack produces would contain the content of the CSS files inlined. Since we want to maintain separate CSS files, we are using two complementary plugins:

mini-css-extract-plugin will extract each style sheet into its own file, as one of the steps of the build process.
webpack-fix-style-only-entries is used to correct an issue in wepback 4, to avoid generating an extra JS file for each CSS file listed in webpack-config.js.

You will now make some changes in the project:

Open the Fav Kitties project in Glitch.
To view the source, press View Source.
Click Remix to Edit to make the project editable.
Click Terminal (note: if the Terminal button does not show you may need to use the Fullscreen option).

To minify the resulting CSS, you'll use the optimize-css-assets-webpack-plugin:

In Glitch console, run npm install --save-dev optimize-css-assets-webpack-plugin.
Run refresh, so the changes are synchronized with the Glitch editor.

Next, go back to the Glitch editor, open the webpack.config.js file, and make the following modifications:

Load the module at the beginning of the file:

const OptimizeCSSAssetsPlugin = require("optimize-css-assets-webpack-plugin");

Then, pass an instance of the plugin to the plugins array:

  plugins: [
    new HtmlWebpackPlugin({template: "./src/index.html"}),
    new MiniCssExtractPlugin({filename: "[name].css"}),
    new FixStyleOnlyEntriesPlugin(),
    new OptimizeCSSAssetsPlugin({})
  ]

After making the changes a rebuild of the project will be triggered. This is how the resulting webpack.config.js will look like:

Next, you'll check the result of this optimization with performance tools.

Verify #

To preview the site, press View App. Then press Fullscreen .

If you got lost in any previous step, you can click here, to open an optimized version of the site.

To inspect the size and content of the files:

Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Network tab.
Click the CSS filter.
Select the Disable cache checkbox if it isn't already.
Reload the app.

You can inspect these files, and see that the new versions don't contain any whitespaces. Both files are much smaller, in particular, the animate.css has been reduced in ~26%, saving ~20KB!

As a final step:

Open the measure page.
Enter the URL of the optimized site.
Click View report.
Click on Performance and find the Opportunities section.

The report doesn't show "Minify CSS" as "Opportunity" anymore, and has now moved to "Passed Audits" section:

Since CSS files are render-blocking resources, if you apply minification on sites that use large CSS files, you can see improvements on metrics like First Contentful Paint.

Next steps and resources #

In this guide, we've covered CSS Minification with webpack, but the same approach can be followed with other build tools, like gulp-clean-css for Gulp, or grunt-contrib-cssmin for Grunt.

Minification can also be applied to other types of files. Check out the Minify and compress network payloads guide to learn more about tools to minify JS, and some complementary techniques, like compression.

Defer non-critical CSS

2019-02-17T00:00:00Z

CSS files are render-blocking resources: they must be loaded and processed before the browser renders the page. Web pages that contain unnecessarily large styles take longer to render.

In this guide, you'll learn how to defer non-critical CSS with the goal of optimizing the Critical Rendering Path, and improving First Contentful Paint (FCP).

Loading CSS in a suboptimal way #

The following example contains an accordion with three hidden paragraphs of text, each of which is styled with a different class:

This page requests a CSS file with eight classes, but not all of them are necessary to render the "visible" content.

The goal of this guide is to optimize this page, so only the critical styles are loaded synchronously, while the rest (like the ones applied to paragraphs), are loaded in a non-blocking way.

Measure #

Run Lighthouse on the page and go to the Performance section.

The report shows the First Contentful Paint metric with a value of "1s", and the opportunity Eliminate render-blocking resources, pointing to the style.css file:

To visualize how this CSS blocks rendering:

Open the page in Chrome.
Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Performance tab.
In the Performance panel, click Reload.

In the resulting trace, you'll see that the FCP marker is placed immediately after the CSS finishes loading:

This means that the browser needs to wait for all CSS to load and get processed before painting a single pixel on the screen.

Optimize #

To optimize this page, you need to know which classes are considered "critical". You'll use the Coverage Tool for that:

In DevTools, open the Command Menu, by pressing Control+Shift+P or Command+Shift+P (Mac).
Type "Coverage" and select Show Coverage.
Click the Reload button, to reload the page and start capturing the coverage.

Double-click on the report, to see classes marked in two colors:

Green (critical): These are the classes the browser needs to render the visible content (like the title, subtitle, and accordion buttons).
Red (non-critical): These styles apply to content that's not immediately visible (like the paragraphs inside the accordions).

With this information, optimize your CSS so that the browser starts processing critical styles immediately after page loads, while deferring non-critical CSS for later:

Extract the class definitions marked with green in the report obtained from the coverage tool, and put those classes inside a <style> block at the head of the page:

<style type="text/css">
.accordion-btn {background-color: #ADD8E6;color: #444;cursor: pointer;padding: 18px;width: 100%;border: none;text-align: left;outline: none;font-size: 15px;transition: 0.4s;}.container {padding: 0 18px;display: none;background-color: white;overflow: hidden;}h1 {word-spacing: 5px;color: blue;font-weight: bold;text-align: center;}
</style>

Then, load the rest of the classes asynchronously, by applying the following pattern:

<link rel="preload" href="styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="styles.css"></noscript>

This is not the standard way of loading CSS. Here's how it works:

link rel="preload" as="style" requests the stylesheet asynchronously. You can learn more about preload in the Preload critical assets guide.
The onload attribute in the link allows the CSS to be processed when it finishes loading.
"nulling" the onload handler once it is used helps some browsers avoid re-calling the handler upon switching the rel attribute.
The reference to the stylesheet inside of a noscript element works as a fallback for browsers that don't execute JavaScript.

The resulting page looks exactly like the previous version, even when most styles load asynchronously. Here's how the inlined styles and asynchronous request to the CSS file look like in the HTML file:

Monitor #

Use DevTools to run another Performance trace on the optimized page.

The FCP marker appears before the page requests the CSS, which means the browser doesn't need to wait for the CSS to load before rendering the page:

As a final step, run Lighthouse on the optimized page.

In the report you'll see that the FCP page has been reduced by 0.2s (a 20% improvement!):

The Eliminate render-blocking resources suggestion is no longer under Opportunities, and now belongs to the Passed Audits section:

Next steps & references #

In this guide, you learned how to defer non-critical CSS by manually extracting the unused code in the page. As a complement to this, the extract critical CSS guide covers some of the most popular tools to extract critical CSS and includes a codelab to see how they work in practice.

Demian Renzulli on web.dev

How Terra improved user engagement thanks to Dark Mode

What is dark mode? #

Identifying the "prefers light" vs "dark" user cohorts #

Mobile (Android) #

Desktop (Windows) #

Implementing a dark theme #

Measuring the impact of Terra's dark theme #

Mobile (Android) #

Desktop (Windows) #

Conclusion #

Building multiple Progressive Web Apps on the same domain

Technical terms #

The case for multiple, related PWAs #

Using separate origins #

Using the same origin #

Non-overlapping paths #

Overlapping/nested paths #

Challenges for multiple, same-origin PWAs #

Additional challenges for overlapping/nested paths #

Conclusion #

Additional resources #

Broadcast updates to pages with service workers

Production cases #

Tinder #

Squoosh #

Using Workbox #

Listen to service worker lifecycle events #

Inform the page of changes in cache data #

Using browser APIs #

Broadcast Channel API #

Client API #

Message Channel #

Next steps #

Additional resources #

Imperative caching guide

Production case #

Using Workbox #

Using browser APIs #

A simple prefetching example #

Prefetch product detail pages #

Beyond JSON data #

Conclusion #

Two-way communication with service workers

Using Workbox #

Using Browser APIs #

Broadcast Channel API #

Client API #

Message Channel #

Advanced APIs: Background Sync and Background Fetch #

Background Sync #

Background Fetch #

Next steps #

Workers overview

How workers can improve your website #

Web workers and service workers #

Similarities #

Differences #

Use cases #

Tools and libraries #

Comlink #

Workbox #

Next steps #

How Mercado Libre optimized for Web Vitals (TBT/FID)

Long tasks, First Input Delay, and Total Blocking Time #

Measure interactivity of product detail pages #

Use WebPageTest to visualize long tasks #

Use Lighthouse to determine Max Potential FID #

Optimize long tasks #

First iteration #

Measure impact #

Second iteration #

Measure impact #

Visualize progress for real users #

Next steps #

Adaptive loading with service workers

Production case #

Implement adaptive loading with Workbox #

Cloudinary Workbox Plugin #

Explore more adaptive loading strategies #

Configure `webpack-route-manifest` #

Improve navigations with `rel=prefetch` #

How to implement `rel=prefetch` #

Prefetch the product page with `<link rel="prefetch">` #

Extra credit: Use `prefetch` as a progressive enhancement #