Milica Mihajlija on web.dev

First-party cookie recipes

2022-06-07T00:00:00Z

Cookies can be first-party or third-party relative to the user's context; depending on which site the user is on at the time. If the cookie's registrable domain and scheme match the current top-level page, that is, what's displayed in the browser's address bar, the cookie is considered to be from the same site as the page and it's generally referred to as a first-party cookie.

Cookies from domains other than the current site are generally referred to as third-party cookies.

If the cookie you're setting is not used across sites, for example, it's used to manage sessions on your site and it's never used in a cross-site iframe, that cookie is always used in a first-party context.

By default, cookies can be shared across sites, accessed by JavaScript, and sent over HTTP connections, which comes with some privacy and security risks. While there's ongoing work to improve the default behavior, through Privacy Sandbox and other proposals such as origin-bound cookies, there's a lot you can do today by setting additional attributes on your cookies.

The following configuration is best practice, ensuring security and cross-browser compatibility for most first-party cookies. It will provide you with a safe foundation, which you can adjust to open up permissions only when necessary. This article also covers recipe variations for some specific use-cases.

The recipe #

Set-Cookie:
__Host-cookie-name=cookie-value;
Secure;
Path=/;
HttpOnly;
Max-Age=7776000;
SameSite=Lax;

Details

__Host is an optional prefix that makes some attributes mandatory and forbids others:

Secure must be present
Domain must be omitted
Path must be /

With __Host added, you can rely on the browser to check if attributes above are set in line with __Host rules and reject the cookie if not.

Secure protects cookies from being stolen on insecure networks because it only allows sending cookies over HTTPS connections. If you haven't fully migrated your site to HTTPS, make that a priority.

The Domain attribute specifies which hosts can receive a cookie. Omitting it restricts the cookie to the current document host, excluding subdomains: the cookie for example.com will be sent on every request to example.com but not on requests to images.example.com. If you have different apps running on different subdomains, this reduces the risk of one compromised domain allowing a door into the others.

Path indicates the path that must exist in the requested URL for the browser to send the Cookie header. Setting Path=/ means that the cookie is sent to all URL paths on that domain. The combination of no Domain and Path=/ makes the cookie bound to the origin as closely as possible, so it behaves similarly to other client-side storage such as LocalStorage—there's no confusion that example.com/a might receive different values to example.com/b.

The HttpOnly attribute adds some protection against malicious third-party scripts on your sites by restricting JavaScript access. It allows a cookie to be sent only in request headers and makes them unavailable to JavaScript via document.cookie.

Max-Age limits the life of a cookie as browser sessions can last a pretty long time and you don't want stale cookies hanging around forever. It's good for short-term cookies, such as user sessions or even shorter ones such as tokens for form submission. Max-Age is defined in seconds and in the example above it's set to 7776000 seconds which is 90 days. This is a reasonable default, which you can change depending on your use case.

SameSite=Lax restricts the cookie to only be sent on same-site requests. That is, where the request matches the current browsing context–the top level site the user is currently visiting which is displayed in their location bar. SameSite=Lax is the default in modern browsers but it's good practice to specify it for compatibility across browsers which may have different defaults. By explicitly marking the cookie as same-site only, you are restricting it to your first-party contexts, and you should not have to make changes to that cookie when third-party cookies go away.

To learn more about different cookie attributes, check out Set-Cookie documentation on MDN.

If you have a site with subdomains and want to have one session across all of them, the Host prefix can be too restrictive. For example news.site could have subdomains for topics, such as finance.news.site and sport.news.site and you'd want one user session on all of them. In that case, use the __Secure prefix instead of __Host and specify Domain.

The recipe #

Set-Cookie:
__Secure-cookie-name=cookie-value;
Secure;
Domain=news.site;
Path=/;
HttpOnly;
Max-Age=7776000;
SameSite=Lax;

Details

__Secure is an optional prefix which asserts fewer requirements than __Host: it only requires that the cookie be set with the Secure attribute.

While SameSite=Lax cookies are not sent on cross-site subrequests (for example, when loading embedded images or iframes on a third-party site), they are sent when a user is navigating to the origin site (for example, when following a link from a different site).

You can further restrict cookies access and disallow sending them along with requests initiated from third-party websites with SameSite=Strict. This is useful when you have cookies relating to functionality that will always be behind an initial navigation, such as changing a password or making a purchase.

The recipe #

Set-Cookie:
__Host-cookie-name=cookie-value;
Secure;
Path=/;
HttpOnly;
Max-Age=7776000;
SameSite=Strict;

Chrome and Firefox soon to reach major version 100

2022-02-15T00:00:00Z

Chrome and Firefox will reach version 100 in a couple of months. This has the potential to cause breakage on sites that rely on identifying the browser version to perform business logic. This post covers the timeline of events, the strategies that Chrome and Firefox are taking to mitigate the impact, and how you can help.

User-Agent string #

User-Agent (UA) is a string that browsers send in HTTP headers, so servers can identify the browser. The string is also accessible through JavaScript with navigator.userAgent. It's usually formatted as follows:

<browser_name>/<major_version>.<minor_version>

For example, the latest release versions of browsers at the time of publishing this post are:

Chrome: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.54 Safari/537.36
Firefox: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:96.0) Gecko/20100101 Firefox/96.0
Safari: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.2 Safari/605.1.15

Major version 100—three-digit version number #

Major version 100 is a big milestone for both Chrome and Firefox. It also has the potential to cause breakage on websites as we move from a two-digit to a three-digit version number. Web developers use all kinds of techniques for parsing these strings, from custom code to using User-Agent parsing libraries, which can then be used to determine the corresponding processing logic. The User-Agent and any other version reporting mechanisms will soon report a three-digit version number.

Version 100 timelines #

Version 100 browsers will be first released in experimental versions (Chrome Canary, Firefox Nightly), then beta versions, and then finally on the stable channel.

Browser	Timeline
Chrome (release schedule)	March 29, 2022
Firefox (release schedule)	May 3, 2022

Why can a three-digit version number be problematic? #

When browsers first reached version 10 a little over 12 years ago, many issues were discovered with User-Agent parsing libraries as the major version number went from one digit to two.

Without a single specification to follow, different browsers have different formats for the User-Agent string, and site-specific User-Agent parsing. It's possible that some parsing libraries may have hard-coded assumptions or bugs that don't take into account three-digit major version numbers. Many libraries improved the parsing logic when browsers moved to two-digit version numbers, so hitting the three-digit milestone is expected to cause fewer problems. Mike Taylor, an engineer on the Chrome team, has done a survey of common UA parsing libraries which didn't uncover any issues. Running Chrome experiments in the field has surfaced some issues, which are being worked on.

What are browsers doing about it? #

Both Firefox and Chrome have been running experiments where current versions of the browser report being at major version 100 in order to detect possible website breakage. This has led to a few reported issues, some of which have already been fixed. These experiments will continue to run until the release of version 100.

There are also backup mitigation strategies in place, in case version 100 release to stable channels causes more damage to websites than anticipated.

Chrome mitigation #

In Chrome, the backup plan is to use a flag to freeze the major version at 99 and report the real major version number in the minor version part of the User-Agent string (the code has already landed).

The Chrome version as reported in the User-Agent string follows the pattern <major_version>.<minor_version>.<build_number>.<patch_number>.

If the backup plan is employed, then the User-Agent string would look like this:

99.101.4988.0

Chrome is also running experiments to ensure that reporting a three-digit value in the minor version part of the string does not result in breakage, since the minor version in the Chrome User-Agent string has reported 0 for a very long time. The Chrome team will decide on whether to resort to the backup option based on the number and severity of the issues reported.

Firefox mitigation #

In Firefox, the strategy will depend on how important the breakage is. Firefox has a site interventions mechanism. Mozilla webcompat team can hot fix broken websites in Firefox using this mechanism. If you type about:compat in the Firefox URL bar, you can see what is currently being fixed. If a site breaks with the major version being 100 on a specific domain, it is possible to fix it by sending version 99 instead.

If the breakage is widespread, it is possible to freeze the major version number. There are then different possible strategies, each of them with their pros and cons. Mozilla can send the real version number as a minor version number, freeze the string entirely as-is, or send the real version number through other parameters.

Every strategy that adds complexity to the User-Agent string has a strong impact on the ecosystem. Let's work together to avoid yet another quirky behavior.

What can you do to help? #

In Chrome and Firefox Nightly, you can configure the browser to report the version as 100 right now and report any issues you come across.

Configure Chrome to report the major version as 100 #

Go to chrome://flags/#force-major-version-to-100.
Set the option to Enabled.

Configure Firefox Nightly to report the major version as 100 #

Open Firefox Nightly's Settings menu.
Search for "Firefox 100" and then check the "Firefox 100 User-Agent String" option.

Test and file reports #

If you are a website maintainer, test your website with Chrome and Firefox 100. Review your User-Agent parsing code and libraries, and ensure they are able to handle three-digit version numbers. We have compiled some of the patterns that are currently breaking.
If you develop a User-Agent parsing library, add tests to parse versions greater than and equal to 100. Our early tests show that recent versions of libraries can handle it correctly. However, the web has a long legacy, so if you have old versions of parsing libraries, it's time to check for issues and eventually upgrade.
If you are browsing the web and notice any issues with the major version 100, file a report on webcompat.com.

How CLS optimizations increased Yahoo! JAPAN News's page views per session by 15%

2021-03-09T00:00:00Z

Yahoo! JAPAN is one of the largest media companies in Japan, providing over 79 billion page views per month. Their news platform, Yahoo! JAPAN News has more than 22 billion page views per month and an engineering team dedicated to improving the user experience.

By continuously monitoring Core Web Vitals (CWV), they correlated the site's improved Cumulative Layout Shift (CLS) score with a 15% increase in page views per session and 13% increase in session duration.

0.2

CLS improvement

15.1_%

More page views per session

13.3_%

Longer session duration

Page content moving around unexpectedly often causes accidental clicks, disorientation on the page, and ultimately user frustration. Frustrated users tend not to stick around for long. To keep users happy, the page layout should stay stable through the entire lifecycle of the user journey. For Yahoo! JAPAN News this improvement had a significant positive impact on business critical engagement metrics.

For technical details on how they improved the CLS, read the Yahoo! JAPAN News engineering team's post.

Identifying the issue #

Monitoring Core Web Vitals, including CLS, is crucial in catching issues and identifying where they're coming from. At Yahoo! JAPAN News, Search Console provided a great overview of groups of pages with performance issues and Lighthouse helped identify per-page opportunities to improve page experience. Using these tools, they discovered that the article detail page had poor CLS.

Google Search Console Core Web Vitals Report.

Lighthouse "Avoid large layout shifts" audit shows which elements are contributing to CLS score and how much.

It's important to keep in mind the cumulative part of the Cumulative Layout Shift—the score is captured through the entire page lifecycle. In the real-world, the score can include shifts that happen as a result of user interactions such as scrolling a page or tapping a button. To collect CLS scores from the field data, the team integrated web-vitals JavaScript library reporting.

The team used Chrome DevTools to identify which elements were making layout shifts on the page. Layout Shift Regions in DevTools visualizes elements that contribute to CLS by highlighting them with a blue rectangle whenever a layout shift happens.

Visualized layout shifts.

They figured out that a layout shift occurred after the hero image at the top of the article was loaded for the first view.

Layout shift on the article detail page.

In the example above, when the image finishes loading, the text gets pushed down (the position change is indicated with the red line).

Improving CLS for images #

For fixed-size images, layout shifts can be prevented by specifying the width and height attributes in the img element and using the CSS aspect-ratio property available in modern browsers. However, Yahoo! JAPAN News needed to support not only modern browsers, but also browsers installed in relatively old operating systems such as iOS 9.

They used Aspect Ratio Boxes—a method which uses markup to reserve the space on the page before the image is loaded. This method requires knowing the aspect ratio of the image in advance, which they were able to get from the backend API.

Left: reserved blank space for the image at the top of the page; right: the hero image loaded in the reserved space without layout shifts.

Results #

The number of URLs with poor performance in Search Console decreased by 98% and CLS in lab data decreased from about 0.2 to 0. More importantly, there were several correlated improvements in business metrics.

Search Console after improvements.

When Yahoo! JAPAN News compared user engagement metrics before and after CLS optimization, they saw multiple improvements:

15.1_%

More page views per session

13.3_%

Longer session duration

1.72_%*

Lower bounce rate (*percentage points)

By improving CLS and other Core Web Vitals metrics, Yahoo! JAPAN News also got the "Fast page" label in the context menu of Chrome Android.

"Fast page" label in Chrome on Android.

Layout shifts are frustrating and discourage users from reading more pages, but that can be improved by using the appropriate tools, identifying issues, and applying best practices. Improving CLS is a chance to improve your business.

For more information, read the Yahoo! JAPAN engineering team's post.

Life of a payment transaction

2020-05-25T00:00:00Z

Web Payments APIs are dedicated payment features built into the browser for the first time. With Web Payments, merchant integration with payment apps becomes simpler while the customer experience gets streamlined and more secure.

To learn more about the benefits of using Web Payments check out Empowering payment apps with Web Payments.

This article walks you through a payment transaction on a merchant website and helps you understand how payment app integration works.

The process involves 6 steps:

The merchant initiates a payment transaction.
The merchant shows a payment button.
The customer presses the payment button.
The browser launches the payment app.
If the customer changes any details (such as shipping options or their address), the merchant updates the transaction details reflecting the change.
After the customer confirms the purchase, the merchant validates the payment and completes the transaction.

Step 1: The merchant initiates a payment transaction #

When a customer decides to make a purchase, the merchant initiates the payment transaction by constructing a PaymentRequest object. This object includes important information about the transaction:

Acceptable payment methods and their data to process the transaction.
Details, such as the total price (required) and information about the items.
Options in which merchants can request shipping information such as a shipping address and a shipping option.
Merchants can also request the billing address, the payer's name, email, and phone number.
Merchants can also include optional shipping type (shipping, delivery, or pickup) in the PaymentRequest. The payment app can use that as a hint to display the correct labels in its UI.

const request = new PaymentRequest([{
  supportedMethods: 'https://bobpay.xyz/pay',
  data: {
    transactionId: '****'
  }
}], {
  displayItems: [{
    label: 'Anvil L/S Crew Neck - Grey M x1',
    amount: { currency: 'USD', value: '22.15' }
  }],
  total: {
    label: 'Total due',
    amount: { currency: 'USD', value : '22.15' }
  }
}, {
  requestShipping: true,
  requestBillingAddress: true,
  requestPayerEmail: true,
  requestPayerPhone: true,
  requestPayerName: true,
  shippingType: 'delivery'
});

Including a transaction ID

Some payment handlers may require the merchant to provide the transaction ID which they have issued in advance as part of the transaction information. A typical integration includes communication between the merchant's and the payment handler's server to reserve the total price. This prevents malicious customers from manipulating the price and cheating the merchant with a validation at the end of the transaction.

The merchant can pass a transaction ID as part of the PaymentMethodData object's data property.

Provided the transaction information, the browser goes through a discovery process of payment apps specified in the PaymentRequest based on the payment method identifiers. This way, the browser can determine the payment app to launch as soon as the merchant is ready to proceed with the transaction.

To learn how the discovery process works in detail check out Setting up a payment method.

Step 2: The merchant shows a payment button #

Merchants can support many payment methods, but should only present the payment buttons for those that a customer can actually use. Showing a payment button that is unusable is poor user experience. If a merchant can predict that a payment method specified in the PaymentRequest object won't work for the customer, they can provide a fallback solution or not show that button at all.

Using a PaymentRequest instance, a merchant can query whether a customer has the payment app available.

Does the customer have the payment app available? #

The canMakePayment() method of PaymentRequest returns true if a payment app is available on the customer's device. "Available" means that a payment app that supports the payment method is discovered, and that the platform-specific payment app is installed, or the web-based payment app is ready to be registered.

const canMakePayment = await request.canMakePayment();
if (!canMakePayment) {
  // Fallback to other means of payment or hide the button.
}

Step 3: The customer presses the payment button #

When the customer presses the payment button, the merchant calls the show() method of the PaymentRequest instance which immediately triggers the launch of the payment UI.

In case the final total price is set dynamically (for example, retrieved from a server), the merchant can defer the launch of the payment UI until the total is known.

Deferring the launch of the payment UI #

Check out a demo of deferring the payment UI until the final total price is determined.

To defer the payment UI, the merchant passes a promise to the show() method. The browser will show a loading indicator until the promise resolves and the transaction is ready to begin.

const getTotalAmount = async () => {
  // Fetch the total amount from the server, etc.
};

try {
  const result = await request.show(getTotalAmount());
  // Process the result…
} catch(e) {
  handleError(e);
}

If there is no promise specified as an argument for show(), the browser will launch the payment UI immediately.

Step 4: The browser launches the payment app #

The browser can launch a platform-specific or a web-based payment app. (You can learn more about how Chrome determines which payment app to launch.)

How the payment app is built is up to the developer for the most part, but the events emitted from and to the merchant, as well as the structure of the data passed along with those events, are standardized.

When the payment app is launched, it receives the transaction information passed to the PaymentRequest object in Step 1, which includes the following:

Payment method data
Total price
Payment options

The payment app uses the transaction information to label its UI.

Step 5: How a merchant can update the transaction details depending on customer's actions #

Customers have an option to change the transaction details such as payment method and shipping option in the payment app. While the customer makes changes, the merchant receives the change events and updates the transaction details.

There are four types of events a merchant can receive:

Payment method change event
Shipping address change event
Shipping option change event
Merchant validation event

Payment method change event #

A payment app can support multiple payment methods and a merchant may offer a special discount depending on the customer's selection. To cover this use case, the payment method change event can inform the merchant of the new payment method so that they can update the total price with the discount and return it back to the payment app.

request.addEventListener('paymentmethodchange', e => {
  e.updateWith({
    // Add discount etc.
  });
});

Shipping address change event #

A payment app can optionally provide the customer's shipping address. This is convenient for customers because they don't have to manually enter any details into a form and they can store their shipping address in their preferred payment apps, rather than on multiple different merchant websites.

If a customer updates their shipping address in a payment app after the transaction has been initiated, a 'shippingaddresschange' event will be sent to the merchant. This event helps the merchant determine the shipping cost based on the new address, update the total price, and return it to the payment app.

request.addEventListener('shippingaddresschange', e => {
  e.updateWith({
    // Update the details
  });
});

If the merchant can't ship to the updated address, they can provide an error message by adding an error parameter to the transaction details returned to the payment app.

Shipping option change event #

A merchant can offer multiple shipping options to the customer and can delegate that choice to the payment app. The shipping options are displayed as a list of prices and service names the customer can select from. For example:

Standard shipping - Free
Express shipping - 5 USD

When a customer updates the shipping option in a payment app, a 'shippingoptionchange' event will be sent to the merchant. The merchant can then determine the shipping cost, update the total price, and return it to the payment app.

request.addEventListener('shippingoptionchange', e => {
  e.updateWith({
    // Update the details
  });
});

The merchant can dynamically modify the shipping options based on the customer's shipping address as well. This is useful when a merchant wants to offer different sets of shipping options for domestic and international customers.

Merchant validation event #

For additional security, a payment app can perform a merchant validation before proceeding to the payment flow. The design of the validation mechanism is up to the payment app, but the merchant validation event serves to inform the merchant of the URL they can use to validate themselves.

request.addEventListener('merchantvalidation', e => {
  e.updateWith({
    // Use `e.validateURL` to validate
  });
});

Step 6: The merchant validates the payment and completes the transaction #

When the customer successfully authorizes the payment, the show() method returns a promise that resolves to a PaymentResponse. The PaymentResponse object includes the following information:

Payment result details
Shipping address
Shipping option
Contact information

At this point, the browser UI may still show a loading indicator meaning that the transaction is not completed yet.

If the payment app is terminated because of a payment failure or error, the promise returned from show() rejects, and the browser terminates the payment transaction.

Processing and validating the payment #

The details in PaymentResponse is the payment credential object returned from the payment app. The merchant can use the credential to process or validate the payment. How this critical process works is up to the payment handler.

Completing or retrying the transaction #

After the merchant determines whether the transaction has succeded or failed, they can either:

Call the .complete() method to complete the transaction and dismiss the loading indicator.
Let the customer retry by calling the retry() method.

async function doPaymentRequest() {
  try {
    const request = new PaymentRequest(methodData, details, options);
    const response = await request.show();
    await validateResponse(response);
  } catch (err) {
    // AbortError, SecurityError
    console.error(err);
  }
}

async function validateResponse(response) {
  try {
    const errors = await checkAllValuesAreGood(response);
    if (errors.length) {
      await response.retry(errors);
      return validateResponse(response);
    }
    await response.complete("success");
  } catch (err) {
    // Something went wrong…
    await response.complete("fail");
  }
}
// Must be called as a result of a click
// or some explicit user action.
doPaymentRequest();

Next Steps #

Learn how to declare a payment method identifier in detail in Setting up a payment method.
Learn how to build a platform-specific payment app in Android payment apps developer's guide.
Learn how to build a web-based payment app in Web-based payment apps developer's guide.

Adaptive loading: improving web performance on slow devices

2019-12-16T00:00:00Z

Device capabilities and network connections vary a lot. Sites that delight users on high-end devices can be unusable on low-end ones. Sites that load smoothly on fast networks can come to a halt on slow ones. Any user can experience a slow website, that's why developing "one-size fits all" solutions may not always work.

In their Chrome Dev Summit talk, Addy Osmani from Google and Nate Schloss from Facebook explore a solution to that problem—a pattern for delivering pages that better cater to a variety of user constraints. They call it adaptive loading.

What is adaptive loading? #

Adaptive loading involves delivering different experiences to different users based on their network and hardware constraints, specifically:

A fast core experience for all users (including low-end devices).
Progressively adding high-end-only features, if a user's network and hardware can handle it.

By optimizing for specific hardware and network constraints you enable every user to get the best possible experience for their device. Tailoring the experience to users' constraints can include:

Serving low-quality images and videos on slow networks.
Throttling the frame-rate of animations on low-end devices.
Avoiding computationally expensive operations on low-end devices.
Blocking third-party scripts on slower devices.
Loading non-critical JavaScript for interactivity only on fast CPUs.

Browser support and how to implement adaptive loading #

The signals you can use for adaptive loading are listed below. Browser support is also included for each signal:

`Navigator.deviceMemory` #

The navigator.deviceMemory property is used to reduce memory consumption on low-end devices.

Browser support

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

Source

`Navigator.hardwareConcurrency` #

The navigator.hardwareConcurrency property is the CPU core count. It is used to limit costly JavaScript execution and reduce CPU intensive logic when a device can't handle it well.

Browser support

Chrome 37, Supported 37
Firefox 48, Supported 48
Edge 15, Supported 15
Safari, Not supported

Source

`NetworkInformation.effectiveType` #

The navigator.connection.effectiveType property is used to fine-tune data transfer to use less bandwidth.

Browser support

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

Source

`NetworkInformation.saveData` #

The navigator.connection.saveData property is used to leverage the user's Data Saver preferences.

Browser support

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

Source

There are two places where you can make a decision about what to serve to users: the client and the server. On the client, you have the JavaScript APIs noted above. On the server, you can use client hints to get insight into the user's device capabilities and the network they're connected to.

Adaptive loading in React #

React Adaptive Loading Hooks & Utilities is a suite for the React ecosystem that makes it easier to adapt your sites to lower-end devices. It includes:

The useNetworkStatus() hook for adapting based on network status (slow-2g, 2g, 3g, or 4g).
The useSaveData() hook for adapting based on the user's Data Saver preferences.
The useHardwareConcurrency() hook for adapting based on the number of logical CPU processor cores on the user's device.
The useMemoryStatus() hook for adapting based on the user's device memory (RAM).

Each hook accepts an optional argument for setting the initial value. This option is useful in two scenarios: when the user's browser does not support the relevant API and for server-side rendering where you can use the client hint data to set the initial value on the server. For example, the useNetworkStatus() hook can use the initial value passed from client hint for server-side rendering and, when executed on the client, update itself if the network effective type changes.

React Adaptive Loading Hooks & Utilities are implemented using web platform APIs (Network Information, Device Memory and Hardware Concurrency). You can use the same APIs to apply adaptive loading concepts to other frameworks and libraries, such as Angular, Vue, and others.

Adaptive loading in action #

This section explores demos of how you could use adaptive loading and real-world examples from sites such as Facebook, eBay, Tinder, and others.

The React Movie demo shows how to adapt media serving based on the network status. It's an application for browsing movies that shows posters, summaries, and cast lists. Based on the user's effective connection type, it serves high-quality posters on fast connections and low-quality posters on slow ones.

Twitter has a Data Saver mode designed to reduce the amount of data used. In this mode, preview images load in low-resolution and large images load only when you tap on the preview. With this option enabled, users on iOS and Android saved 50% in data-usage from images, and users on the web saved 80%. Here's a React demo that uses the Save Data hook to replicate the Twitter timeline. Try opening your DevTools Network panel and looking at the difference in the amount of data transferred as you scroll while Save Data is disabled versus when it's enabled.

A screencast comparing scrolling the Twitter timeline with Data Saver on and off. With Data Saver on, only image previews are loaded and videos don't autoplay.

eBay conditionally turns on and off features like zooming when a user's hardware or network conditions don't support them well. You can achieve this through adaptive code-splitting and code loading—a way to conditionally load more highly interactive components or run more computationally heavy operations on high-end devices, while not sending those scripts down to users on slower devices. Check out the video at 16 mins where Addy shows this pattern implemented with React.lazy() and Suspense on a demo eBay product page.

Tinder is using a number of adaptive loading patterns in its web and Lite app to keep the experience fast for everyone. If a user is on a slow network or has Data Saver enabled, they disable video autoplay, limit route prefetching and limit loading the next image in the carousel to loading images one at a time as users swipe. After implementing these optimizations, they've seen significant improvements in average swipe count in countries such as Indonesia.

Adaptive loading at Facebook #

One issue that comes up in adaptive loading is grouping devices into high-end and low-end classes based on available signals. On mobile devices the user-agent (UA) string provides the device name which enables Facebook to use publicly available data on device characteristics to group mobile devices into classes. However, on desktop devices the only relevant information the UA provides is the device's operating system.

For grouping desktop devices, Facebook logs the data about the operating system, CPU cores (from navigator.hardwareConcurrency), and RAM memory (navigator.deviceMemory) in their performance monitoring. Looking at the relationships between different types of hardware and performance, they classified devices into five categories. With hardware classes integrated into performance monitoring, they get a more complete picture of how people use Facebook products depending on their device and can identify regressions more easily.

Check out the video at 24 mins, where Nate walks through how Facebook approaches device grouping and uses adaptive loading for animations and loading JavaScript.

Learn more about adaptive loading #

Adaptive loading is all about designing your sites with inclusivity in mind. Build a core experience that works great for everyone, then toggle or layer features that make it even more awesome if a user has enough memory, CPU, or a fast network. To learn more about adaptive loading, check out the available demos and watch the Chrome Dev Summit talk:

Route prefetching in Next.js

2019-11-08T00:00:00Z

What will you learn? #

In this post you'll learn how routing in Next.js works, how it's optimized for speed, and how to customize it to best fit your needs.

The `<Link>` component #

In Next.js, you don't need to set up routing manually. Next.js uses file-system-based routing, which lets you just create files and folders inside the ./pages/ directory:

To link to different pages, use the <Link> component, similarly to how you'd use the good old <a> element:

<Link href="/margherita">
  <a>Margherita</a>
</Link>

When you use the <Link> component for navigation, Next.js does a little bit more for you. Normally, a page is downloaded when you follow a link to it, but Next.js automatically prefetches the JavaScript needed to render the page.

When you load a page with a few links, odds are that by the time you follow a link, the component behind it has already been fetched. This improves application responsiveness by making navigations to new pages quicker.

In the example app below, the index.js page links to margherita.js with a <Link>:

Use Chrome DevTools to verify that margherita.js is prefetched:

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.
Select the Disable cache checkbox.
Reload the page.

When you load index.js, the Network tab shows that margherita.js is downloaded too:

How automatic prefetching works #

Next.js prefetches only links that appear in the viewport and uses the Intersection Observer API to detect them. It also disables prefetching when the network connection is slow or when users have Save-Data turned on. Based on these checks, Next.js dynamically injects <link rel="preload"> tags to download components for subsequent navigations.

Next.js only fetches the JavaScript; it doesn't execute it. That way, it's not downloading any additional content that the prefetched page might request until you visit the link.

Avoid unnecessary prefetching #

To avoid downloading unnecessary content, you can disable prefetching for rarely visited pages by setting the prefetch property on <Link> to false:

<Link href="/pineapple-pizza" prefetch={false}>
  <a>Pineapple pizza</a>
</Link>

In this second example app, the index.js page has a <Link> to pineapple-pizza.js with prefetch set to false:

To inspect the network activity, follow the steps from the first example. When you load index.js, the DevTools Network tab shows that margherita.js is downloaded, but pineapple-pizza.js is not:

Prefetching with custom routing #

The <Link> component is suitable for most use cases, but you can also build your own component to do routing. Next.js makes this easy for you with the router API available in next/router. If you want to do something (for example, submit a form) before navigating to a new route, you can define that in your custom routing code.

When you use custom components for routing, you can add prefetching to them too. To implement prefetching in your routing code, use the prefetch method from useRouter.

Take a look at components/MyLink.js in this example app:

Prefetching is done inside the useEffect hook. If the prefetch property on a <MyLink> is set to true, the route specified in the href property gets prefetched when that <MyLink> is rendered:

useEffect(() => {
    if (prefetch) router.prefetch(href)
});

When you click the link, the routing is done in handleClick. A message gets logged to the console, and the push method navigates to the new route specified in href:

const handleClick = e => {
    e.preventDefault();
    console.log("Having fun with Next.js.");
    router.push(href);
};

In this example app, the index.js page has a <MyLink> to margherita.js and pineapple-pizza.js. The prefetch property is set to true on /margherita and to false on /pineapple-pizza.

<MyLink href="/margherita" title="Margherita" prefetch={true} />
<MyLink href="/pineapple-pizza"  title="Pineapple pizza" prefetch={false} />

When you load index.js, the Network tab shows that margherita.js is downloaded and pineapple-pizza.js is not:

When you click on either link, the Console logs "Having fun with Next.js." and navigates to the new route:

Conclusion #

When you use <Link>, Next.js automatically prefetches the JavaScript needed to render the linked page, which makes navigating to new pages faster. If you are using custom routing, you can use the Next.js router API to implement prefetching yourself. Avoid downloading content unnecessarily by disabling prefetching for rarely visited pages.

Code splitting with dynamic imports in Next.js

2019-11-08T00:00:00Z

What will you learn? #

This post explains different types of code splitting and how to use dynamic imports to speed up your Next.js apps.

Route-based and component-based code splitting #

By default, Next.js splits your JavaScript into separate chunks for each route. When users load your application, Next.js only sends the code needed for the initial route. When users navigate around the application, they fetch the chunks associated with the other routes. Route-based code splitting minimizes the amount of script that needs to be parsed and compiled at once, which results in faster page load times.

While route-based code splitting is a good default, you can further optimize the loading process with code splitting on the component level. If you have large components in your app, it's a great idea to split them into separate chunks. That way, any large components that are not critical or only render on certain user interactions (like clicking a button) can be lazy-loaded.

Next.js supports dynamic import(), which allows you to import JavaScript modules (including React components) dynamically and load each import as a separate chunk. This gives you component-level code splitting and enables you to control resource loading so that users only download the code they need for the part of the site that they're viewing. In Next.js, these components are server-side rendered (SSR) by default.

Dynamic imports in action #

This post includes several versions of a sample app that consists of a simple page with one button. When you click the button, you get to see a cute puppy. As you move through each version of the app, you'll see how dynamic imports are different from static imports and how to work with them.

In the first version of the app, the puppy lives in components/Puppy.js. To display the puppy on the page, the app imports the Puppy component in index.js with a static import statement:

import Puppy from "../components/Puppy";

To see how Next.js bundles the app, inspect the network trace in DevTools:

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.
Select the Disable cache checkbox.
Reload the page.

When you load the page, all the necessary code, including the Puppy.js component, is bundled in index.js:

When you press the Click me button, only the request for the puppy JPEG is added to the Network tab:

The downside of this approach is that even if users don't click the button to see the puppy, they have to load the Puppy component because it's included in index.js. In this little example that's not a big deal, but in real-world applications it's often a huge improvement to load large components only when necessary.

Now check out a second version of the app, in which the static import is replaced with a dynamic import. Next.js includes next/dynamic, which makes it possible to use dynamic imports for any components in Next:

import Puppy from "../components/Puppy";
import dynamic from "next/dynamic";

// ...

const Puppy = dynamic(import("../components/Puppy"));

Follow the steps from the first example to inspect the network trace.

When you first load the app, only index.js is downloaded. This time it's 0.5 KB smaller (it went down from 37.9 KB to 37.4 KB) because it doesn't include the code for the Puppy component:

The Puppy component is now in a separate chunk, 1.js, which is loaded only when you press the button:

In real-world applications, components are often much larger, and lazy loading them can trim your initial JavaScript payload by hundreds of kilobytes.

Dynamic imports with custom loading indicator #

When you lazy-load resources, it's good practice to provide a loading indicator in case there are any delays. In Next.js, you can do that by providing an additional argument to the dynamic() function:

const Puppy = dynamic(() => import("../components/Puppy"), {
  loading: () => <p>Loading...</p>
});

To see the loading indictor in action, simulate slow network connection in DevTools:

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.
Select the Disable cache checkbox.
In the Throttling drop-down list, select Fast 3G.
Press the Click me button.

Now when you click the button it takes a while to load the component and the app displays the "Loading…" message in the meantime.

Dynamic imports without SSR #

If you need to render a component only on the client side (for example, a chat widget) you can do that by setting the ssr option to false:

const Puppy = dynamic(() => import("../components/Puppy"), {
  ssr: false,
});

Conclusion #

With support for dynamic imports, Next.js gives you component-level code splitting, which can minimize your JavaScript payloads and improve application load time. All components are server-side rendered by default and you can disable this option whenever necessary.

Efficiently load third-party JavaScript

2019-08-14T00:00:00Z

If a third-party script is slowing down your page load, you have two options to improve performance:

Remove it if it doesn't add clear value to your site.
Optimize the loading process.

This post explains how to optimize the loading process of third-party scripts with the following techniques:

Using the async or defer attribute on <script> tags
Establishing early connections to required origins
Lazy loading
Optimizing how you serve third-party scripts

Use `async` or `defer` #

Because synchronous scripts delay DOM construction and rendering, you should always load third-party scripts asynchronously unless the script has to run before the page can be rendered.

The async and defer attributes tell the browser that it may go on parsing the HTML while loading the script in the background, and then execute the script after it loads. This way, script downloads don't block DOM construction and page rendering. The result is that the user can see the page before all scripts have finished loading.

<script async src="script.js">

<script defer src="script.js">

The difference between async and defer is when they start executing the scripts.

`async` #

Scripts with the async attribute execute at the first opportunity after they finish downloading and before the window's load event. This means it's possible (and likely) that async scripts will not be executed in the order in which they appear in the HTML. It also means they can interrupt DOM building if they finish downloading while the parser is still at work.

`defer` #

Scripts with the defer attribute execute after HTML parsing is completely finished, but before the DOMContentLoaded event. defer guarantees scripts will be executed in the order they appear in the HTML and will not block the parser.

Use async if it's important to have the script run earlier in the loading process.
Use defer for less critical resources. A video player that's below-the-fold, for example.

Using these attributes can significantly speed up page load. For example, Telegraph recently deferred all of their scripts, including ads and analytics, and improved the ad loading time by an average of four seconds.

Establish early connections to required origins #

You can save 100–500 ms by establishing early connections to important third-party origins.

Two <link> types can help here:

preconnect
dns-prefetch

`preconnect` #

<link rel="preconnect"> informs the browser that your page intends to establish a connection to another origin, and that you'd like the process to start as soon as possible. When the request for a resource from the pre-connected origin is made, the download starts immediately.

<link rel="preconnect" href="https://cdn.example.com">

`dns-prefetch` #

<link rel="dns-prefetch> handles a small subset of what is handled by <link rel="preconnect">. Establishing a connection involves the DNS lookup and TCP handshake, and for secure origins, TLS negotiations. dns-prefetch instructs the browser to only resolve the DNS of a specific domain before it has been explicitly called.

The preconnect hint is best used for only the most critical connections; for less critical third-party domains use <link rel=dns-prefetch>.

<link rel="dns-prefetch" href="http://example.com">

Browser support for dns-prefetch is slightly different from preconnect support, so dns-prefetch can serve as a fallback for browsers that don't support preconnect. Use separate link tags to implement this safely:

<link rel="preconnect" href="http://example.com">
<link rel="dns-prefetch" href="http://example.com">

Lazy-load third-party resources #

Embedded third-party resources can be a big contributor to slow page speed when constructed poorly. If they aren't critical or are below the fold (that is, if users have to scroll to view them), lazy loading is a good way to improve page speed and paint metrics. This way, users will get the main page content faster and have a better experience.

One effective approach is to lazy-load third-party content after the main page content loads. Ads are a good candidate for this approach.

Ads are an important source of income for many sites, but users come for the content. By lazy loading ads and delivering the main content faster, you can increase the overall viewability percentage of an ad. For example, MediaVine switched to lazy-loading ads and saw a 200% improvement in page load speed. DoubleClick have guidance on how to lazy-load ads in their official documentation.

An alternative approach is to load third-party content only when users scroll down to that section of the page.

Intersection Observer is a browser API that efficiently detects when an element enters or exits the browser's viewport and it can be used to implement this technique. lazysizes is a popular JavaScript library for lazy loading images and iframes. It supports YouTube embeds and widgets. It also has optional support for IntersectionObserver.

Using the loading attribute for lazy loading images and iframes is a great alternative to JavaScript techniques, and it has recently become available in Chrome 76!

Optimize how you serve third-party scripts #

Third-party CDN hosting #

It's common for third-party vendors to provide URLs of JavaScript files that they host, usually on a content delivery network (CDN). The benefits of this approach are that you can get started quickly—just copy and paste the URL—and there's no maintenance overhead. The third-party vendor handles server configuration and script updates.

But because they are not on the same origin as the rest of your resources, loading files from a public CDN comes with a network cost. The browser needs to perform a DNS lookup, establish a new HTTP connection, and, on secure origins, perform an SSL handshake with the vendor's server.

When you use files from third-party servers, you rarely have control over caching. Relying on someone else's caching strategy might cause scripts to be unnecessarily re-fetched from the network too often.

Self-host third-party scripts #

Self-hosting third-party scripts is an option that gives you more control over a script's loading process. By self-hosting you can:

Reduce DNS lookup and round-trip times.
Improve HTTP caching headers.
Take advantage of HTTP/2, or the newer HTTP/3.

For example, Casper managed to shave 1.7 seconds off load time by self-hosting an A/B testing script.

Self-hosting comes with one big downside though: scripts can go out of date and won't get automatic updates when there's an API change or a security fix.

Use service workers to cache scripts from third-party servers #

An alternative to self-hosting that allows you greater control over caching while still getting the third-party CDN benefits is using service workers to cache scripts from third-party servers. This gives you control over how often scripts are re-fetched from the network and makes it possible to create a loading strategy that throttles requests for non-essential third-party resources until the page reaches a key user moment. Using preconnect to establish early connections in this case can also mitigate the network costs to an extent.

Identify slow third-party JavaScript

2019-08-14T00:00:00Z

As a developer, you often don't have control over which third-party scripts your site loads. Before you can optimize third-party content you have to do some detective work to find out what's making your site slow. 🕵️

In this post, you'll learn how to use Lighthouse and Chrome DevTools to identify slow third-party resources. The post walks through increasingly robust techniques which are best used in combination.

If you only have 5 minutes #

The Lighthouse Performance audit helps you discover opportunities to speed up page loads. Slow third-party scripts are likely to appear in the Diagnostics section under the Reduce JavaScript execution time and Avoid enormous network payloads audits.

To run an audit:

Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Lighthouse tab.
Click Mobile.
Select the Performance checkbox. (You can clear the rest of the checkboxes in the Audits section.)
Click Simulated Fast 3G, 4x CPU Slowdown.
Select the Clear Storage checkbox.
Click Run audits.

Third-party usage #

The Lighthouse Third-party usage audit shows a list of the third-party providers a page uses. This overview can help you better understand the big picture and identify redundant third-party code. The audit is available in the Lighthouse extension and will soon be added to DevTools in Chrome 77.

Third-party provider names generated with Startup generator. Any similarity to actual startups, living or dead, is purely coincidental.

Reduce JavaScript execution time #

The Lighthouse Reduce JavaScript execution time audit highlights scripts that take a long time to parse, compile, or evaluate. Select the Show 3rd-party resources checkbox to discover CPU-intensive third-party scripts.

Avoid enormous network payloads #

The Lighthouse Avoid enormous network payloads audit identifies network requests—including those from third-parties—that may slow down page load time. The audit fails when your network payload exceeds 4,000 KB.

Block network requests in Chrome DevTools #

Chrome DevTools network request blocking allows you to see how your page behaves when a particular script, stylesheet, or other resource isn't available. After you identify third-party scripts that you suspect affect performance, measure how your load time changes by blocking the requests to those scripts.

To enable request blocking:

Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Network tab.
Right-click any request in the Network panel.
Select Block request URL.

A Request blocking tab will appear in the DevTools drawer. You can manage which requests have been blocked there.

To measure the impact of third-party scripts:

Measure how long your page takes to load using the Network panel. To emulate real-world conditions, turn on network throttling and CPU throttling. (On faster connections and desktop hardware, the impact of expensive scripts may not be as representative as it would be on a mobile phone.)
Block the URLs or domains responsible for third-party scripts you believe are an issue.
Reload the page and re-measure how long it takes to load without the blocked third-party scripts.

You should hopefully see a speed improvement, but occasionally blocking third-party scripts might not have the effect you expect. If that's the case, reduce the list of blocked URLs until you isolate the one that's causing slowness.

Note that doing three or more runs of measurement and looking at the median values will likely produce more stable results. As third-party content can occasionally pull in different resources per page load, this approach can give you a more realistic estimate. DevTools now supports multiple recordings in the Performance panel, making this a little easier.

Third-party JavaScript performance

2019-08-13T00:00:00Z

Third-party JavaScript generally refers to scripts embedded in your website that are:

Not authored by you
Served from third-party servers

Sites use these scripts for various purposes, including:

Social sharing buttons
Video player embeds
Chat services
Advertising iframes
Analytics and metrics scripts
A/B testing scripts for experiments
Helper libraries (like date formatting, animation, and functional libraries)

Third-party scripts can provide powerful functionality, but that's not the whole story. They also affect privacy, security, and page behavior⁠—and they can be particularly problematic for performance.

Performance #

Any significant amount of JavaScript can slow down performance. But because third-party JavaScript is usually outside your control, it can bring additional issues.

Network #

Setting up connections takes time, and sending too many requests to multiple servers causes slowdowns. That time is even longer for secure connections, which may involve DNS lookups, redirects, and several round trips to the final server that handles the user's request.

Third-party scripts often add to network overhead with things such as:

Firing additional network requests
Pulling in unoptimized images and videos
Insufficient HTTP caching, which forces frequent fetching of network resources
Insufficient server compression of resources
Multiple instances of frameworks and libraries pulled in by different third-party embeds

Rendering #

The way third-party JavaScript is loaded matters a lot. If it's done synchronously in the critical rendering path it delays parsing of the rest of the document.

If a third party has server issues and fails to deliver a resource, rendering is blocked until the request times out, which can be anywhere from 10 to 80 seconds. You can test and simulate this problem with WebPageTest Single-Point-of-Failure tests.

What to do about it #

Using third-party JavaScript is often unavoidable, but there are things you can do to minimize adverse effects:

When choosing third-party resources, favor those that send the least amount of code while still giving you the functionality you need.
Use performance budgets for third-party content to keep their cost in check.
Don't use the same functionality from two different vendors. You probably don't need two tag managers or two analytics platforms.
Routinely audit and clean out redundant third-party scripts.

To learn how to audit third-party content and load it efficiently for better performance and user experience, check out the other posts in the Optimize your third-party resources section.

Optimize third-party JavaScript

2019-08-08T00:00:00Z

Third-party scripts impact performance, which is why it's important to audit them regularly and use efficient techniques for loading them. This codelab shows you how to optimize the loading of third-party resources. It covers the following techniques:

Deferring script loading
Lazy loading non-critical resources
Preconnecting to required origins

The included sample app features a simple web page with three features coming from third-party sources:

A video embed
A data-visualization library for rendering a line graph
A social media sharing widget

Third-party resources in the sample app.

You'll start by measuring the performance of the app and then apply each technique to improve different aspects of app performance.

Measure performance #

First open the sample app in the fullscreen view:

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

Run a Lighthouse performance audit on the page to establish baseline performance:

Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Lighthouse tab.
Click Mobile.
Select the Performance checkbox. (You can clear the rest of the checkboxes in the Audits section.)
Click Simulated Fast 3G, 4x CPU Slowdown.
Select the Clear Storage checkbox.
Click Run audits.

When you run an audit on your machine, the exact results may vary, but you should notice that the First Contentful Paint (FCP) time is pretty high, and that Lighthouse suggests two opportunities to investigate: Eliminate render-blocking resources and Preconnect to required origins. (Even if the metrics are all in the green, optimizations will still yield improvements.)

Defer third-party JavaScript #

The Eliminate render-blocking resources audit identified that you can save some time by deferring a script coming from d3js.org:

D3.js is a JavaScript library for creating data visualizations. The script.js file in the sample app uses D3 utility functions to create the SVG line chart and append it to the page. The order of operations here matters: script.js has to run after the document is parsed and the D3 library has loaded, which is why it's included right before the closing </body> tag in index.html.

However, the D3 script is included in the page's <head>, which blocks the parsing of the rest document:

Two magic attributes can unblock the parser when added to the script tag:

async ensures that scripts download in the background and execute at the first opportunity after they finish downloading.
defer ensures that scripts download in the background and execute after parsing is completely finished.

Since this chart is not really critical to the overall page and will most likely be below the fold, use defer to make sure there's no parser blocking.

Step 1: Load the script asynchronously with the `defer` attribute #

On line 17 in index.html, add the defer attribute to the <script> element:

<script src="https://d3js.org/d3.v3.min.js" defer></script>

Step 2: Ensure the correct order of operations #

Now that D3 is deferred, script.js will run before D3 is ready, resulting in an error.

Scripts with the defer attribute execute in the order in which they were specified. To ensure script.js gets executed after D3 is ready, add defer to it and move it up to the <head> of the document, right after the D3 <script> element. Now it no longer blocks the parser, and the download starts sooner.

<script src="https://d3js.org/d3.v3.min.js" defer></script>
<script src="./script.js" defer></script>

Lazy-load third-party resources #

All resources that are below the fold are good candidates for lazy loading.

The sample app has a YouTube video embedded in an iframe. To check out how many requests the page makes and which come from the embedded YouTube iframe:

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.
Select the Disable cache checkbox.
Select Fast 3G in the Throttling dropdown menu.
Reload the page.

The Network panel reveals that the page made a total of 28 requests and transferred almost 1 MB of compressed resources.

To identify the requests that the YouTube iframe made, look for the video ID 6lfaiXM6waw in the Initiator column. To group together all the requests by domain:

In the Network panel, right-click a column title.
In the dropdown menu, select the Domains column.
To sort the requests by domain, click the Domains column title.

The new sorting reveals that there are additional requests to Google domains. In total, the YouTube iframe makes 14 requests for scripts, stylesheets, images, and fonts. But unless users actually scroll down to play the video, they don't really need all those assets.

By waiting to lazy-load the video until a user scrolls down to that section of the page, you cut the number of requests the page initially makes. This approach saves users' data and speeds up the initial load.

One way to implement lazy loading is by using the Intersection Observer, a browser API that notifies you when an element enters or exits the browser's viewport.

Step 1: Prevent video from loading initially #

To lazy-load the video iframe, you must first prevent it from loading in the usual way. Do that by replacing the src attribute with the data-src attribute to specify the video URL:

<iframe width="560" height="315" data-src="https://www.youtube.com/embed/lS9D6w1GzGY" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

data-src is a data attribute, which allows you to store extra information on standard HTML elements. A data attribute can be named anything, as long as it starts with "data-".

An iframe without a src simply won't load.

Step 2: Use Intersection Observer to lazy-load the video #

To load the video when a user scrolls to it you need to know when that happens. That's where the Intersection Observer API steps in. The Intersection Observer API lets you register a callback function that's executed whenever an element you want to track enters or exits the viewport.

To get started, create a new file and name it lazy-load.js:

Click New File and give it a name.
Click Add This File.

Add the script tag to your document head:

<script src="/lazy-load.js" defer></script>

In lazy-load.js, create a new IntersectionObserver and pass it a callback function to run:

// create a new Intersection Observer
let observer = new IntersectionObserver(callback);

Now give observer a target element to watch (the video iframe in this case) by passing it as an argument in the observe method:

// the element that you want to watch
const element = document.querySelector('iframe');

// register the element with the observe method
observer.observe(element);

callback receives a list of IntersectionObserverEntry objects and the IntersectionObserver object itself. Each entry contains a target element and properties that describe its dimensions, position, the time it entered the viewport, and more. One of the properties of IntersectionObserverEntry is isIntersecting—a boolean value that equals true when the element enters the viewport.

In this example, the target is the iframe. isIntersecting equals true when target enters the viewport. To see this in action, replace callback with the following function:

let observer = new IntersectionObserver(callback);
let observer = new IntersectionObserver(function(entries, observer) {
    entries.forEach(entry => {
      console.log(entry.target);
      console.log(entry.isIntersecting);
    });
  });

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 Console tab.

Try scrolling up and down. You should see the value of isIntersecting change and the target element logged to the console.

To load the video when the user scrolls to its position, use isIntersecting as a condition to run a loadElement function, which gets the value from the iframe element's data-src and sets it as the iframe element's src attribute. That replacement triggers the loading of the video. Then, once the video is loaded, call the unobserve method on the observer to stop watching the target element:

let observer = new IntersectionObserver(function (entries, observer) {
  entries.forEach(entry => {
    console.log(entry.target);
    console.log(entry.isIntersecting);
  });
});
    if (entry.isIntersecting) {
      // do this when the element enters the viewport
      loadElement(entry.target);
      // stop watching
      observer.unobserve(entry.target);
    }
  });
});

function loadElement(element) {
  const src = element.getAttribute('data-src');
  element.src = src;
}

Step 3: Reevaluate performance #

To see how the size and number of resources changed, open the DevTools Network panel and reload the page again. The Network panel reveals that the page made 14 requests and only 260 KB. That's a meaningful improvement!

Now scroll down the page and keep an eye on the Network panel. When you get to the video, you should see the page trigger additional requests.

Preconnect to required origins #

You've deferred non-critical JavaScript and lazy-loaded the YouTube requests, so now it's time to optimize the remaining third-party content.

Adding the rel=preconnect attribute to a link tells the browser to establish a connection to a domain before the request for that resource is made. This attribute is best used on origins that provide resources you are certain the page needs.

The Lighthouse audit you ran in the first step suggested in Preconnect to required origins that you can save around 400 ms by establishing early connections to staticxx.facebook.com and youtube.com:

Since the YouTube video is now lazy-loaded, that leaves only staticxx.facebook.com, the source of the social media sharing widget. Establishing an early connection to this domain is as simple as adding a <link> tag to the document's <head>:

  <link rel="preconnect" href="https://staticxx.facebook.com">

Reevaluate performance #

Here's the state of the page after optimization. Follow the steps from the Measure performance section of the codelab to run another Lighthouse audit.

Establish network connections early to improve perceived page speed

2019-07-30T00:00:00Z

Before the browser can request a resource from a server, it must establish a connection. Establishing a secure connection involves three steps:

Look up the domain name and resolve it to an IP address.
Set up a connection to the server.
Encrypt the connection for security.

In each of these steps the browser sends a piece of data to a server, and the server sends back a response. That journey, from origin to destination and back, is called a round trip.

Depending on network conditions, a single round trip might take a significant amount of time. The connection setup process might involve up to three round trips—and more in unoptimized cases.

Taking care of all that ahead of time makes applications feel much faster. This post explains how to achieve that with two resource hints: <link rel=preconnect> and <link rel=dns-prefetch>.

Establish early connections with `rel=preconnect` #

Modern browsers try their best to anticipate what connections a page will need, but they cannot reliably predict them all. The good news is that you can give them a (resource 😉) hint.

Adding rel=preconnect to a <link> informs the browser that your page intends to establish a connection to another domain, and that you'd like the process to start as soon as possible. Resources will load more quickly because the setup process has already been completed by the time the browser requests them.

Resource hints get their name because they are not mandatory instructions. They provide the information about what you'd like to happen, but it's ultimately up to the browser to decide whether to execute them. Setting up and keeping a connection open is a lot of work, so the browser might choose to ignore resource hints or execute them partially depending on the situation.

Informing the browser of your intention is as simple as adding a <link> tag to your page:

<link rel="preconnect" href="https://example.com">

You can speed up the load time by 100–500 ms by establishing early connections to important third-party origins. These numbers might seem small, but they make a difference in how users perceive web page performance.

Use-cases for `rel=preconnect` #

Knowing where from, but not what you're fetching #

Due to versioned dependencies, you sometimes end up in a situation where you know you'll be requesting a resource from a particular CDN, but not the exact path for it.

An example of a versioned URL.

The other common case is loading images from an image CDN, where the exact path for an image depends on media queries or runtime feature checks on the user's browser.

An example of an image CDN URL.

In these situations, if the resource you'll be fetching is important, you want to save as much time as possible by pre-connecting to the server. The browser won't download the file until your page requests it, but at least it can handle the connection aspects ahead of time, saving the user from waiting for several round trips.

Streaming media #

Another example where you may want to save some time in the connection phase, but not necessarily start retrieving content right away, is when streaming media from a different origin.

Depending on how your page handles the streamed content, you may want to wait until your scripts have loaded and are ready to process the stream. Pre-connecting helps you cut the waiting time to a single round trip once you're ready to start fetching.

How to implement `rel=preconnect` #

One way of initiating a preconnect is adding a <link> tag to the <head> of the document.

<head>
    <link rel="preconnect" href="https://example.com">
</head>

Preconnecting is only effective for domains other than the origin domain, so you shouldn't use it for your site.

You can also initiate a preconnect via the Link HTTP header:

Link: <https://example.com/>; rel=preconnect

Some types of resources, such as fonts, are loaded in anonymous mode. For those you must set the crossorigin attribute with the preconnect hint:

<link rel="preconnect" href="https://example.com/ComicSans" crossorigin>

If you omit the crossorigin attribute, the browser only performs the DNS lookup.

Resolve domain name early with `rel=dns-prefetch` #

You remember sites by their names, but servers remember them by IP addresses. This is why the domain name system (DNS) exists. The browser uses DNS to convert the site name to an IP address. This process—domain name resolution— is the first step in establishing a connection.

If a page needs to make connections to many third-party domains, preconnecting all of them is counterproductive. The preconnect hint is best used for only the most critical connections. For all the rest, use <link rel=dns-prefetch> to save time on the first step, the DNS lookup, which usually takes around 20–120 ms.

DNS resolution is initiated similarly to preconnect: by adding a <link> tag to the <head> of the document.

<link rel="dns-prefetch" href="http://example.com">

Browser support for dns-prefetch is slightly different from preconnect support, so dns-prefetch can serve as a fallback for browsers that don't support preconnect.

<link rel="preconnect" href="http://example.com">
<link rel="dns-prefetch" href="http://example.com">

To safely implement the fallback technique, use separate link tags.

Don't

<link rel="preconnect dns-prefetch" href="http://example.com">

Implementing dns-prefetch fallback in the same <link> tag causes a bug in Safari where preconnect gets cancelled.

Effect on Largest Contentful Paint (LCP) #

Using dns-prefetch and preconnect allows sites to reduce the amount of time it takes to connect to another origin. The ultimate aim is that the time to load a resource from another origin should be minimized as much as possible.

Where Largest Contentful Paint (LCP) is concerned, it is better that resources are immediately discoverable, since LCP candidates are crucial parts of the user experience. A fetchpriority value of "high" on LCP resources can further improve this by signaling the importance of this asset to the browser so it can fetch it early.

Where it is not possible to make LCP assets immediately discoverable, a preload link—also with the fetchpriority value of "high"—still allows the browser to load the resource as soon as possible.

If neither of these options are available—because the exact resource will not be known until later in the page load—you can use preconnect on cross-origin resources to reduce the impact of the late discovery of the resource as much as possible.

Additionally, preconnect is less expensive than preload in terms of bandwidth usage, but still not without its risks. As is the case with excessive preload hints, excessive preconnect hints still consume bandwidth where TLS certificates are concerned. Be careful not to preconnect to too many origins, as this may cause bandwidth contention.

Conclusion #

These two resource hints are helpful for improving page speed when you know you'll download something from a third-party domain soon, but you don't know the exact URL for the resource. Examples include CDNs that distribute JavaScript libraries, images or fonts. Be mindful of constraints, use preconnect only for the most important resources, rely on dns-prefetch for the rest, and always measure the impact in the real-world.

Adapt video to image serving based on network quality

2019-07-08T00:00:00Z

In this codelab, you'll learn how to adapt your content based on the network quality. This page's background video will load only when users are on a fast network. On slower networks, an image will load instead.

The Network Information API enables you to access information about the user's connection quality. You will use its effectiveType property to decide when to serve a video and when to serve an image. effectiveType can be 'slow-2g', '2g', '3g', or '4g'.

Browser support

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

Source

Step 1: Check connection type #

The index.html file contains a <video> tag to display the background video (line 22). The code in script.js loads the video by setting the video tag's src attribute. (The video loading code is described in more detail in Step 2.)

To load the video conditionally, first check if the Network Information API is available; if it is, check the connection type.

In script.js, add an if statement that tests whether the navigator.connection object exists and whether it has the effectiveType property.
Add an if statement to check the effectiveType of the network.

if (navigator.connection && !!navigator.connection.effectiveType) {
  if (navigator.connection.effectiveType === '4g') {
    // Only load video on the fastest connections.
  } else {
    // In any other case load the image.
  }
}

Wrap the existing video loading code in an else statement, so that video will still load in browsers that don't support the Network Information API.

if (navigator.connection && !!navigator.connection.effectiveType) {
  if (navigator.connection.effectiveType === '4g') {
    // video loading code
  } else {
    // image loading code
  }
} else {
  const video = document.getElementById('coverVideo');
  const videoSource = video.getAttribute('data-src');
  video.setAttribute('src', videoSource);

  video.setAttribute('style', 'height: 100%; width: 100%; display:inline');
}

Step 2: Load video #

If the effectiveType is '4g', use the video loading code from the beginning of the codelab.

if (navigator.connection.effectiveType === '4g') {
  const video = document.getElementById('coverVideo');
  const videoSource = video.getAttribute('data-src');
  video.setAttribute('src', videoSource);
  video.setAttribute('style', 'height: 100%; width: 100%; display:inline');
} else {
  // image loading code
}

Here's how the video loading code works: the <video> tag doesn't download or display anything at first because its src attribute is not set. The video URL to load is specified using the data-src attribute.

<video id="coverVideo" autoplay loop muted data-src="https://cdn.glitch.com/b6491350-b058-4eb6-aa6c-55c93122073e%2FMatrix%2C%20Console%2C%20Hacking%2C%20Code.mp4?1551464245607"></video>

Data attributes allow you to store extra information on standard HTML elements. A data element can be named anything, as long as it starts with "data-".

To actually display the video on the page, you need to get the value from data-src and set it as the video element's src attribute.

First, get the DOM element that contains the asset:

const video = document.getElementById('coverVideo');

Then get the resource location from the data-src attribute:

const videoSource = video.getAttribute('data-src');

And finally set that as the src attribute of the video element:

video.setAttribute('src', videoSource);

The last line takes care of CSS positioning:

video.setAttribute('style', 'height: 100%; width: 100%; display:inline');

Step 3: Load image #

To conditionally load an image on slower networks, use the same strategy as for the video.

Add an image element to index.html (right after the video element), and use the data-src attribute instead of the src attribute.

<img id="coverImage" data-src="https://cdn.glitch.com/36529535-5976-40f8-979b-40c898b86bd0%2F36529535-5976-40f8-979b-40c898b86bd0_1_Sn80dgiwpMjBVrqjfiDbnA.jpg?1553003835358" />

In script.js, add code to set the image's src attribute depending on the effectiveType of the network.

if (navigator.connection.effectiveType === '4g') {
  const video = document.getElementById('coverVideo');
  const videoSource = video.getAttribute('data-src');
  video.setAttribute('src', videoSource);

  video.setAttribute('style', 'height: 100%; width: 100%; display:inline');
} else {
  const image = document.getElementById('coverImage');
  const imageSource = image.getAttribute('data-src');
  image.setAttribute('src', imageSource);

  image.setAttribute('style', 'height: 100%; width: 100%; display:inline');
}

Try it out #

To test it yourself:

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.
Click the Throttling drop-down, which is set to No throttling by default. Select Fast 3G.

Now reload the page with Fast 3G still enabled. The app loads an image in the background instead of the video:

Extra Credit: Respond to changes #

Remember how this API has an onchange event listener? You can use it for many things: dynamically adapting content such as video quality; restarting deferred data transfers when a change to a high-bandwidth network type is detected; or notifying users when the network quality changes.

Here's a simple example of how to use this listener. Add it to script.js. This code will call the displayNetworkInfo function whenever the network information changes.

navigator.connection.addEventListener('change', displayNetworkInfo);

There's already an empty <h2> element on the index.html page. Now define the displayNetworkInfo function so that it displays the network information in the <h2> element and invoke the function.

function displayNetworkInfo() {
  document.getElementById('connection').innerHTML = navigator.connection.effectiveType;
}

displayNetworkInfo();

Here's the final state of the app on Glitch.

To test it again:

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.
Click the Throttling drop-down, which is set to No throttling by default. Select Fast 3G.
Reload the app.

The app will update the network information to 3g:

Cumulative Layout Shift (CLS)

2019-06-11T00:00:00Z

Browser support

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

Source

Have you ever been reading an article online when something suddenly changes on the page? Without warning, the text moves, and you've lost your place. Or even worse: you're about to tap a link or a button, but in the instant before your finger lands—BOOM—the link moves, and you end up clicking something else!

Most of the time these kinds of experiences are just annoying, but in some cases, they can cause real damage.

A screencast illustrating how layout instability can negatively affect users.

Unexpected movement of page content usually happens because resources are loaded asynchronously or DOM elements get dynamically added to the page above existing content. The culprit might be an image or video with unknown dimensions, a font that renders larger or smaller than its fallback, or a third-party ad or widget that dynamically resizes itself.

What makes this issue even more problematic is that how a site functions in development is often quite different from how users experience it. Personalized or third-party content often doesn't behave the same in development as it does in production, test images are often already in the developer's browser cache, and API calls that run locally are often so fast that the delay isn't noticeable.

The Cumulative Layout Shift (CLS) metric helps you address this problem by measuring how often it's occurring for real users.

What is CLS? #

CLS is a measure of the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifespan of a page.

A layout shift occurs any time a visible element changes its position from one rendered frame to the next. (See below for details on how individual layout shift scores are calculated.)

A burst of layout shifts, known as a session window, is when one or more individual layout shifts occur in rapid succession with less than 1-second in between each shift and a maximum of 5 seconds for the total window duration.

The largest burst is the session window with the maximum cumulative score of all layout shifts within that window.

Example of session windows. Blue bars represent the scores of each individual layout shift.

What is a good CLS score? #

To provide a good user experience, sites should strive to have a CLS score of 0.1 or less. To ensure you're hitting this target for most of your users, a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices.

Layout shifts in detail #

Layout shifts are defined by the Layout Instability API, which reports layout-shift entries any time an element that is visible within the viewport changes its start position (for example, its top and left position in the default writing mode) between two frames. Such elements are considered unstable elements.

Note that layout shifts only occur when existing elements change their start position. If a new element is added to the DOM or an existing element changes size, it doesn't count as a layout shift—as long as the change doesn't cause other visible elements to change their start position.

Layout shift score #

To calculate the layout shift score, the browser looks at the viewport size and the movement of unstable elements in the viewport between two rendered frames. The layout shift score is a product of two measures of that movement: the impact fraction and the distance fraction (both defined below).

layout shift score = impact fraction * distance fraction

Impact fraction #

The impact fraction measures how unstable elements impact the viewport area between two frames.

The union of the visible areas of all unstable elements for the previous frame and the current frame—as a fraction of the total area of the viewport—is the impact fraction for the current frame.

In the image above there's an element that takes up half of the viewport in one frame. Then, in the next frame, the element shifts down by 25% of the viewport height. The red, dotted rectangle indicates the union of the element's visible area in both frames, which, in this case, is 75% of the total viewport, so its impact fraction is 0.75.

Distance fraction #

The other part of the layout shift score equation measures the distance that unstable elements have moved, relative to the viewport. The distance fraction is the greatest distance any unstable element has moved in the frame (either horizontally or vertically) divided by the viewport's largest dimension (width or height, whichever is greater).

In the example above, the largest viewport dimension is the height, and the unstable element has moved by 25% of the viewport height, which makes the distance fraction 0.25.

So, in this example the impact fraction is 0.75 and the distance fraction is 0.25, so the layout shift score is 0.75 * 0.25 = 0.1875.

The next example illustrates how adding content to an existing element affects the layout shift score:

The "Click Me!" button is appended to the bottom of the gray box with black text, which pushes the green box with white text down (and partially out of the viewport).

In this example, the gray box changes size, but its start position does not change so it's not an unstable element.

The "Click Me!" button was not previously in the DOM, so its start position doesn't change either.

The start position of the green box, however, does change, but since it's been moved partially out of the viewport, the invisible area is not considered when calculating the impact fraction. The union of the visible areas for the green box in both frames (illustrated by the red, dotted rectangle) is the same as the area of the green box in the first frame—50% of the viewport. The impact fraction is 0.5.

The distance fraction is illustrated with the purple arrow. The green box has moved down by about 14% of the viewport so the distance fraction is 0.14.

The layout shift score is 0.5 x 0.14 = 0.07.

This last example illustrates multiple unstable elements:

In the first frame above there are four results of an API request for animals, sorted in alphabetical order. In the second frame, more results are added to the sorted list.

The first item in the list ("Cat") does not change its start position between frames, so it's stable. Similarly, the new items added to the list were not previously in the DOM, so their start positions don't change either. But the items labelled "Dog", "Horse", and "Zebra" all shift their start positions, making them unstable elements.

Again, the red, dotted rectangles represent the union of these three unstable elements' before and after areas, which in this case is around 60% of the viewport's area (impact fraction of 0.60).

The arrows represent the distances that unstable elements have moved from their starting positions. The "Zebra" element, represented by the blue arrow, has moved the most, by about 30% of the viewport height. That makes the distance fraction in this example 0.3.

The layout shift score is 0.60 x 0.3 = 0.18.

Expected vs. unexpected layout shifts #

Not all layout shifts are bad. In fact, many dynamic web applications frequently change the start position of elements on the page.

User-initiated layout shifts #

A layout shift is only bad if the user isn't expecting it. On the other hand, layout shifts that occur in response to user interactions (clicking a link, pressing a button, typing in a search box and similar) are generally fine, as long as the shift occurs close enough to the interaction that the relationship is clear to the user.

For example, if a user interaction triggers a network request that may take a while to complete, it's best to create some space right away and show a loading indicator to avoid an unpleasant layout shift when the request completes. If the user doesn't realize something is loading, or doesn't have a sense of when the resource will be ready, they may try to click something else while waiting—something that could move out from under them.

Layout shifts that occur within 500 milliseconds of user input will have the hadRecentInput flag set, so they can be excluded from calculations.

Animations and transitions #

Animations and transitions, when done well, are a great way to update content on the page without surprising the user. Content that shifts abruptly and unexpectedly on the page almost always creates a bad user experience. But content that moves gradually and naturally from one position to the next can often help the user better understand what's going on, and guide them between state changes.

Be sure to respect prefers-reduced-motion browser settings, as some site visitors can experience ill effects or attention issues from animation.

CSS transform property allows you to animate elements without triggering layout shifts:

Instead of changing the height and width properties, use transform: scale().
To move elements around, avoid changing the top, right, bottom, or left properties and use transform: translate() instead.

How to measure CLS #

CLS can be measured in the lab or in the field, and it's available in the following tools:

Field tools #

Lab tools #

Measure layout shifts in JavaScript #

To measure layout shifts in JavaScript, you use the Layout Instability API.

The following example shows how to create a PerformanceObserver to log layout-shift entries to the console:

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('Layout shift:', entry);
  }
}).observe({type: 'layout-shift', buffered: true});

Measure CLS in JavaScript #

To measure CLS in JavaScript, you need to group these unexpected layout-shift entries into sessions, and calculate the maximum session value. You can refer to the web vitals JavaScript library source code which contains a reference implementation on how CLS is calculated.

In most cases, the current CLS value at the time the page is being unloaded is the final CLS value for that page, but there are a few important exceptions as noted in the next section. The web vitals JavaScript library accounts for these as much as possible, within the limitations of the Web APIs.

Differences between the metric and the API #

If a page is loaded in the background, or if it's backgrounded prior to the browser painting any content, then it should not report any CLS value.
If a page is restored from the back/forward cache, its CLS value should be reset to zero since users experience this as a distinct page visit.
The API does not report layout-shift entries for shifts that occur within iframes but the metric does as they are part of the user experience of the page. This can show as a difference between CrUX and RUM. To properly measure CLS you should consider them. Sub-frames can use the API to report their layout-shift entries to the parent frame for aggregation.

In addition to these exceptions, CLS has some added complexity due to the fact that it measures the entire lifespan of a page:

Users might keep a tab open for a very long time—days, weeks, months. In fact, a user might never close a tab.
On mobile operating systems, browsers typically do not run page unload callbacks for background tabs, making it difficult to report the "final" value.

To handle such cases, CLS should be reported any time a page is background—in addition to any time it's unloaded (the visibilitychange event covers both of these scenarios). And analytics systems receiving this data will then need to calculate the final CLS value on the backend.

Rather than memorizing and grappling with all of these cases yourself, developers can use the web-vitals JavaScript library to measure CLS, which accounts for everything mentioned above:

import {onCLS} from 'web-vitals';

// Measure and log CLS in all situations
// where it needs to be reported.
onCLS(console.log);

How to improve CLS #

A full guide on optimizing CLS is available to guide you through the process of identifying layout shifts in the field and using lab data to drill down and optimize them.

Additional resources #

Google Publisher Tag's guidance on minimizing layout shift
Understanding Cumulative Layout Shift by Annie Sullivan and Steve Kobes at #PerfMatters (2020)

CHANGELOG #

Occasionally, bugs are discovered in the APIs used to measure metrics, and sometimes in the definitions of the metrics themselves. As a result, changes must sometimes be made, and these changes can show up as improvements or regressions in your internal reports and dashboards.

To help you manage this, all changes to either the implementation or definition of these metrics will be surfaced in this CHANGELOG.

If you have feedback for these metrics, you can provide it in the web-vitals-feedback Google group.

Extract and inline critical CSS with Critical

2019-05-29T00:00:00Z

Whether you use a UI library or handcraft your styles, shipping a significant amount of CSS delays rendering because the browser must download and parse CSS files before it can show the page.

This responsive ice cream gallery is built with Bootstrap. UI libraries like Bootstrap speed up development, but that often comes at the expense of bloated and unnecessary CSS, which can slow down your load times. Bootstrap 4 is 187 KB, while Semantic UI, another UI library, is a whopping 730 KB uncompressed. Even when minified and gzipped, Bootstrap still weighs around 20 KB, well over the 14 KB threshold for the first roundtrip.

Critical is a tool that extracts, minifies and inlines above-the-fold CSS. This allows above-the-fold content to be rendered as soon as possible, even if CSS for other parts of the page has not yet loaded. In this codelab, you'll learn how to use Critical's npm module.

Measure #

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

To run a Lighthouse audit on this site:

Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Lighthouse tab.
Click Mobile.
Select the Performance checkbox.
Clear the rest of the checkboxes in the Audits section.
Click Simulated Fast 3G, 4x CPU Slowdown.
Select the Clear Storage checkbox. With this option selected, Lighthouse will not load resources from the cache, which simulates how first-time visitors would experience the page.
Click Run Audits.

When you run an audit on your machine, the exact results may vary, but in the filmstrip view, you'll notice the app has a blank screen for quite a while before finally rendering the content. This is why First Contentful Paint (FCP) is high and why overall performance score is not great.

Lighthouse is here to help you fix performance issues, so look for solutions in the Opportunities section. Eliminate render-blocking resources is listed as an opportunity and that's where Critical shines!

Optimize #

Click Remix to Edit to make the project editable.

To speed things up, Critical is already installed and an empty configuration file is included in the codelab.

In the configuration file critical.js, add a reference to Critical and then invoke the critical.generate() function. This function accepts an object containing the configuration.

const critical = require('critical');

critical.generate({
	// configuration
},(err, output) => {
  if (err) {
    console.error(err);
  } else if (output) {
    console.log('Generated critical CSS');
  }
});

Error handling isn't mandatory, but it's an easy way to gauge the operation success in the console.

Configure Critical #

The table below contains some useful Critical options. You can check out all of the available options on GitHub.

Option	Type	Explanation
`base`	string	The base directory for your files.
`src`	string	HTML source file.
`dest`	string	The target for the output file. If CSS is inlined the output file is HTML. If not, the output is a CSS file.
`width`, `height`	numbers	Viewport width and height in pixels.
`dimensions`	array	Contains objects with width and height properties. These objects represent the viewports you want to target with above-the-fold CSS. If you have media queries in your CSS, this allows you to generate critical CSS that covers multiple viewport sizes.
`inline`	boolean	When set to true, the generated critical CSS is inlined in the of the HTML source file.
`minify`	boolean	When set to true, Critical minifies the generated critical CSS. Can be omitted when extracting critical CSS for multiple resolutions because Critical automatically minifies it to avoid duplicate rule inclusion.

Below is a configuration example for extracting critical CSS for multiple resolutions. Add it to critical.js or play around and tweak the options.

critical.generate({
  base: 'public/',
  src: './index.html',
  dest: './index.html',
  inline: true,
  dimensions: [
    {
      height: 500,
      width: 300,
    },
    {
      height: 720,
      width: 1280,
    },
  ]
}, (err, output) => {
  if (err) {
    console.error(err);
  } else if (output) {
    console.log('Generated critical CSS');
  }
});

In this example, index.html is both the source file and the destination file because the inline option is set to true. Critical first reads the HTML source file, extracts critical CSS and then overwrites index.html with critical CSS inlined in the <head>.

dimensions array has two viewport sizes specified: 300 x 500 for extra small screens and 1280 x 720 for standard laptop screens.

minify option is omitted because Critical automatically minifies the extracted CSS when there are multiple viewport sizes specified.

Run Critical #

Add Critical to your scripts in package.json:

scripts: {
  "start": "node server.js",
  "critical": "node critical.js"
}

Click Terminal (note: if the Terminal button does not show you may need to use the Fullscreen option).

To generate critical CSS, in the console, run:

npm run critical
refresh

Success message in the console

Now in the <head> tag of index.html, generated critical CSS is inlined between <style> tags, followed by a script that loads the rest of the CSS asynchronously.

Inlined critical CSS

Measure again #

Follow the steps from the beginning of the codelab to run Lighthouse performance audit again. The results you get will look similar to this:

Extract critical CSS

2019-05-29T00:00:00Z

The browser must download and parse CSS files before it can show the page, which makes CSS a render-blocking resource. If CSS files are big, or network conditions are poor, requests for CSS files can significantly increase the time it takes for a web page to render.

Inlining extracted styles in the <head> of the HTML document eliminates the need to make an additional request to fetch these styles. The remainder of the CSS can be loaded asynchronously.

Inlined critical CSS

Improving render times can make a huge difference in perceived performance, especially under poor network conditions. On mobile networks, high latency is an issue regardless of bandwidth.

Comparison of loading a page with render-blocking CSS (top) and the same page with inlined critical CSS (bottom) on a 3G connection

If you have poor First Contentful Paint (FCP) and see "Eliminate render-blocking resource" opportunity in Lighthouse audits it's a good idea to give critical CSS a go.

To minimize the number of roundtrips to first render, aim to keep above-the-fold content under 14 KB (compressed).

The performance impact you can achieve with this technique depends on the type of your website. Generally speaking, the more CSS a site has, the greater the possible impact of inlined CSS.

Overview of tools #

There are a number of great tools that can automatically determine the critical CSS for a page. This is good news because doing this manually would be a tedious process. It requires analysis of the entire DOM to determine the styles that are applied to each element in the viewport.

Critical #

Critical extracts, minifies and inlines above-the-fold CSS and is available as npm module. It can be used with Gulp (directly) or with Grunt (as a plugin) and there's a webpack plugin too.

It's a simple tool that takes a lot of thinking out of the process. You don't even have to specify the stylesheets, Critical automatically detects them. It also supports extracting critical CSS for multiple screen resolutions.

criticalCSS #

CriticalCSS is another npm module that extracts above-the-fold CSS. It is also available as a CLI.

It doesn't have options to inline and minify critical CSS, but it does let you force-include rules that don't actually belong in critical CSS and gives you more granular control over including @font-face declarations.

Penthouse #

Penthouse is a good choice if your site or app has a large number of styles or styles which are being dynamically injected into the DOM (common in Angular apps). It uses Puppeteer under the hood and even features an online hosted version too.

Penthouse doesn't detect stylesheets automatically, you have to specify the HTML and CSS files that you want to generate critical CSS for. The upside is that it's good at running many jobs in parallel.

Adaptive serving based on network quality

2019-05-06T00:00:00Z

Loading a website can be a very different experience depending on the network conditions. Everything is usually smooth when you are on a fast network, but when you're on the go with a limited data plan and spotty connection, or stuck with a laptop on slow coffee-shop Wi-Fi, it's a different story.

One way to deal with this is by adapting which assets you're serving to users based on the quality of their connection. This is now possible with the Network Information API which enables web applications to access information about the user's network.

Browser support

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

Source

Usage #

There are many ways you can use this network information to improve the user experience:

Switch between serving high-definition and low-definition content based on the user's network.
Decide whether to preload resources.
Defer uploads and downloads when users are on a slow connection.
Enable offline mode if the network quality is not good enough to load the app and use the features.
Warn users that doing something (for example, watching video) over cellular could cost them money.
Use it in your analytics to gather data on your users' network quality.

Many applications are already doing something similar. For example, YouTube, Netflix and most other video (or video calling) services automatically adjust the resolution during streaming. When Gmail is loading, it provides users with a link to "load basic HTML (for slow connections)".

How it works #

The navigator.connection object contains information about a client's connection. Its properties are explained in the table bellow.

Property	Explanation
`downlink`	The bandwidth estimate in megabits per second.
`effectiveType`	The effective type of the connection, with possible values `'slow-2g'`, `'2g'`, `'3g'`, or `'4g'` (covers 4g and higher). Determined based on the combination of round-trip time and downlink speed. For example, fast downlink combined with high latency will have lower effectiveType due to latency.
`onchange`	An event handler that fires when connection information changes.
`rtt`	The estimated round-trip latency of the connection in milliseconds.
`saveData`	A boolean that defines whether the user has requested a reduced data usage mode.

Here's what this looks like when you run it in the browser's console:

The effectiveType values are also available via Client Hints and allow you to communicate the browser's connection type to servers.

The onchange event listener enables you to dynamically adapt to changes in network quality. If you deferred uploads or downloads because of poor network conditions, you can rely on the event listener to restart the transfer when it detects better network conditions. You can also use it to notify users when the network quality changes. For example, if they lost their Wi-Fi signal and were dropped to a cellular network this can prevent accidental data transfers (and charges 💸).

Use the onchange event listener as you would any other event listener:

navigator.connection.addEventListener('change', doSomethingOnChange);

Conclusion #

The potential benefits of the Network Information API are big, especially for users on slow networks and applications that require a lot of bandwidth. Best of all, it can be used as a progressive enhancement technique.

Incorporate performance budgets into your build process

2019-02-01T00:00:00Z

Once you've defined a performance budget, it's time to set up the build process to keep track of it. There are a number of tools that let you define thresholds for chosen performance metrics and warn you if you go over budget. Find out how to choose one that best fits your needs and current setup. 🕵️‍♀️

Lighthouse performance budgets #

Lighthouse is an auditing tool that tests sites in a few key areas—performance, accessibility, best practices and how well your site performs as a progressive web application.

The command line version of Lighthouse (v5+) supports setting performance budgets based on:

resource size
resource count

You can set budgets for any of the following resource types:

document
font
image
media
other
script
stylesheet
third-party
total

Budgets are set in a JSON file and after defining them the new "Over Budget" column tells you whether you're exceeding any limits.

"Budgets" section in Lighthouse report

Webpack performance hints #

Webpack is a powerful build tool for optimizing how your code is delivered to the users. It also supports setting performance budgets based on asset size.

Turn on performance hints in webpack.config.js to get command line warnings or errors when your bundle size grows over the limit. It's a great way to stay mindful about asset sizes throughout the development.

After the build step, webpack outputs a color-coded list of assets and their sizes. Anything over budget is highlighted in yellow.

The highlighted bundle.js is bigger than your budget

The default limit for both assets and entry-points is 250 KB. You can set your own targets in the configuration file.

Webpack bundle size warning ⚠️

The budgets are compared against uncompressed asset sizes. Uncompressed JavaScript size is related to the execution time and big files can take a long time to execute, especially on mobile devices.

Bonus feature: webpack won’t only warn you, it will give you a recommendation on how to downsize your bundles. 💁

Bundlesize #

Bundlesize is a simple npm package that tests asset size against a threshold you've set. It can run locally and integrate with your CI.

Bundlesize CLI #

Run bundlesize CLI by specifying a threshold and the file that you want to test.

bundlesize -f "dist/bundle.js" -s 170kB

Bundlesize outputs color-coded test results in one line.

Failing bundlesize CLI test ❌

Passing bundlesize CLI test ✔️

Bundlesize for CI #

You'll get the most value out of bundlesize if you integrate it with a CI to automatically enforce size limits on pull requests. If bundlesize test fails, that pull request is not merged. It works for pull requests on GitHub with Travis CI, CircleCI, Wercker, and Drone.

Bundlesize check status on GitHub

You may have a fast app today, but adding new code can often change this. Checking pull requests with bundlesize will help you avoid performance regressions. Bootstrap, Tinder, Trivago and many others use it to keep their budgets in check.

With bundlesize, it's possible to set thresholds for each file separately. This is especially useful if you are splitting a bundle in your application.

By default, it tests gzipped asset sizes. You can use the compression option to switch to brotli compression or turn it off completely.

Lighthouse Bot #

Lighthouse Bot integrates with Travis CI and enforces budgets based on any of the five Lighthouse audit categories. For example, a budget of 100 for your Lighthouse performance score. It's sometimes simpler to keep an eye on a single number than individual asset budgets and Lighthouse scores take many things into account.

Lighthouse scores 💯

Lighthouse Bot runs an audit after you deploy a site to staging server. In .travis.yml set budgets for particular Lighthouse categories with --perf, --a11y, --bp, --seo or --pwa options. Aim to stay in the green zone with scores of at least 90.

after_success:
  - ./deploy.sh # Deploy the PR changes to staging server
  - npm run lh -- --perf=96 https://staging.example.com # Run Lighthouse test

If the scores for a pull request on GitHub fall below the threshold you've set, Lighthouse Bot can prevent pull request from being merged. ⛔

Lighthouse Bot check status on GitHub

Lighthouse Bot then comments on your pull request with updated scores. This is a neat feature which encourages conversation about performance as code changes are happening.

Lighthouse reporting scores on pull request 💬

If you find your pull request blocked by a poor Lighthouse score, run an audit with Lighthouse CLI or in Dev Tools. It generates a report with details about bottlenecks and hints for simple optimizations.

Summary #

Tool	CLI	CI	Summary
Lighthouse	✔️	❌	Budgets for different types of resources based on their size or count.
webpack	✔️	❌	Budgets based on sizes of assets generated by webpack. Checks uncompressed sizes.
bundlesize	✔️	✔️	Budgets based on sizes of specific resources. Checks compressed or uncompressed sizes.
Lighthouse Bot	❌	✔️	Budgets based on Lighthouse scores.

Using bundlesize with Travis CI

2019-02-01T00:00:00Z

Using bundlesize with Travis CI lets you define performance budgets with minimal setup and enforce them as part of your development workflow. Travis CI is a service that runs tests for your app in the cloud every time you push code to GitHub. You can configure your repository so that it won't allow merging pull-requests unless the bundlesize tests have passed.

Bundlesize's GitHub checks include a size comparison to the main branch and a warning in case of a big jump in size.

To see it in action, here's an app bundled with webpack that lets you vote for your favorite kitty.

Set the performance budget #

This Glitch already contains bundlesize.

Click Remix to Edit to make the project editable.

The main bundle of this app is in the public folder. To test its size, add the following section to the package.json file:

"bundlesize": [
  {
    "path": "./public/*.bundle.js",
    "maxSize": "170 kB"
  }
]

To keep the compressed JavaScript bundle size under the recommended limit, set the performance budget to 170KB in the maxSize field.

Bundlesize supports glob patterns and the * wildcard character in the file path will match all bundle names in the public folder.

Create a test script #

Since Travis needs a test to run, add a test script to package.json:

"scripts": {
  "start": "webpack && http-server -c-1",
  "test": "bundlesize"
}

Set up continuous integration #

Integrate GitHub and Travis CI #

First, create a new repository for this project on your GitHub account and initialize it with a README.md.

You'll need to register an account on Travis and activate GitHub Apps integration under the Settings section of your profile.

Once you have an account, go to Settings under your profile, click the Sync account button, and make sure your new repo is listed on Travis.

Authorize bundlesize to post on pull requests #

Bundlesize needs authorization to be able to post on pull requests, so visit this link to get the bundlesize token that will be stored in the Travis configuration.

In your project's Travis dashboard, go to More options > Settings > Environment variables.

Add a new environment variable with the token as the value field and BUNDLESIZE_GITHUB_TOKEN as the name.

The last thing you need to kick-off continuous integration is a .travis.yml file, which tells Travis CI what to do. To speed things up, it is already included in the project and it specifies that the app is using NodeJS.

With this step, you're all set up and bundlesize will warn you if your JavaScript ever goes over the budget. Even when you start off great, over time, as you add new features, kilobytes can pile up. With automated performance budget monitoring, you can rest easy knowing that it won't go unnoticed.

Try it out #

Trigger your first bundlesize test #

To see how the app stacks up against the performance budget, add the code to the GitHub repo that you created in step 3.

On Glitch, click Tools > Git, Import, and Export > Export to GitHub.
In the pop-up, enter your GitHub username and the name of the repo as username/repo. Glitch will export your app to a new branch named "glitch".
Create a new pull request by clicking the New pull request button on the homepage of the repository.

You'll now see status checks in progress on the pull request page.

It won't take long until all checks are done. Unfortunately, the cat voting app is a bit bloated and does not pass the performance budget check. The main bundle is 266 KB and the budget is 170 KB.

Optimize #

Luckily, there are some easy performance wins you can make by removing unused code. There are two main imports in src/index.js:

import firebase from "firebase";
import * as moment from 'moment';

The app is using Firebase Realtime Database to store the data, but it's importing the entire firebase package which consists of a lot more than just a database (auth, storage, messaging etc.).

Fix this by importing only the package that the app needs in the src/index.js file:

import firebase from "firebase";
import firebase from 'firebase/app';
import 'firebase/database';

Re-run test #

Since the source file has been updated, you need to run webpack to build the new bundle file.

Click the Tools button.
Then click the Console button. This will open the console in another tab.
In the console, type webpack and wait for it to finish the build.
Export the code to GitHub from Tools > Git, Import, and Export > Export to GitHub.
Go to the pull request page on GitHub and wait for all checks to finish.

Success! The new size of the bundle is 125.5 KB and all the checks have passed. 🎉

Unlike Firebase, importing parts of the moment library cannot be done as easily, but it's worth a shot. Check out how you can further optimize the app in the Remove unused code codelab.

Monitor #

The app is now under the budget and all is well. Travis CI and bundlesize will keep monitoring the performance budget for you, making sure your app stays fast.

Setting performance budgets with webpack

2019-01-31T00:00:00Z

Webpack combines all your imported files and packages them into one or more output files known as bundles. Bundling is neat, but as your app grows your bundles will grow too. You need to monitor bundle sizes to ensure that they don't grow too large and affect how long your application takes to load. Webpack supports setting performance budgets based on asset size and it can keep an eye on bundle sizes for you.

To see it in action, here's an app that counts the days left until New Year's. It's built with React and moment.js. (Just like real-world apps that increasingly rely on frameworks and libraries. 😉)

Measure #

This codelab already contains the app bundled with webpack.

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 get a color-coded list of assets and their sizes, type webpack in the console.

webpack

The main bundle is highlighted in yellow because it's larger than 244 KiB (250 KB).

Webpack warning you about bulky JS bundle ⚠️

These warnings are enabled by default in production mode and the default threshold is 244 KiB uncompressed, for both assets and entry points (the combination of all assets used during the initial load of a page).

Webpack warning you about bulky JS bundle ⚠️

Webpack will not only warn you, but it will also give you a recommendation on how to downsize your bundles. You can learn more about the recommended techniques on Web Fundamentals.

Webpack performance optimization recommendation 💁

Set a custom performance budget #

An appropriate performance budget will depend on the nature of your project. It's always best to do your own research. A good rule of thumb is to deliver under 170 KB of compressed/minified critical-path resources.

For this simple demo, try being even more conservative and set the budget to 100 KB (97.7 KiB). In webpack.config.js, add the following:

module.exports = {
  //...
  performance: {
    maxAssetSize: 100000,
    maxEntrypointSize: 100000,
    hints: "warning"
  }
};

The new performance budget is set in bytes:

100000 bytes for individual assets (maxAssetSize)
100000 bytes for the entry-point (maxEntrypointSize)

In this case, there's only one bundle which also acts as the entry point.

Possible values for hints are:

warning (default): Displays a yellow warning message, but the build passes. It's best to use this in development environments.
error: Displays a red error message, but the build still passes. This setting is recommended for production builds.
false: No warnings or errors are shown.

Webpack performance hint "error" 🚨

Optimize #

The purpose of a performance budget is to warn you about performance issues before they become too difficult to fix. There is always more than one way to build an app and some techniques will make for faster load times. (A lot of them are documented right here in Optimizing your JavaScript. 🤓)

Frameworks and libraries make developers' lives easier, but end users don't really care how apps are built, only that they're functional and fast. If you find yourself going over the performance budget, it's time to think about possible optimizations.

In the real world, large client-side frameworks are usually hard to swap out, so it's important to use them wisely. With a bit of research, you can often find smaller alternatives to popular libraries that do the job just as well (date-fns is a good alternative for moment.js). Sometimes it makes more sense to not use a framework or library at all if it has a significant performance impact.

Removing unused code a good way to optimize apps that include large third-party libraries. The Remove unused code guide explains this process in detail and here's a quick way to rewrite the countdown code without using moment.js.

In app/components/Countdown.jsx remove:

const today = moment();
const yearEnd = moment().endOf('year');
const daysLeft = yearEnd.diff(today, 'days');

And delete this line:

const moment = require('moment');

It takes a bit of math, but you can implement the same countdown with vanilla JavaScript:

const today = new Date();
const year = today.getFullYear();
const yearEnd = new Date(year,11,31); //months are zero indexed in JS
const timeDiff = Math.abs(yearEnd.getTime() - today.getTime());
const daysLeft = Math.ceil(timeDiff / (1000 * 3600 * 24));

Now remove moment.js from package.json and run webpack in the console again to build the optimized bundle.

Ta-da! You have shaved off 223 KiB (230KB) and the app is under budget.🎉

Monitor #

Setting up a performance budget in webpack takes just a couple of lines of code and it will warn you if you ever (accidentally) add a big dependency. The saying goes "out of sight, out of mind" but webpack can make sure that you are aware of performance implications at all times.

Using Lighthouse Bot to set a performance budget

2019-01-28T00:00:00Z

You've done hard work to get fast, now make sure you stay fast by automating performance testing with Lighthouse Bot.

Lighthouse grades your app in 5 categories, and one of those is performance. While you could try to remember to monitor performance changes with DevTools or Lighthouse CLI every time you edit your code, you don't have to do that. Tools can do the tedious stuff for you. Travis CI is a great service that automatically runs tests for your app in the cloud every time you push new code.

Lighthouse Bot integrates with Travis CI, and its performance budget feature ensures that you won't accidentally downgrade performance without noticing. You can configure your repository so that it won't allow merging pull-requests if the Lighthouse scores fall below the threshold you've set (e.g. < 96/100).

Lighthouse Bot checks on GitHub.

Although you can test performance on localhost, your site will often perform differently on live servers. To get a more realistic picture, it's best to deploy your site to a staging server. You can use any hosting service; this guide will take Firebase hosting for a spin.

1. Setup #

This simple app helps you sort three numbers.

Clone the example from GitHub, and make sure to add it as a repository on your GitHub account.

2. Deploy to Firebase #

To get started, you'll need a Firebase account. Once you've taken care of that, create a new project in the Firebase console by clicking "Add project":

Deploying to Firebase #

You'll need Firebase CLI to deploy the app. Even if you already have it installed, it's good practice to frequently update the CLI to the latest version with this command:

npm install -g firebase-tools

To authorize the Firebase CLI, run:

firebase login

Now initialize the project:

firebase init

The console will ask you a series of questions during setup:

When prompted to select features, choose "Hosting."
For the default Firebase project, select the project that you've created in the Firebase console.
Type in "public" as your public directory.
Type "N" (no) to configuring as a single-page app.

This process creates a firebase.json configuration file in the root of your project directory.

Congrats, you're ready to deploy! Run:

firebase deploy

In a split second, you'll have a live app.

3. Setting up Travis #

You'll need to register an account on Travis and then activate GitHub Apps integration under the Settings section of your profile.

Once you have an account #

Go to Settings under your profile, hit the Sync account button, and make sure your project repo is listed on Travis.

To kick-off continuous integration, you need two things:

To have a .travis.yml file in the root directory
To trigger a build by doing a regular old git push

The lighthouse-bot-starter repo already has a .travis.yml YAML file:

language: node_js
node_js:
  - "8.1.3"
install:
  - npm install
before_script:
  - npm install -g firebase-tools
script:
  - webpack

The YAML file tells Travis to install all the dependencies and build your app. Now it's your turn to push the example app to your own GitHub repository. If you haven't already, run the following command:

git push origin main

Click on your repo under Settings in Travis to see your project's Travis dashboard. If everything is cool, you'll see your build go from yellow to green in a couple of minutes. 🎉

4. Automate Firebase deployment with Travis #

In Step 2, you logged into your Firebase account and deployed the app from the command line with firebase deploy. In order for Travis to deploy your app to Firebase, you have to authorize it. How do you do that? With a Firebase token. 🗝️🔥

Authorize Firebase #

To generate the token run this command:

firebase login:ci

It will open a new tab in a browser window so that Firebase can verify you. After that, look back at the console, and you'll see your freshly minted token. Copy it and go back to Travis.

In your project's Travis dashboard, go to More options > Settings > Environment variables.

Paste the token in the value field, name the variable FIREBASE_TOKEN, and add it.

Add deployment to your Travis setup #

You need the following lines to tell Travis to deploy the app after every successful build. Add them to the end of the .travis.yml file. 🔚

after_success:
  - firebase deploy --token $FIREBASE_TOKEN --non-interactive

Push this change to GitHub and wait for your first automated deployment. If you take a look at your Travis log, it should soon say ✔️ Deploy complete!

Now whenever you make changes to your app, they will be automatically deployed to Firebase.

5. Setting up Lighthouse Bot #

Friendly Lighthouse Bot updates you on your app's Lighthouse scores. It just needs an invitation to your repo.

On GitHub, go to your project's settings and add "lighthousebot" as a collaborator (Settings>Collaborators):

Approving these requests is a manual process so they don't always happen instantly. Before you start testing, make sure lighthousebot has approved its collaborator status. In the meantime, you also need to add another key to your project's environment variables on Travis. Leave your email here, and you'll get a Lighthouse Bot key in your inbox. 📬

On Travis, add this key as an environment variable and name it LIGHTHOUSE_API_KEY:

Add Lighthouse Bot to your project #

Next, add Lighthouse Bot to your project by running:

npm i --save-dev https://github.com/ebidel/lighthousebot

And add this bit to the package.json:

"scripts": {
  "lh": "lighthousebot"
}

Add Lighthouse Bot to your Travis configuration #

For the final trick, test the performance of the app after every pull request!

In .travis.yml add another step in after_success:

after_success:
  - firebase deploy --token $FIREBASE_TOKEN --non-interactive
  - npm run lh -- https://staging.example.com

It will run a Lighthouse audit on the given URL, so replace https://staging.example.com with the URL of your app (that's your-app-123.firebaseapp.com).

Set your standards high and tweak the setup so you don't accept any changes to the app that bring the performance score below 95:

- npm run lh -- --perf=95 https://staging.example.com

Make a pull request to trigger Lighthouse Bot test on Travis #

Lighthouse Bot will only test pull requests, so if you push to the main branch now, you'll just get "This script can only be run on Travis PR requests" in your Travis log.

To trigger the Lighthouse Bot test:

Checkout a new branch
Push it to GitHub
Make a pull request

Hang tight on that pull request page and wait for Lighthouse Bot to sing! 🎤

The performance score is great, the app is under budget, and the check has passed!

More Lighthouse options #

Remember how Lighthouse tests 5 different categories? You can enforce scores for any of those with Lighthouse Bot flags:

--perf  # performance
--pwa   # progressive web app score
--a11y  # accessibility score
--bp    # best practices score
--seo   # SEO score

Example:

npm run lh -- --perf=93 --seo=100 https://staging.example.com

This will fail the PR if the performance score drops below 93 or the SEO score drops below 100.

You can also choose not to get Lighthouse Bot's comments with the --no-comment option.

Preload critical assets to improve loading speed

2018-11-05T00:00:00Z

When you open a web page, the browser requests the HTML document from a server, parses its contents, and submits separate requests for any referenced resources. As a developer, you already know about all the resources your page needs and which of them are the most important. You can use that knowledge to request the critical resources ahead of time and speed up the loading process. This post explains how to achieve that with <link rel="preload">.

How preloading works #

Preloading is best suited for resources typically discovered late by the browser.

In this example, Pacifico font is defined in the stylesheet with a @font-face rule. The browser loads the font file only after it has finished downloading and parsing the stylesheet.

By preloading a certain resource, you are telling the browser that you would like to fetch it sooner than the browser would otherwise discover it because you are certain that it is important for the current page.

In this example, Pacifico font is preloaded, so the download happens in parallel with the stylesheet.

The critical request chain represents the order of resources that are prioritized and fetched by the browser. Lighthouse identifies assets that are on the third level of this chain as late-discovered. You can use the Preload key requests audit to identify which resources to preload.

You can preload resources by adding a <link> tag with rel="preload" to the head of your HTML document:

<link rel="preload" as="script" href="critical.js">

The browser caches preloaded resources so they are available immediately when needed. (It doesn't execute the scripts or apply the stylesheets.)

Resource hints, for example, preconnectand prefetch, are executed as the browser sees fit. The preload, on the other hand, is mandatory for the browser. Modern browsers are already pretty good at prioritizing resources, that's why it's important to use preload sparingly and only preload the most critical resources.

Unused preloads trigger a Console warning in Chrome, approximately 3 seconds after the load event.

Use cases #

Preloading resources defined in CSS #

Fonts defined with @font-face rules or background images defined in CSS files aren't discovered until the browser downloads and parses those CSS files. Preloading these resources ensures they are fetched before the CSS files have downloaded.

Preloading CSS files #

If you are using the critical CSS approach, you split your CSS into two parts. The critical CSS required for rendering the above-the-fold content is inlined in the <head> of the document and non-critical CSS is usually lazy-loaded with JavaScript. Waiting for JavaScript to execute before loading non-critical CSS can cause delays in rendering when users scroll, so it's a good idea to use <link rel="preload"> to initiate the download sooner.

Preloading JavaScript files #

Because browsers don't execute preloaded files, preloading is useful to separate fetching from execution which can improve metrics such as Time to Interactive. Preloading works best if you split your JavaScript bundles and only preload critical chunks.

How to implement rel=preload #

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

<head>
  <link rel="preload" as="script" href="critical.js">
</head>

Supplying the as attribute helps the browser set the priority of the prefetched resource according to its type, set the right headers, and determine whether the resource already exists in the cache. Accepted values for this attribute include: script, style, font, image, and others.

Some types of resources, such as fonts, are loaded in anonymous mode. For those you must set the crossorigin attribute with preload:

<link rel="preload" href="ComicSans.woff2" as="font" type="font/woff2" crossorigin>

<link> elements also accept a type attribute, which contains the MIME type of the linked resource. The browsers use the value of the type attribute to make sure that resources get preloaded only if their file type is supported. If a browser doesn't support the specified resource type, it will ignore the <link rel="preload">.

You can also preload any type of resource via the Link HTTP header:

Link: </css/style.css>; rel="preload"; as="style"

A benefit of specifying preload in the HTTP Header is that the browser doesn't need to parse the document to discover it, which can offer small improvements in some cases.

Preloading JavaScript modules with webpack #

If you are using a module bundler that creates build files of your application, you need to check if it supports the injection of preload tags. With webpack version 4.6.0 or later, preloading is supported through the use of magic comments inside import():

import(_/* webpackPreload: true */_ "CriticalChunk")

If you are using an older version of webpack, use a third-party plugin such as preload-webpack-plugin.

Effects of preloading on Core Web Vitals #

Preloading is a powerful performance optimization that has an effect on loading speed. Such optimizations can lead to changes in your site's Core Web Vitals, and it's important to be aware them.

Largest Contentful Paint (LCP) #

Preloading has a powerful effect on Largest Contentful Paint (LCP) when it comes to fonts and images, as both images and text nodes can be LCP candidates. Hero images and large runs of text that are rendered using web fonts can benefit significantly from a well-placed preload hint, and should be used when there are opportunities to deliver these important bits of content to the user faster.

However, you want to be careful when it comes to preloading—and other optimizations! In particular, avoid preloading too many resources. If too many resources are prioritized, effectively none of them are. The effects of excessive preload hints will be especially detrimental to those on slower networks where bandwidth contention will be more evident.

Instead, focus on a few high-value resources that you know will benefit from a well-placed preload. When preloading fonts, ensure that you're serving fonts in WOFF 2.0 format to reduce resource load time as much as possible. Since WOFF 2.0 has excellent browser support, using older formats such as WOFF 1.0 or TrueType (TTF) will delay your LCP if the LCP candidate is a text node.

When it comes to LCP and JavaScript, you'll want to ensure that you're sending complete markup from the server in order for the browser's preload scanner to work properly. If you're serving up an experience that relies entirely on JavaScript to render markup and can't send server-rendered HTML, it would be advantageous to step in where the browser preload scanner can't and preload resources that would only otherwise be discoverable when the JavaScript finishes loading and executing.

Cumulative Layout Shift (CLS) #

Cumulative Layout Shift (CLS) is an especially important metric where web fonts are concerned, and CLS has significant interplay with web fonts that use the font-display CSS property to manage how fonts are loaded. To minimize web font-related layout shifts, consider the following strategies:

Preload fonts while using the default block value for font-display. This is a delicate balance. Blocking the display of fonts without a fallback can be considered a user experience problem. On one hand, loading fonts with font-display: block; eliminates web font-related layout shifts. On the other hand, you still want to get those web fonts loaded as soon as possible if they're crucial to the user experience. Combining a preload with font-display: block; may be an acceptable compromise.
Preload fonts while using the fallback value for font-display. fallback is a compromise between swap and block, in that it has an extremely short blocking period.
Use the optional value for font-display without a preload. If a web font isn't crucial to the user experience, but it is still used to render a significant amount of page text, consider using the optional value. In adverse conditions, optional will display page text in a fallback font while it loads the font in the background for the next navigation. The net result in these conditions is improved CLS, as system fonts will render immediately, while subsequent page loads will load the font immediately without layout shifts.

CLS is a difficult metric to optimize for when it comes to web fonts. As always, experiment in the lab, but trust your field data to determine if your font loading strategies are improving CLS or making it worse.

Responsiveness metrics #

First Input Delay (FID) and Interaction to Next Paint are two metrics that gauge responsiveness to user input. Since the lion's share of interactivity on the web is driven by JavaScript, preloading JavaScript that powers important interactions may help to keep your FID and INP metrics as low as they can possibly be. However, be aware that FID is a load responsiveness metric and INP observes interactions throughout the entire page lifecycle—including during startup. Preloading too much JavaScript during startup can carry unintended negative consequences if too many resources are contending for bandwidth.

You'll also want to be careful about how you go about code splitting. Code splitting is an excellent optimization for reducing the amount of JavaScript loaded during startup, but interactions can be delayed if they rely on JavaScript loaded right at the start of the interaction. To compensate for this, you'll need to examine the user's intent, and inject a preload for the necessary chunk(s) of JavaScript before the interaction takes place. One example could be preloading JavaScript required for validating a form's contents when any of the fields in the form are focused.

Conclusion #

To improve page speed, preload important resources that are discovered late by the browser. Preloading everything would be counterproductive so use preload sparingly and measure the impact in the real-world.

Performance budgets 101

2018-11-05T00:00:00Z

Performance is an important part of the user experience and it affects business metrics. It's tempting to think that if you are a good developer you'll end up with a performant site, but the truth is that good performance is rarely a side effect. As with most other things—to reach a goal you have to define it clearly. Start the journey by setting a performance budget.

Definition #

A performance budget is a set of limits imposed on metrics that affect site performance. This could be the total size of a page, the time it takes to load on a mobile network, or even the number of HTTP requests that are sent. Defining a budget helps get the web performance conversation started. It serves as a point of reference for making decisions about design, technology, and adding features.

Having a budget enables designers to think about the effects of high-resolution images and the number of web fonts they pick. It also helps developers compare different approaches to a problem and evaluate frameworks and libraries based on their size and parsing cost.

Choose metrics #

Quantity-based metrics ⚖️ #

These metrics are useful in the early stages of development because they highlight the impact of including heavy images and scripts. They are also easy to communicate to both designers and developers.

We've already mentioned a few things you can include in a performance budget such as page weight and the number of HTTP requests, but you can split these up into more granular limits like:

Maximum size of images
Maximum number of web fonts
Maximum size of scripts, including frameworks
Total number of external resources, such as third-party scripts

However, these numbers don't tell you much about the user experience. Two pages with the same number of requests or same weight can render differently depending on the order in which resources get requested. If a critical resource like a hero image or a stylesheet on one of the pages is loaded late in the process, the users will wait longer to see something useful and perceive the page as slower. If on the other page the most important parts load quickly, they may not even notice if the rest of the page doesn't.

This is why it's important to keep track of another type of metric.

Milestone timings ⏱️ #

Milestone timings mark events that happen during page load, such as DOMContentLoaded or load event. The most useful timings are user-centric performance metrics that tell you something about the experience of loading a page. These metrics are available through browser APIs and as part of Lighthouse reports.

First Contentful Paint (FCP) measures when the browser displays the first bit of content from the DOM, like text or images.

Time to Interactive (TTI) measures how long it takes for a page to become fully interactive and reliably respond to user input. It's a very important metric to track if you expect any kind of user interaction on the page like clicking links, buttons, typing or using form elements.

Rule-based metrics 💯 #

Lighthouse and WebPageTest calculate performance scores based on general best practice rules, that you can use as guidelines. As a bonus, Lighthouse also offers you hints for simple optimizations.

You'll get the best results if you keep track of a combination of quantity-based and user-centric performance metrics. Focus on asset sizes in the early phases of a project and start tracking FCP and TTI as soon as possible.

Establish a baseline #

The only way to really know what works best for your site is to try it—research and then test your findings. Analyze the competition to see how you stack up. 🕵️

If you don't have time for that, here are good default numbers to get you started:

Under 5 s Time to Interactive
Under 170 KB of critical-path resources (compressed/minified)

These numbers are calculated based on real-world baseline devices and 3G network speed. Over half of the internet traffic today happens on mobile networks, so you should use 3G network speed as a starting point.

Examples of budgets #

You should have a budget in place for different types of pages on your site since the content will vary. For example:

Our product page must ship less than 170 KB of JavaScript on mobile
Our search page must include less than 2 MB of images on desktop
Our home page must load and get interactive in < 5 s on slow 3G on a Moto G4 phone
Our blog must score > 80 on Lighthouse performance audits

Add performance budgets to your build process #

Choosing a tool for this will depend a lot on the scale of your project and resources that you can dedicate to the task. There are a few open-source tools that can help you add budgeting to your build process:

If something goes over a defined threshold, you can either:

Optimize an existing feature or asset 🛠️
Remove an existing feature or asset 🗑️
Not add the new feature or asset ✋⛔

Track performance #

Making sure your site is fast enough means you have to keep measuring after the initial launch. Monitoring these metrics over time and getting data from real users will show you how changes in performance impact key business metrics.

Wrap up #

The purpose of a performance budget is to make sure you focus on performance throughout a project and setting it early will help prevent backtracking later. It should be the point of reference for helping you figure out what to include on your website. The main idea is to set goals so that you can better balance performance without harming functionality or user experience.🎯

The next guide will walk you through defining your first performance budget in a few simple steps.

Your first performance budget

2018-11-05T00:00:00Z

When you set a personal, business or family budget, you are setting a limit to your spending and making sure you stay within it. Performance budgets work in the same way, but for metrics that affect website performance.

With a performance budget established and enforced you can be sure that your site will render as quickly as possible. This will provide a better experience for your visitors and positively impact business metrics.

Here's how to define your first performance budget in a few simple steps.

Preliminary analysis #

If you are trying to improve the performance of an existing site, start by identifying the most important pages. For example, these could be pages that have the highest amount of user traffic or a product landing page.

After you identify your key pages, it's time to analyze them. First, we'll focus on the timing milestones that best measure the user experience.

Under the Audits panel in Chrome DevTools, you'll find Lighthouse. Run audits on each page in a Guest window to record these two times:

Let's take a highly specialized search engine, Doggos.com, as an example. Doggos.com aims to index all dog-related things on the internet, and its most important pages are the home and results pages. Here are the FCP and TTI numbers measured for the site on desktop and mobile.

Desktop analysis of Doggos.com
Desktop	FCP	TTI
Homepage	1,680 ms	5,550 ms
Results page	2,060 ms	6,690 ms

Mobile analysis of Doggos.com
Mobile	FCP	TTI
Homepage	1,800 ms	6,150 ms
Results page	1,100 ms	7,870 ms

Competitive analysis #

Once you've analyzed your own site, it's time to analyze your competitors' sites. Comparing results from websites similar to yours is a great way to figure out a performance budget. Whether you are working on an established project or starting from scratch, this is an important step. You get competitive advantage when you are faster than your competitors.

If you are not sure which sites to look at, here are a few tools to try:

Google search's "related:" keyword
Alexa's similar sites feature
SimilarWeb

For a realistic picture, try to find 10 or so competitors.

Budget for timing milestones #

Our niche search engine in this example has a handful of competitors and we'll focus on optimizing the homepage for mobile devices. Over half of the internet traffic today happens on mobile networks and using mobile numbers as default will benefit not only your mobile users, but your desktop users as well.

Create a chart with FCP and TTI times for all the similar websites and highlight the fastest in the bunch. A chart like this one gives you a clearer picture of how your website is doing compared to the competition.

Competitive analysis of Doggos.com on 3G network
Site/Homepage	FCP	TTI
goggles.com	880 ms	3,150 ms
Doggos.com	1,800 ms	6,500 ms
quackquackgo.com	2,680 ms	4,740 ms
ding.xyz	2,420 ms	7,040 ms

Doggos.com seems to be doing okay on the FCP metric but seriously lagging behind in TTI

There's room for improvement and a good guideline for that is the 20% rule. Research states that users recognize a difference in response times when it's greater than 20%. This means that if you want to be noticeably better than the best comparable site, you have to be at least 20% faster.

Performance budget that would get Doggos.com ahead of the competition
Measure	Current time	Budget (20% faster than competition)
FCP	1,800 ms	704 ms
TTI	6,500 ms	2,520 ms

If you are trying to optimize an existing site that goal may seem impossible to reach. This is not a sign for you to give up. Start with small steps and set a budget at 20% faster than your current speed. Keep optimizing from there.

For Doggos.com, a revised budget could look like this.

Revised Doggos.com performance budget
Measure	Current time	Initial budget (20% faster than the current time)	Long-term goal (20% faster than competition)
FCP	1,800 ms	1,440 ms	704 ms
TTI	6,500 ms	5,200 ms	2,520 ms

Combine different metrics #

A solid performance budget combines different types of metrics. We've already defined the budget for milestone timings and now we'll add two more to the mix:

quantity-based metrics
rule-based metrics

Budget for quantity-based metrics #

Whatever total page weight number you come up with, try to deliver under 170 KB of critical-path resources (compressed/minified). This guarantees your website will be fast even on inexpensive devices and slow 3G.

You can have a bigger budget for the desktop experience, but don't go wild. The median page weight on both desktop and mobile is over 1MB according to the HTTP Archive data for the last year. To get a performant website you have to aim well below these median numbers.

Here are a few examples based on TTI budgets:

Network	Device	JS	Images	CSS	HTML	Fonts	Total	Time to Interactive budget
Slow 3G	Moto G4	100	30	10	10	20	~170 KB	5s
Slow 4G	Moto G4	200	50	35	30	30	~345 KB	3s
WiFi	Desktop	300	250	50	50	100	~750 KB	2s

Defining a budget based on quantity metrics is a tricky business. An e-commerce website with loads of product photos is very different from a news portal which is mostly text. If you have ads or analytics on your site, that increases the amount of JavaScript you're shipping.

Use the table above as a starting point and adjust based on the type of content you are working with. Define what your pages will include, review your research and take an educated guess for individual asset sizes. For example, if you are building a website with a lot of images, put stricter limits to JS size.

Once you have a working website, check how you are doing on user-centric performance metrics and adjust your budget.

Budget for rule-based metrics #

Very effective rule-based metrics are Lighthouse scores. Lighthouse grades your app in 5 categories and one of those is performance. Performance scores are calculated based on 5 different metrics, including First Contentful Paint and Time to Interactive.

When you try to build a great site, set Lighthouse performance score budget to at least 85 (out of 100). Use Lighthouse CI to enforce it on pull-requests.

Prioritize #

Ask yourself what level of interaction you expect on your site. If it's a news website, users' primary goal is to read content so you should focus on rendering quickly and keeping FCP low. Doggos.com visitors want to click on relevant links as soon as possible, so the top priority is low TTI.

Find out exactly what part of your audience browses on desktop vs. on mobile devices and prioritize accordingly. One way to figure this out is to check what your audience is doing on competitors' websites, through the Chrome User Experience report dashboard.

Device distribution data from Chrome User Experience report

Next steps #

Make sure your performance budget is enforced throughout the project and incorporate it into your build process.

Milica Mihajlija on web.dev

First-party cookie recipes

The good first-party cookie recipe #

The recipe #

First-party cookie recipe for sites with subdomains #

The recipe #

Restricting first-party cookie access on requests initiated from third-party websites #

The recipe #

Chrome and Firefox soon to reach major version 100

User-Agent string #

Major version 100—three-digit version number #

Version 100 timelines #

Why can a three-digit version number be problematic? #

What are browsers doing about it? #

Chrome mitigation #

Firefox mitigation #

What can you do to help? #

Configure Chrome to report the major version as 100 #

Configure Firefox Nightly to report the major version as 100 #

Test and file reports #

How CLS optimizations increased Yahoo! JAPAN News's page views per session by 15%

Identifying the issue #

Improving CLS for images #

Results #

Life of a payment transaction

Step 1: The merchant initiates a payment transaction #

Step 2: The merchant shows a payment button #

Does the customer have the payment app available? #

Step 3: The customer presses the payment button #

Deferring the launch of the payment UI #

Step 4: The browser launches the payment app #

Step 5: How a merchant can update the transaction details depending on customer's actions #

Payment method change event #

Shipping address change event #

Shipping option change event #

Merchant validation event #

Step 6: The merchant validates the payment and completes the transaction #

Processing and validating the payment #

Completing or retrying the transaction #

Next Steps #

Adaptive loading: improving web performance on slow devices

What is adaptive loading? #

Browser support and how to implement adaptive loading #

Navigator.deviceMemory #

Navigator.hardwareConcurrency #

NetworkInformation.effectiveType #

NetworkInformation.saveData #

Adaptive loading in React #

Adaptive loading in action #

Adaptive loading at Facebook #

Learn more about adaptive loading #

Route prefetching in Next.js

What will you learn? #

The <Link> component #

How automatic prefetching works #

Avoid unnecessary prefetching #

Prefetching with custom routing #

Conclusion #

Code splitting with dynamic imports in Next.js

What will you learn? #

Route-based and component-based code splitting #

Dynamic imports in action #

Dynamic imports with custom loading indicator #

Dynamic imports without SSR #

Conclusion #

Efficiently load third-party JavaScript

Use async or defer #

async #

defer #

Establish early connections to required origins #

preconnect #

dns-prefetch #

Lazy-load third-party resources #

Optimize how you serve third-party scripts #

Third-party CDN hosting #

Self-host third-party scripts #

Use service workers to cache scripts from third-party servers #

Identify slow third-party JavaScript

If you only have 5 minutes #

Third-party usage #

`Navigator.deviceMemory` #

`Navigator.hardwareConcurrency` #

`NetworkInformation.effectiveType` #

`NetworkInformation.saveData` #

The `<Link>` component #

Use `async` or `defer` #

`async` #

`defer` #

`preconnect` #

`dns-prefetch` #

Step 1: Load the script asynchronously with the `defer` attribute #

Establish early connections with `rel=preconnect` #

Use-cases for `rel=preconnect` #

How to implement `rel=preconnect` #

Resolve domain name early with `rel=dns-prefetch` #