web.dev

New to the web platform in September

2023-10-02T00:00:00Z

Stable browser releases #

In September 2023 Firefox 118, Safari 17, and Chrome 117 became stable. This post takes a look at what that means for the web platform.

The subgrid value for grid-template-columns and grid-template-rows is included in Chrome 117, making this longed for feature interoperable. You can learn more about subgrid in the article CSS subgrid.

Browser support

Chrome 114, Behind a flag
Firefox 71, Supported 71
Edge 114, Behind a flag
Safari 16, Supported 16

Source

Chrome also includes three new CSS features to easily add entry and exit animations, and smoothly animate to and from the top layer dismissible elements such as dialogs and popovers. You can learn about the transition-behavior property, @starting-style rule, and overlay property in the article Four new CSS features for entry and exit animations.

Browser support

Chrome, Not supported
Firefox, Not supported
Edge, Not supported
Safari, Not supported

Also in Chrome 117 is JavaScript array grouping with the Object.groupBy and Map.groupBy static methods.

Browser support

Chrome, Not supported
Firefox, Not supported
Edge, Not supported
Safari, Not supported

Safari 17 includes the popover attribute, to add support for the Popover API.

Browser support

Chrome, Not supported
Firefox, Not supported
Edge, Not supported
Safari, Not supported

Safari 17 and Firefox 118 include the HTML <search> element. This element represents the parts of the page or application that contain funtionality for search or filtering content.

Browser support

Chrome, Not supported
Firefox, Not supported
Edge, Not supported
Safari, Not supported

Source

There are lots of new CSS features included in Safari 17, including @counter-style. This rule lets you define counter styles that are outside the predefined list of style. This feature is now available in all three engines.

Browser support

Chrome 91, Supported 91
Firefox 33, Supported 33
Edge 91, Supported 91
Safari 17, Supported 17

Source

Firefox 118 includes several additional CSS math functions: abs(), sign(), round(), mod(), rem(), pow(), sqrt(), hypot(), log(), and exp().

Browser support

Chrome, Not supported
Firefox 112, Supported 112
Edge, Not supported
Safari 15.4, Supported 15.4

Source

Safari 17 also includes support for HEIC/HEIF images, and JPEG XL.

Beta browser releases #

Beta browser versions give you a preview of things that will be in the next stable version of the browser. It's a great time to test new features, or removals, that could impact your site before the world gets that release. New betas are Firefox 119, Safari 17.1, and Chrome 118. These releases bring many great features to the platform. Check out the release notes for all of the details, here are just a few highlights.

The <search> element, shipping in Firefox and Safari this month is included in Chrome 118, meaning this feature is quickly landing across all three engines.

The Object.groupBy and Map.groupBy static methods are part of Firefox 119.

Chrome 118 includes CSS scoped styles with the @scope rule and new media features with prefers-reduced-transparency and scripting.

Safari 17.1 is currently a release that fixes a range of issues across the platform.

Photo by Charles Deluvio.

Effectively loading ads without impacting page speed

2023-09-29T00:00:00Z

Websites heavily rely on online advertising as a primary source of revenue. However, the presence of ads on websites can sometimes come at the expense of user experience and overall page performance. It's therefore vital to strike a balance between monetization and performance for website owners and advertisers, and the user experience.

Consider a website that extensively places ads within its content, aiming to generate high revenue. However, the overwhelming number of ads frustrates users, leading to a poor user experience and high bounce rates. Despite the potential for substantial revenue from ads, abandonment severely hampers the website's success.

On the other end of the spectrum, consider a website with no ads. This ad-free environment attracts a significant number of users due to its fast loading time and seamless browsing experience. However, without a monetization strategy in place, the website struggles to generate revenue, which may hinder its long-term sustainability and growth.

Both scenarios illustrate the importance of balancing monetization, users and performance.

Harnessing Core Web Vitals #

Passing the Core Web Vitals is essential when it comes to loading ads without negatively impacting page speed. Core Web Vitals, comprising metrics such as Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and First Input Delay (FID) (as well as the upcoming Interaction to Next Paint (INP) Core Web Vital metric slated to replace FID), are user experience metrics that measure the quality of the user experience of your website.

Largest Contentful Paint (LCP) #

Focusing on optimizing LCP is vital, as this metric measures the time it takes for the largest contentful element to become visible within the viewport. By minimizing the loading time of ad content and by prioritizing asynchronous loading techniques, website owners can reduce LCP and decrease rendering time of the most prominent contentful elements on a page.

First Input Delay (FID) and Interaction to Next Paint (INP) #

Secondly, improving INP (and by extension, optimizing FID) is crucial for interactivity. FID measures the time it takes for the browser to respond to the first user interaction, such as a click or tap. The INP metric, slated to replace FID in March of 2024, goes much further by measuring a page's overall ability to process all click, keyboard, and tap interactions throughout the page lifecycle.

Ads that delay user interactions negatively impact INP and FID. This may frustrate users by creating experiences that feel sluggish, or even altogether broken in extreme cases. Implementing lazy loading for ads and deferring non-critical JavaScript execution can help reduce page INP and FID, and therefore improve overall page responsiveness.

Cumulative Layout Shift (CLS) #

Lastly, CLS measures a page's visual stability by measuring the amount of unexpected layout shifts that occur during page load. Ads that dynamically load or resize can result in layout instability, leading to a poor user experiences where users either lose track of where they are on a page, or even unintentionally tap on the wrong elements due to unexpected layout shifts. To mitigate this, website owners should optimize CLS to ensure that ads have reserved space to prevent layout shifts, and ad sizes should be optimized to avoid sudden content reflows.

Structuring your webpage into distinct content blocks #

Structuring your web page with content blocks for both text, image, and ad content, while also using the CSS content-visibility: property, can significantly improve overall rendering time in modern browsers.

By strategically applying the content-visibility: property within these content blocks, you optimize the rendering process for text, image, and ad content. This ensures that only the content currently in the viewport is fully rendered, resulting in a faster initial page load and smoother user interactions. This performance enhancement is particularly valuable when dealing with lengthy or pages with many ads.

Prioritize important ad slots #

Not all ad slots are equal. For example, above-the-fold ad slots are usually more valuable than those that are below the fold in terms of viewability and monetization. This is because above-the-fold ads are more likely to be seen by users, as they are visible without scrolling in the first viewport. Below-the-fold ads become visible after the user scrolls down the page far enough to see them.

Above the fold ads #

Above the fold ad slots refer to the portion of a webpage that is visible without scrolling, and hold significant value in digital advertising. These prime placements are considered valuable for several reasons:

Advertisements placed above the fold are immediately visible for users upon loading a webpage. Users are more likely to notice and engage with these ads, resulting in higher click-through rates.
Advertisers often consider the top portion of a webpage as the most valuable real estate. It's the first impression users get when they visit a site, making it a crucial area for showcasing high-impact and premium ads.
Ads above the fold have the highest viewability rates because they are in the user's direct line of sight. This ensures that the majority of users who visit the page will see these ads without having to scroll down.

However, it's important to strike a balance between monetization and the user experience when utilizing above the fold ad slots in the initial view. Here are some key considerations.

First screen ad slots should load as fast as possible in the user's initial viewport. Slow-loading ads can negatively impact user experience and increase bounce rates. Optimizing ad load times is crucial to maintain a smooth user and browsing experience.
While above the fold ad placements are valuable, it's important to not overload this prime space with too many ads. Excessive ads clutter the page, disrupt content readability, and detract from the user experience. Strive for a balance between monetization and maintaining a clean, user-friendly layout.
Ensure above the fold ad slots are compatible with different screen sizes and devices. Responsive design practices can help maintain a consistent and visually appealing layout regardless of the user's screen size.

Below the fold ads #

Below the fold ad slots—that is, ads placed within the portion of a webpage that becomes visible only after scrolling down—also hold considerable value in the world of digital advertising. These placements offer unique advantages that complement above the fold placements.

Ads located below the fold benefit from users who scroll down to explore more content. These placements capture the attention of engaged users who are actively seeking additional information, making them valuable for brands looking to convey more complex messages or storytelling.

Ad slots which are not initially visible can align with the content next to them, providing an opportunity for contextual relevance. This alignment can lead to higher user engagement as users discover ads that are related to the content they are exploring.
When designed thoughtfully, below the fold ads can seamlessly integrate with the surrounding content, appearing less disruptive to users. This integration—also known as native advertising—can result in a more harmonious user experience.
Scroll required ad placements offer more creative design and format flexibility, with ample space and freedom to experiment. Video ads, interactive elements, and larger images can be lazy loaded to capture user attention without disrupting their experience.

However, the following considerations should be given for below the fold ad placements:

While below the fold ad placements can be effective, it's essential to ensure that users are encouraged to scroll down. Implementing visual cues or content teasers can entice users to explore further, increasing the likelihood of ad visibility.
The placements of ads below the fold should not compromise content quality or readability. Maintaining a balance between ads and content to avoid overwhelming users and to ensure positive user experience.
Unlike above the fold ad placements, below the fold ads may not need to load immediately. Delaying the loading of these ads until they are close to entering the user's viewport can help improve overall page load speed and reduce initial page rendering times.

When used strategically, below the fold ads can complement above the fold ads, and provide a platform for creative ad formats and contextual relevance. However, optimizing visibility, balancing content, and managing ad load timing are key considerations to ensure a positive user experience.

Current Google Publisher Tag (GPT) best practices:

Lazy load ads where appropriate #

Lazy loading is a technique that defers loading non-critical resources until they are needed. Applying lazy loading for ads which are not immediately visible (that is, below-the-fold ads) ensures that they are only loaded when they come into view, conserving bandwidth and improving overall page speed. Browsers now include native lazy loading for iframes with a simple loading=lazy attribute.

By implementing lazy loading, ads are fetched dynamically when they are about to enter the user's viewport, reducing the initial load time and Total Blocking Time (TBT) (which is highly correlated with INP) on the main thread at that crucial part of the page lifecycle, therefore minimizing negative impacts on the user experience.

Refresh ads without refreshing the page #

An additional technique that can balance page performance with loading ads is the ability to refresh ads every 30 to 120 seconds without reloading the entire page. This approach allows for dynamic updates of ad content without disrupting the user's browsing experience or causing unnecessary delays.

On mobile apps, refreshing ads in existing web views provides better performance compared to reloading the entire page or recreating WebViews because it minimizes the data and resource overhead, leading to faster content updates and a smoother user experience without the latency associated with starting from scratch.

By refreshing ads asynchronously, website owners can keep the page content intact while seamlessly updating the ad content in-place and in real time. This not only improves page speed by eliminating the need to reload the entire page, but also ensures that displayed ads remain relevant and engaging. With this technique, website owners can strike a balance between monetization and performance, delivering timely and engaging ad content while minimizing negative effects on the user experience.

Refreshing ad slots is particularly valuable on pages where users tend to stay longer, such as recipe pages, DIY tutorials, or other content-rich websites. For example, on a DIY crafting page where users may spend a considerable amount of time following the tutorials, refreshing ad slots strategically during breaks between the steps, or while viewing image galleries, can enhance both the user experience and ad revenue. Similarly on a recipe page, refreshing ad slots after users have scrolled through the ingredients list or instructions can maintain user interest.

Prioritize asynchronous loading #

One of the most impactful strategies to improve page speed while serving ads is asynchronous loading. Asynchronous loading loads ads independently of the main web page content allows the page to continue rendering and become interactive without waiting for ads to fully load. This significantly reduces perceived loading time, enhancing user satisfaction.

Include the async attribute in the script tag definition. For example:

AdSense:

<script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>

AdSense (auto ads):

<script async data-ad-client="ca-pub-xxxxxxxxxxxxxxxx" src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>

Google Publisher Tag:

<script async src="https://securepubads.g.doubleclick.net/tag/js/gpt.js"></script>

Optimize ad sizes, position and formats #

The size, position, and format for ads can have a significant impact on page speed. Large ad sizes can slow down page load, leading to frustrated users. To mitigate this, website owners should work closely with advertisers to optimize ad sizes and formats. Encouraging the use of compressed image formats and efficient ad creative design helps reduce file sizes without compromising visual quality. These optimizations not only improve page speed, but also minimize data consumption for users with limited bandwidth.

Better Ads Standards #

It's essential to adhere to the Better Ads Standard for displaying ads, because doing so not only enhances the user experience by reducing intrusive and disruptive ad formats, but also positively impacts ad delivery position and page load time.

By following these standards, ads are more likely to be placed in positions that are less obstructive and intrusive, which can result in a higher user engagement and click-through rates.

Furthermore, adhering to these guidelines can also lead to faster page loading speeds since lighter, less resource-intensive ad formats are favored, improving overall website performance and user satisfaction.

Strategic evaluation of ad networks and providers #

Not all ad networks and providers are created equal in terms of performance. To ensure optimal page speed, website owners should meticulously evaluate the performance of different ad networks, header bidding implementation, and providers.

Forging partnerships with providers that prioritize speed—and have a track record of delivering lightweight ad content efficiently—can significantly increase page performance and improve the user experience.

Conclusion #

Achieving a balance between monetization and performance is crucial for website owners seeking to provide an exceptional user experience while maximizing revenue through online advertising.

By using techniques such as asynchronous loading, lazy loading, optimizing ad formats and sizes, leveraging intelligent caching and carefully evaluating ad networks, and header bidding and providers, website owners can successfully navigate the challenges of loading ads without compromising page performance. Prioritizing efficient delivery of ads ultimately ensures user stratification, increased engagement, and sustainable revenue generation.

CSS Subgrid

2023-09-28T00:00:00Z

CSS grid is a very powerful layout engine, but the row and column tracks created on a parent grid can only be used to position direct children of the grid container. Any author defined named grid areas and lines were lost on any other element than a direct child. With subgrid, track sizing, templates and names can be shared with nested grids. This article explains how it works.

Before subgrid, content was often hand tailored to avoid ragged layouts like this one.

After subgrid, aligning the variably sized content is possible.

Browser support

Chrome 114, Behind a flag
Firefox 71, Supported 71
Edge 114, Behind a flag
Safari 16, Supported 16

Source

Subgrid basics #

Here is a straightforward use case introducing the basics of CSS subgrid. A grid is defined with two named columns, the first is 20ch wide and the second is "the rest" of the space 1fr. The column names aren't required but they're great for illustrative and educational purposes.

.grid {
  display: grid;
  gap: 1rem;
  grid-template-columns: [column-1] 20ch [column-2] 1fr;
}

Then, a child of that grid, spans those two columns, is set as a grid container, and adopts the columns of its parent by setting grid-template-columns to subgrid.

.grid > .subgrid {
  grid-column: span 2;

  display: grid;
  grid-template-columns: subgrid; /* 20ch 1fr */
}

https://codepen.io/web-dot-dev/pen/NWezjXv

That's it, a parent grid's columns have been effectively passed down a level to a subgrid. This subgrid can now assign children to either of those columns.

Challenge! Repeat the same demo but do it for grid-template-rows.

Designers often work with shared grids, drawing lines over an entire design, aligning any element they want to it. Now web developers can too! This exact workflow can now be achieved, plus many more.

From macro grid to finished design. Grid named areas are created upfront and later components are placed as desired.

Implementing the most common designer grid workflow can provide excellent insights into the capabilities, workflows, and potentials of subgrid.

Here's a screenshot taken from Chrome DevTools of a mobile page layout macro grid. The lines have names and there are clear areas for component placement.

The following CSS creates this grid, with named rows and columns for the device layout. Each row and column has a size.

.device {
    display: grid;
    grid-template-rows:
      [system-status] 3.5rem
      [primary-nav] 3rem
      [primary-header] 4rem
      [main] auto
      [footer] 4rem
      [system-gestures] 2rem
    ;
    grid-template-columns: [fullbleed-start] 1rem [main-start] auto [main-end] 1rem [fullbleed-end];
}

Some additional styles give the following design.

Inside this parent, are various nested elements. The design requires a full width image under the nav and header rows. The furthest left and right column line names are fullbleed-start and fullbleed-end. Naming grid lines this way enables children to align to each simultaneously with the placement shorthand of fullbleed. It’s very convenient as you’ll soon see.

With the overall device layout created with nice named rows and columns, use subgrid to pass the well named rows and columns to nested grid layouts. This is that subgrid magic moment. The device layout passes the named rows and columns to the app container, which then passes it on to every one of its children.

.device > .app,
.app > * {
    display: grid;
    grid: subgrid / subgrid;

    /* same as */
    grid-template-rows: subgrid;
    grid-template-columns: subgrid;
}

CSS subgrid is a value used in place of a list of grid tracks. The rows and columns the element is spanning from its parent, are now the same rows and columns it offers. This makes the line names from the .device grid available to children of .app, instead of only .app. Elements inside of .app were not able to reference the grid tracks created by .device before subgrid.

With this all defined, the nested image is now able to go full bleed in the layout thanks to subgrid. No negative values or tricks, instead a nice one-liner that says “my layout spans from fullbleed-start to fullbleed-end.”

.app > main img {
    grid-area: fullbleed;
}

https://codepen.io/web-dot-dev/pen/WNLyjzX

There you have it, a macro grid like designers use, implemented in CSS. This concept can scale and grow with you as needed.

Checking for support #

Progressive enhancement with CSS and subgrid is familiar and straightforward. Use @supports and inside the parenthesis ask the browser if it understands subgrid as a value for template columns or rows. The following example checks if the grid-template-columns property supports the subgrid keyword, which if true, means that subgrid can be used

@supports (grid-template-columns: subgrid) {
  /* safe to enhance to */
}

See the Pen Pen KKrJPZQ by web-dot-dev on Codepen

Devtools #

Chrome, Edge, Firefox and Safari all have great CSS grid DevTools, and Chrome, Edge and Firefox have specific tools for helping with subgrid. Chrome announced their tools in 115 while Firefox has had them for a year or more.

The subgrid badge acts like the grid badge but visually distinguishes which grids are subgrids and which aren’t.

Resources #

This list is a compilation of subgrid articles, demos and overall inspiration for getting started. If you’re looking for the next step for your subgrid education, have fun exploring all these great resources!

Submit your proposals for Interop 2024

2023-09-14T00:00:00Z

Over the past two years the Chrome team has successfully worked with our partners to improve the interoperability of the web. For Interop 2022 all major browser vendors and other stakeholders worked together to improve top browser compatibility issues identified by web developers. We repeated the process with Interop 2023, which still has a few months to run yet is already seeing a huge improvement in scores. For Interop 2023, we also requested public proposals for features to include, which led to many great suggestions representing the needs of the wider web ecosystem.

January 2023.

September 2023.

It's been a huge success, with many features reaching interoperability, and we're happy to announce that Interop 2024 is happening.

The first step is to gather suggested features, once again including ideas from the wider community, so the Interop 2024 proposal process is now open for submissions. Suggestions can include features that behave differently across browsers, or features that are not yet implemented in all browsers. Keep in mind that proposals with high quality specifications and web platform tests are more likely to be included, as this project is about reaching interoperability rather than specifying new features. The proposal submission process ends October 5, 2023.

Once the proposal period ends, the collected submissions will be discussed by browser vendors and other partners to determine the final list. It's likely that there will be more proposals than can be achieved during 2024, so some high quality proposals may not be selected. We are looking forward to reviewing all the submissions, and we'll post the final list here once Interop 2024 gets underway.

Submit your proposals here.

Four common types of code coverage

2023-09-06T00:00:00Z

Have you heard the phrase "code coverage"? In this post, we will explore what code coverage in tests is and four common ways to measure it.

What is code coverage? #

Code coverage is a metric that measures the percentage of source code your tests execute. It helps you identify areas that may lack proper testing.

Often, recording these metrics looks like this:

File	% Statements	% Branch	% Functions	% Lines	Uncovered lines
file.js	90%	100%	90%	80%	89,256
coffee.js	55.55%	80%	50%	62.5%	10-11, 18

As you add new features and tests, increasing code coverage percentages can give you more confidence that your application has been thoroughly tested. However, there is more to discover.

Four common types of code coverage #

There are four common ways to collect and calculate code coverage: function, line, branch, and statement coverage.

To see how each type of code coverage calculates its percentage, consider the following code example for calculating coffee ingredients:

/* coffee.js */

export function calcCoffeeIngredient(coffeeName, cup = 1) {
  let espresso, water;

  if (coffeeName === 'espresso') {
    espresso = 30 * cup;
    return { espresso };
  }

  if (coffeeName === 'americano') {
    espresso = 30 * cup; water = 70 * cup;
    return { espresso, water };
  }

  return {};
}

export function isValidCoffee(name) {
  return ['espresso', 'americano', 'mocha'].includes(name);
}

The tests that verify the calcCoffeeIngredient function are:

/* coffee.test.js */

import { describe, expect, assert, it } from 'vitest';
import { calcCoffeeIngredient } from '../src/coffee-incomplete';

describe('Coffee', () => {
  it('should have espresso', () => {
    const result = calcCoffeeIngredient('espresso', 2);
    expect(result).to.deep.equal({ espresso: 60 });
  });

  it('should have nothing', () => {
    const result = calcCoffeeIngredient('unknown');
    expect(result).to.deep.equal({});
  });
});

You can run the code and tests on this live demo or check out the repository.

Function coverage #

Code coverage: 50%

/* coffee.js */

export function calcCoffeeIngredient(coffeeName, cup = 1) {
  // ...
}

function isValidCoffee(name) {
  // ...
}

Function coverage is a straightforward metric. It captures the percentage of functions in your code that your tests call.

In the code example, there are two functions: calcCoffeeIngredient and isValidCoffee. The tests only call the calcCoffeeIngredient function, so the function coverage is 50%.

Line coverage #

Code coverage: 62.5%

/* coffee.js */

export function calcCoffeeIngredient(coffeeName, cup = 1) {
  let espresso, water;

  if (coffeeName === 'espresso') {
    espresso = 30 * cup;
    return { espresso };
  }

  if (coffeeName === 'americano') {
    espresso = 30 * cup; water = 70 * cup;
    return { espresso, water };
  }

  return {};
}

export function isValidCoffee(name) {
  return ['espresso', 'americano', 'mocha'].includes(name);
}

Line coverage measures the percentage of executable code lines that your test suite executed. If a line of code remains unexecuted, it means that some part of the code hasn't been tested.

The code example has eight lines of executable code (highlighted in red and green) but the tests don’t execute the americano condition (two lines) and the isValidCoffee function (one line). This results in a line coverage of 62.5%.

Note that line coverage doesn’t take into account declaration statements, such as function isValidCoffee(name) and let espresso, water;, because they are not executable.

Branch coverage #

Code coverage: 80%

/* coffee.js */

export function calcCoffeeIngredient(coffeeName, cup = 1) {
  // ...

  if (coffeeName === 'espresso') {
    // ...
    return { espresso };
  }

  if (coffeeName === 'americano') {
    // ...
    return { espresso, water };
  }

  return {};
}
…

Branch coverage measures the percentage of executed branches or decision points in the code, such as if statements or loops. It determines whether tests examine both the true and false branches of conditional statements.

There are five branches in the code example:

Calling calcCoffeeIngredient with just coffeeName
Calling calcCoffeeIngredient with coffeeName and cup
Coffee is Espresso
Coffee is Americano
Other coffee

The tests cover all branches except the Coffee is Americano condition. So branch coverage is 80%.

Statement coverage #

Code coverage: 55.55%

/* coffee.js */

export function calcCoffeeIngredient(coffeeName, cup = 1) {
  let espresso, water;

  if (coffeeName === 'espresso') {
    espresso = 30 * cup;
    return { espresso };
  }

  if (coffeeName === 'americano') {
    espresso = 30 * cup; water = 70 * cup;
    return { espresso, water };
  }

  return {};
}

export function isValidCoffee(name) {
  return ['espresso', 'americano', 'mocha'].includes(name);
}

Statement coverage measures the percentage of statements in your code that your tests execute. At first glance, you might wonder, “isn’t this the same as line coverage?” Indeed, statement coverage is similar to line coverage but takes into account single lines of code that contain multiple statements.

In the code example, there are eight lines of executable code, but there are nine statements. Can you spot the line containing two statements?

Check your answer

It's the following line: `espresso = 30 * cup; water = 70 * cup;`

The tests cover only five of the nine statements, therefore the statement coverage is 55.55%.

If you always write one statement per line, your line coverage will be similar to your statement coverage.

What type of code coverage should you choose? #

Most code coverage tools include these four types of common code coverage. Choosing which code coverage metric to prioritize depends on specific project requirements, development practices, and testing goals.

In general, statement coverage is a good starting point because it is a simple and easy-to-understand metric. Unlike statement coverage, branch coverage and function coverage measure whether tests call a condition (branch) or a function. Therefore, they are a natural progression after statement coverage.

Once you have achieved high statement coverage, you can then move on to branch coverage and function coverage.

Is test coverage the same as code coverage? #

No. Test coverage and code coverage are often confused but they are different:

Test coverage: A qualitative metric that measures how well the test suite covers the features of the software. It helps determine the level of risk involved.
Code coverage: A quantitative metric that measures the proportion of code executed during testing. It is about how much code the tests cover.

Here is a simplified analogy: imagine a web application as a house.

Test coverage measures how well the tests cover the rooms in the house.
Code coverage measures how much of the house the tests have walked through.

100% code coverage doesn’t mean no bugs #

While it is certainly desirable to achieve high code coverage in testing, 100% code coverage doesn’t guarantee the absence of bugs or flaws in your code.

A meaningless way to achieve 100% code coverage #

Consider the following test:

/* coffee.test.js */

// ...
describe('Warning: Do not do this', () => {
  it('is meaningless', () => { 
    calcCoffeeIngredient('espresso', 2);
    calcCoffeeIngredient('americano');
    calcCoffeeIngredient('unknown');
    isValidCoffee('mocha');
    expect(true).toBe(true); // not meaningful assertion
  });
});

This test achieves 100% function, line, branch, and statement coverage, but it doesn’t make sense because it doesn’t actually test the code. The expect(true).toBe(true) assertion will always pass regardless of whether the code works correctly.

A bad metric is worse than no metric #

A bad metric can give you a false sense of security, which is worse than having no metric at all. For example, if you have a test suite that achieves 100% code coverage but the tests are all meaningless, then you may get a false sense of security that your code is well tested. If you accidentally delete or break a part of the application code, the tests will still pass, even though the application no longer works correctly.

To avoid this scenario:

Test review. Write and review tests to make sure they are meaningful and test the code in a variety of different scenarios.
Use code coverage as a guideline, not as the only measure of test effectiveness or code quality.

Using code coverage in different types of testing #

Let’s take a closer look at how you can use code coverage with the three common types of test:

Unit tests. They are the best test type for gathering code coverage because they are designed to cover multiple small scenarios and testing paths.
Integration tests. They can help collect code coverage for integration tests, but use them with caution. In this case, you calculate the coverage of a larger portion of the source code, and it can be difficult to determine which tests actually cover which parts of the code. Nonetheless, calculating code coverage of integration tests may be useful for legacy systems that don’t have well-isolated units.
End-to-end (E2E) tests. Measuring code coverage for E2E tests is difficult and challenging due to the intricate nature of these tests. Instead of using code coverage, requirement coverage might be the better way to go. This is because the focus of E2E tests is to cover the requirements of your test, not to focus on the source code.

Conclusion #

Code coverage can be a useful metric for measuring the effectiveness of your tests. It can help you to improve the quality of your application by ensuring that the crucial logic in your code is well tested.

However, remember that code coverage is just one metric. Make sure to also consider other factors, such as the quality of your tests and your application requirements.

Aiming for 100% code coverage is not the goal. Instead, you should use code coverage along with a well-rounded testing plan that incorporates a variety of testing methods, including unit tests, integration tests, end-to-end tests, and manual tests.

See the full code example and tests with good code coverage. You can also run the code and tests with this live demo.

/* coffee.js - a complete example */

export function calcCoffeeIngredient(coffeeName, cup = 1) {
  if (!isValidCoffee(coffeeName)) return {};

  let espresso, water;

  if (coffeeName === 'espresso') {
    espresso = 30 * cup;
    return { espresso };
  }

  if (coffeeName === 'americano') {
    espresso = 30 * cup; water = 70 * cup;
    return { espresso, water };
  }

  throw new Error (`${coffeeName} not found`);
}

function isValidCoffee(name) {
  return ['espresso', 'americano', 'mocha'].includes(name);
}

/* coffee.test.js - a complete test suite */

import { describe, expect, it } from 'vitest';
import { calcCoffeeIngredient } from '../src/coffee-complete';

describe('Coffee', () => {
  it('should have espresso', () => {
    const result = calcCoffeeIngredient('espresso', 2);
    expect(result).to.deep.equal({ espresso: 60 });
  });

  it('should have americano', () => {
    const result = calcCoffeeIngredient('americano');
    expect(result.espresso).to.equal(30);
    expect(result.water).to.equal(70);
  });

  it('should throw error', () => {
    const func = () => calcCoffeeIngredient('mocha');
    expect(func).toThrowError(new Error('mocha not found'));
  });

  it('should have nothing', () => {
    const result = calcCoffeeIngredient('unknown')
    expect(result).to.deep.equal({});
  });
});

How prefetching helped Terra increase ads click-through rate by 30% and speed up Largest Contentful Paint.

2023-09-01T00:00:00Z

Prefetching is a technique used to speed up page loading by downloading resources—or even entire pages—which are likely to be needed in the near future. Research has shown that faster load times result in higher conversion rates and better user experiences.

Terra is one of the largest content portals from Brazil, offering entertainment, news, and sports with more than 63 million unique visitors per month. We’ve collaborated with Terra’s engineering team to improve the loading time of articles by using prefetching techniques on certain sections of their website.

This case study describes Terra’s journey implementation which resulted in a 11% ads click-through rate (CTR) increase on mobile, 30% ads CTR on desktop, and 50% reduction in the Largest Contentful Paint (LCP) times.

Prefetching strategy #

Prefetching has been around for a while, but it is important to use it carefully as it consumes extra bandwidth for resources that are not immediately necessary. This technique should be applied thoughtfully to avoid unnecessary data usage. In the case of Terra, articles are prefetched if the following conditions are met:

Visibility of links to prefetched articles: Terra used the Intersection Observer API to detect viewability of the section containing the articles that they wanted to prefetch.
Favorable conditions for increased data usage: As mentioned previously, prefetching is a speculative performance improvement that consumes extra data, and that may not be a desirable outcome in every situation. To reduce the likelihood of wasting bandwidth, Terra uses the Network Information API along with the Device Memory API to determine whether to fetch the next article. Terra only fetches the next article when:
- The connection speed is at least 3G and the device has at least 4GB of memory,
- or if the device is running iOS.
CPU idle: Finally, Terra checks if the CPU is idle and able to perform extra work by using requestIdleCallback, which takes a callback to be processed when the main thread is idle, or by a specific (optional) deadline—whichever comes first.

Adhering to these conditions ensures that Terra only fetches data when necessary, which saves bandwidth and battery life, and minimizes the impact of prefetches that end up going unused.

When these conditions are met, Terra prefetches the articles present in the sections: "Related Content" and "Recommended for you" highlighted in blue below.

Business Impact #

In order to measure the impact of this technique, Terra first launched this feature in the "Related content" section of the article page. A UTM code helped them to differentiate between prefetched and non-prefetched articles for comparison purposes. After two weeks of successful A/B testing, Terra decided to add the prefetching functionality to the "Recommended for you" section.

As a result of prefetching articles, an overall increase of ads metrics and a reduction of LCP and Time to First Byte (TTFB) times were observed:

Metric	Mobile	Desktop
Ads CTR	+11%	+30%
Ads viewability	+10.5%	+6%
LCP	-51%	-73%
TTFB	-83%	-84%

Prefetching—when used with care—greatly improves page load time, increases ads metrics, and reduces LCP time.

Technical details #

Prefetching can be achieved through the use of resource hints such as rel=prefetch or rel=preload, via libraries such as quicklink or Guess.js, or using the newer Speculation Rules API. Terra has chosen to implement this by using the fetch API with a low priority in combination with an Intersection Observer instance. Terra made this choice as it allows them to support Safari, which doesn't yet support other prefetching methods like rel=prefetch or the Speculation Rules API, and a full-featured JavaScript library wasn't necessary for Terra's needs.

The below JavaScript is approximately equivalent to the code used by Terra:

function prefetch(nodeLists) {
  // Exclude slow ECTs < 3g
  if (navigator.connection &&
    (navigator.connection.effectiveType === 'slow-2g'
      || navigator.connection.effectiveType === '2g')
  ) {
    return;
  }

  // Exclude low end device which is device with memory <= 2GB
  if (navigator.deviceMemory && navigator.deviceMemory <= 2) {
    return;
  }

  const fetchLinkList = {};

  const observer = new IntersectionObserver(function (entries) {
    entries.forEach(function (entry) {
      if (entry.isIntersecting) {
        if (!fetchLinkList[entry.target.href]) {
          fetchLinkList[entry.target.href] = true;

          fetch(entry.target, {
            priority: 'low'
          });
        }

        observer.unobserve(entry = entry.target);
      }
    });
  });
}

const idleCallback = window.requestIdleCallback || function (cb) {
  let start = Date.now();

  return setTimeout(function () {
    cb({
      didTimeout: false,
      timeRemaining: function () {
        return Math.max(0, 50 - (Date.now() - start));
      }
    });
  }, 1);
}

idleCallback(function () {
  prefetch(nodeLists)
})

The prefetch function first checks for a minimum connection quality and device memory before initiating prefetching.
Then it uses an IntersectionObserver to monitor when elements become visible in the viewport, and subsequently adds URLs to a list for prefetching.
The prefetch process is scheduled with requestIdleCallback, aiming to execute the prefetch function when the main thread is idle.

Conclusion #

When used with care, prefetching can significantly reduce load times for future navigation requests, thereby reducing friction in the user journey and increasing engagement. Prefetching results in loading of extra bytes that may not be used, so Terra took extra steps to only prefetch under good network conditions and on capable devices, where this information is available.

Special thanks to Gilberto Cocchi, Harry Theodoulou, Miguel Carlos Martínez Díaz, Barry Pollard, Jeremy Wagner, and Leonardo Bellini and Lucca Paradeda from Terra's Engineering team for their contribution to this work.

New to the web platform in August

2023-08-31T00:00:00Z

Stable browser releases #

In August 2023 Firefox 116, Firefox 117, Safari 16.6, and Chrome 116 became stable. This post takes a look at what that means for the web platform.

Firefox 116 supports the Audio Output Devices API on all platforms except for Android. This API allows web applications to redirect audio output to a permitted Bluetooth headset, speakerphone, or other device, instead of having to use the browser or underlying OS default.

Browser support

Chrome, Not supported
Firefox preview, Preview
Edge, Not supported
Safari, Not supported

Source

Chrome 116 includes CSS Motion Path allowing any graphical object to be animated it along a path specified by the developer. This allows a number of powerful new transform possibilities, such as positioning using polar coordinates (with the ray() function) rather than the standard rectangular coordinates used by the translate() function, or animating an element along a defined path. This makes it easier to define complex and beautiful 2d spatial transitions. A path can be specified as circle(), ellipse(), rect(), inset(), xywh(), polygon(), ray() and url().

Browser support

Chrome, Not supported
Firefox, Not supported
Edge, Not supported
Safari, Not supported

Also in Chrome 116 is the Document Picture-in-Picture API. This enables an always-on-top window that can be populated with arbitrary HTMLElements. This is an expansion upon the existing HTMLVideoElement API that only allows for an HTMLVideoElement to be put into a Picture-in-Picture (PiP) window.

Browser support

Chrome, Not supported
Firefox, Not supported
Edge, Not supported
Safari, Not supported

Firefox 117 supports CSS Nesting and the & nesting selector. This enables the nesting of one style rule inside another. This makes CSS Nesting interoperable with a caveat, Safari and Chrome implemented an older version of the spec, which did not allow nesting of type selectors. Firefox has implemented the new version of the spec which does not require the & nesting selector. You can see examples of both versions in Using CSS Nesting.

Browser support

Chrome 112, Supported 112
Firefox, Not supported
Edge 112, Supported 112
Safari 16.5, Supported 16.5

Source

Beta browser releases #

Beta browser versions give you a preview of things that will be in the next stable version of the browser. It's a great time to test new features, or removals, that could impact your site before the world gets that release. New betas are Firefox 118 and Chrome 117. The Safari 17 beta is still ongoing. These releases bring many great features to the platform. Check out the release notes for all of the details, here are just a few highlights.

There's not a lot of information available as yet for the next Firefox release. However, Chrome 117 promises some exciting features. For example, some new CSS features that enable entry and exit animations.

The subgrid value for grid-template-columns and grid-template-rows is included in Chrome 117, making this longed for feature interoperable.

Also in Chrome 117 is JavaScript array grouping with the Object.groupBy and Map.groupBy static methods.

Safari 17 beta includes the popover attribute, to add support for the Popover API.

Photo by Courtney Cook.

To test or not to test, a technical perspective

2023-08-23T00:00:00Z

The previous article covered the basics of test cases and what they should contain. This article delves deeper into the creation of test cases from a technical perspective, detailing what should be included in each test and what to avoid. Essentially, you'll learn the answer to the age-old questions of "What to test" or "What not to test".

General guidelines and patterns #

It's worth noting that specific patterns and points are crucial, regardless of whether you're conducting unit, integration, or end-to-end tests. These principles can and should be applied to both types of testing, so they are a good place to start.

Keep it simple #

When it comes to writing tests, one of the most important things to remember is to keep it simple. It's important to consider the brain's capacity. The main production code takes up significant space, leaving little room for additional complexity. This is especially true for testing.

If there's less headspace available, you may become more relaxed in your testing efforts. That's why it's crucial to prioritize simplicity in testing. In fact, Yoni Goldberg's JavaScript testing best practices emphasize the importance of the Golden Rule—your test should feel like an assistant and not like a complex mathematical formula. In other words, you should be able to understand your test's intent at first glance.

You should aim for simplicity in all types of tests, regardless of their complexity. In fact, the more complex a test is, the more critical it is to simplify it. One way to achieve this is through a flat test design, where tests are kept as simple as possible, and to only test what is necessary. This means each test should contain only one test case, and the test case should be focused on testing a single, specific functionality or feature.

Think about it from this perspective: it should be easy to identify what went wrong when reading a failing test. This is why keeping tests simple and easy to understand is important. Doing so lets you quickly identify and fix issues when they arise.

Test what's worth it #

The flat test design also encourages focus and helps ensure your tests are meaningful. Remember, you don't want to create tests just for the sake of coverage—they should always have a purpose.

Don't test implementation details #

One common problem in testing is that tests are often designed to test implementation details, such as using selectors in components or end-to-end tests. Implementation details refer to things that users of your code will not typically use, see, or even know about. This can lead to two major problems in tests: false negatives and false positives.

False negatives occur when a test fails, even though the tested code is correct. This can happen when the implementation details change due to a refactoring of the application code. On the other hand, false positives occur when a test passes, even though the code being tested is incorrect.

One solution to this problem is to consider the different types of users you have. End users and developers can differ in their approach, and they may interact with the code differently. When planning tests, it is essential to consider what users will see or interact with, and make the tests dependent on those things instead of the implementation details.

For example, choosing selectors that are less prone to change can make tests more reliable: data-attributes instead of CSS selectors. For more details, refer to Kent C. Dodds' article on this topic, or stay tuned—an article on this topic is coming later.

Mocking: Don't lose control #

Mocking is a broad concept used in unit testing and sometimes in integration testing. It involves creating fake data or components to simulate dependencies that have complete control over the application. This allows for isolated testing.

Using mocks in your tests can improve predictability, separation of concerns, and performance. And, if you need to conduct a test that requires human involvement (such as passport verification), you'll have to conceal it using a mock. For all these reasons, mocks are a valuable tool to consider.

At the same time, mocking may affect the accuracy of the test because they are mocks, not the real user experiences. So you need to be mindful when using mocks and stubs.

Should you mock in end-to-end tests? #

In general, no. However, mocking can be a lifesaver sometimes—so let's not rule it out completely.

Imagine this scenario: you're writing a test for a feature involving a third-party payment provider service. You're in a sandbox environment that they have provided, meaning no real transactions are taking place. Unfortunately, the sandbox is malfunctioning, thereby causing your tests to fail. The fix needs to be done by the payment provider. All you can do is wait for the issue to be resolved by the provider.

In this case, it might be more beneficial to lessen the dependency on services you cannot control. It's still advisable to use mocking carefully in integration or end-to-end tests as it decreases the confidence level of your tests.

Test specifics: Dos and don'ts #

So, all in all, what does a test contain? And are there differences between the testing types? Let's take a closer look at some specific aspects tailored to the main testing types.

What belongs to a good unit test? #

An ideal and effective unit test should:

Concentrate on specific aspects.
Operate independently.
Encompass small-scale scenarios.
Use descriptive names.
Follow the AAA pattern if applicable.
Guarantee comprehensive test coverage.

Do ✅	Don't ❌
Keep the tests as small as possible. Test one thing per test case.	Write tests over large units.
Always keep tests isolated and mock the things you need which are outside your unit.	Include other components or services.
Keep tests independent.	Rely on previous tests or share test data.
Cover different scenarios and paths.	Limit yourself to the happy path or negative tests at maximum.
Use descriptive test titles, so you can immediately see what your test is about.	Test by function name only, not being descriptive enough as a result: `testBuildFoo()` or `testGetId()`.
Aim for good code coverage or a broader range of test cases, especially at this stage.	Test from every class down to database (I/O) level.

What belongs to a good integration test? #

An ideal integration test shares some criteria with unit tests, too. However, there are a couple of additional points that you need to consider. A great integration test should:

Simulate interactions between components.
Cover real-world scenarios, and use mocks or stubs.
Consider performance.

Do ✅	Don't ❌
Test the integration points: verify that each unit works together gracefully when integrated with each other.	Test each unit in isolation—that's what unit tests are for.
Test real-world scenarios: use test data derived from real-world data.	Use repetitive auto-generated test data or other data which doesn't reflect real-world use cases.
Use mocks and stubs for external dependencies to maintain control of your complete test.	Create dependencies on third-party services, for example, network requests to outside services.
Use a clean-up routine before and after each test.	Forget to use clean-up measures inside your tests, otherwise this can lead to test failures or false positives, due to lack of proper test isolation.

What belongs to a good end-to-end test? #

A comprehensive end-to-end test should:

Replicate user interactions.
Encompass vital scenarios.
Span multiple layers.
Manage asynchronous operations.
Verify results.
Account for performance.

Do ✅	Don't ❌
Use API-driven shortcuts. Learn more.	Use UI interactions for every step, including the `beforeEach` hook.
Use a clean-up routine before each test. Take even more care of test isolation than you do in unit and integration tests because there's a higher risk of side effects here.	Forget to clean up after each test. If you don't clean up the leftover state, data or side effects, they will affect other tests executed later.
Regard end-to-end tests as system tests. This means you need to test the whole application stack.	Test each unit in isolation—that's what unit tests are for.
Use minimal or no mocking inside the test. Consider carefully if you want to mock external dependencies.	Rely heavily on mocks.
Consider performance and workload by, for example, not over-testing large scenarios in the same test.	Cover large workflows without using shortcuts.

Defining test cases and priorities

2023-08-09T00:00:00Z

In the previous post, you learned about testing strategies, the number of tests needed to test an application, and how to find the best fit to gain the most confidence in the results while bearing in mind your resources. However, this only gives us an idea of how much to test. You still need to determine exactly what to test. The following three criteria can be helpful in understanding what to expect in a test and to see what testing type and level of detail might fit best:

Take care of your happy path. This is the most generic or primary user story of your application, where your user will notice an error very quickly.
Decide carefully on the level of detail. Get into more detail if your use case is vulnerable or where an error would cause high damage.
Prioritize lower-level tests, such as unit and integration tests, over higher-level end-to-end tests whenever possible.

The rest of this article explores these criteria, and how they apply as you define test cases.

What is a test case? #

In software development, a test case is a sequence of actions or circumstances that are devised to confirm the effectiveness of a software program or application. A test case aims to ensure that the software operates as planned and that all its features and functions perform correctly. Software testers or developers typically create these test cases to guarantee that the software meets the specified requirements and specifications.

When a test case is run, the software performs a series of checks to ensure it produces the desired results. While doing that, a test fulfills the following tasks:

Verification. The process of thoroughly checking software to ensure it functions without errors. Determining whether the created product meets all the necessary non-functional requirements and successfully achieves its intended purpose is crucial. The question it answers is: “Are we building the product right?”
Validation. The process of ensuring that the software product meets the necessary standards or high-level requirements. It involves checking whether the actual product aligns with the expected product. Essentially, we’re answering the question: “Are we building the right product for the user’s requirements?”

Suppose the program fails to deliver the expected outcome. In that case, the test case will be the messenger—thus reporting an unsuccessful result, and the developer or tester will need to investigate the issue and find a solution. Think of the checks and actions as paths the computer follows, regardless of the testing type. Groups of input data or conditions used for checking are called "equivalence classes". They should get similar behavior or results from the system under test. The specific paths executed inside a test may vary but should match the activities and assertions done in your test.

Test paths: Typical kinds of test cases #

In software development, a test case is a code execution scenario from which a certain behavior is expected and tested. Typically, there are three scenarios to form test cases from.

The first one is the most well known, which you are probably already using. It’s the happy path, also known as the “happy day scenario” or “golden path”. It defines the most common use case of your feature, application, or change—the way it should work out for the customer.

The second most crucial test path to cover in your test cases is often left out as it’s uncomfortable—as its name may imply. It’s the “scary path” or, in other words, the negative test. This path targets scenarios that cause the code to misbehave or enter an error state. Testing these scenarios is especially important if you have highly vulnerable use cases imposing a high risk on the stakeholders or users.

There are some other paths you might want to know about and consider using, but typically they are less commonly used. The following table summarizes them:

Test path	Explanation
Angry path	This leads to an error, but an expected one; for example, if you want to ensure error handling works correctly.
Delinquent path	This path takes care of any security-related scenarios your application needs to fulfill.
Desolate path	The path testing the scenario in your application doesn’t get enough data to function, for example, testing null values.
Forgetful path	Testing the behavior of your application with insufficient resources, for example, triggering a data loss.
Indecisive path	Testing with a user who is trying to do actions or following user stories in your application but hasn’t completed those workflows. This could be the case, for example, when the user interrupts their workflow.
Greedy path	Trying to test using vast amounts of inputs or data.
Stressful path	Trying to put a load on your application by any means necessary until it no longer functions (similar to a load test).

There are several methods to categorize those paths. Two common approaches are:

Equivalence partitioning. A testing method that categorizes test cases into groups or partitions and, as a result, helps create equivalence classes. This is based on the idea that if one test case in a partition uncovers a defect, other test cases in the same partition will likely reveal similar defects. As all inputs within a specific equivalence class should exhibit identical behavior, you can decrease the number of test cases. Learn more about equivalence partitioning.
Limit analysis. A testing method, also known as boundary-value analysis, that examines the limits or extremes of input values to find any potential issues or errors that might arise at the system's limits of capabilities or constraints.

Best practice: Writing test cases #

A classical test case written by a tester will contain specific data to help you grasp the content of the test you want to conduct and, of course, execute the test. A typical tester would document their testing efforts in a table. There are two patterns we can use at this stage, helping us to structure our test cases and later, our tests themselves, too:

Arrange, act, assert pattern. The "arrange, act, assert" (also known as the "AAA" or "Triple A") testing pattern is a way of organizing tests into three distinct steps: arranging the test, then performing the test, and last but not least, drawing conclusions.
Given, when, then pattern. This pattern is similar to the AAA pattern but has some roots in behavior-driven development.

Future articles will go into more details on these patterns, as soon as we cover the structure of a test itself. If you want to go deeper into these patterns at this stage, check out these two articles: Arrange-Act-Assert: A pattern for writing good tests and Given-When-Then.

According to all the learnings from this article, the following table summarizes a classic example:

Information	Explanation
Prerequisites	Everything which needs to be done before writing the test.
Object under test	What needs to be verified?
Input data	Variables and their values.
Steps to be executed	All the things you will do to bring your test to life: all actions or interactions you do in your tests.
Expected result	What should happen and which expectations are to be fulfilled.
Actual result	What actually happens.

In automated testing, you don’t need to document all these test cases in the way that a tester needs to, even though it’s undoubtedly helpful to do so. You can find all this information in your test if you pay attention. So let’s translate this classical test case into an automated test.

Information	Translation into test automation
Prerequisites	All the things you need, arranging the test, and thinking about what is given to make your test’s scenario happen.
Object under test	This “object” can be various things: an application, flow, unit, or component under test.
Input data	Parameter values.
Steps to be executed	All the actions and commands executed inside your test, the things you act upon, and finding out what happens when you do certain things.
Expected result	The assertion you use to validate your application, the things you assert upon in your application.
Actual result	The result of your automated test.

New to the web platform in July

2023-07-31T00:00:00Z

Stable browser releases #

In July 2023 Firefox 115 and Chrome 115 became stable. This post takes a look at what that means for the web platform.

Multiple values for the CSS `display` property #

Chrome 115 includes multiple values for the CSS display property. This means that display: flex becomes display: block flex and display: block becomes display: block flow. The single values are maintained as legacy keywords, these values are now available in the three major engines.

Browser support

Chrome 115, Supported 115
Firefox 70, Supported 70
Edge 115, Supported 115
Safari 15, Supported 15

Scroll-driven animations #

Also in Chrome 115 are the ScrollTimeline and ViewTimeline extensions to the Web Animations specification. These enable scroll-driven animations via CSS and JavaScript.

Browser support

Chrome 115, Supported 115
Firefox, Not supported
Edge 115, Supported 115
Safari, Not supported

Source

Privacy Sandbox APIs #

The Privacy Sandbox relevance and measurement APIs shipped in Chrome 115. This includes the Topics, Protected Audience, Attribution Reporting, Private Aggregation, Shared Storage, and Fenced Frames APIs.

To understand more about these APIs check out the Privacy Sandbox demos.

The `animation-composition` property #

Firefox 115 supports the CSS animation-composition property. Making animation-composition supported in all three major engines. Learn more in the article Specify how multiple animation effects should composite with animation-composition.

Browser support

Chrome 112, Supported 112
Firefox 115, Supported 115
Edge 112, Supported 112
Safari 16, Supported 16

Source

Array methods #

Also reaching interoperability with Firefox 115 are a set of methods for Array and TypedArray. Array.toReversed(), Array.toSorted(), Array.toSpliced(), Array.with(), TypedArrays.toReversed(), TypedArrays.toSorted(), and TypedArrays.with() return a new array with elements that have been shallow copied.

Browser support

Chrome 110, Supported 110
Firefox 115, Supported 115
Edge 110, Supported 110
Safari 16, Supported 16

Source

Beta browser releases #

Beta browser versions give you a preview of things that will be in the next stable version of the browser. It's a great time to test new features, or removals, that could impact your site before the world gets that release. New betas are Firefox 116 and Chrome 116. The Safari 17 and Safari 16.6 betas are still ongoing. These releases bring many great features to the platform. Check out the release notes for all of the details, here are just a few highlights.

Photo by Jason Leung.

Adapting typography to user preferences with CSS

2023-07-27T00:00:00Z

Bringing the user into the design process has been an exciting time for users, designers and developers. Users can land on your experience and seamlessly begin consuming content, their preferences richly integrated into the design result.

This blog post explores using CSS media queries with a variable font to tailor the reading experience even further. Font grade and weight can be customized with font-variation-settings, allowing microtuning given various preferences and contexts, like a preference for dark mode or high contrast. We can take these preferences and tailor a variable font for that user experience.

Dark mode gets a slightly reduced gradation.
High contrast gets a bolder font.
Low contrast gets a thinner font.

https://codepen.io/argyleink/pen/mdQrqvj

Follow along to understand each portion of the CSS and variable font that enable this meaningful moment!

Getting setup #

To help focus on the CSS and font variation setting values, but also give us something to read and see, here's the markup you can use to preview the work:

<h1>Variable font weight based on contrast preference</h1>

<p>
  Lorem ipsum dolor sit amet consectetur adipisicing elit.
  Officia, quod? Quidem, nemo aliquam, magnam rerum distinctio
  itaque nisi nam, cupiditate dolorum ad sint. Soluta nemo
  labore aliquid ex, dicta corporis.
</p>

Without adding any CSS, the font size is already adaptive to user preferences. Here's a video from another demo showing how setting font-size in pixels will squash any user preferences, and why you should set your font size in rems:

Lastly, to center and support the demo, a little CSS:

@layer demo.support {
  body {
    display: grid;
    place-content: center;
    padding: var(--size-5);
    gap: var(--size-5);
  }

  h1 {
    text-wrap: balance;
  }
}

This demo setup lets you begin testing and implementing this neat typography UX feature.

Loading the Roboto Flex variable font #

The adaptive strategy depends on a variable font with meaningful axes for customization, specifically you need GRAD and wght. The target adaptive user preferences in this article are for color scheme and contrast, both of which will tailor these axes to match the user's desired preference.

Load the variable font using the @font-face API of CSS:

@font-face {
  font-family: "Roboto Flex";
  src: url('https://assets.codepen.io/2585/RobotoFlex') format('truetype');
}

Next, apply the font to some content. The following CSS applies it to everything:

@layer demo.support {
  body {
    font-family: Roboto Flex;
  }
}

CSS custom properties and media queries for the win #

With the font loaded, you can query for user preferences and adapt the variable font settings to match.

Settings when there's no preferences (default) #

The following initial styles will be the default styles, or another way to look at it, the styles for users without any preferences.

@layer demo {
  body {
    --base-weight: 400;
    --base-grade: 0;

    font-variation-settings:
      "wght" var(--base-weight),
      "GRAD" var(--base-grade)
    ;
  }
}

Settings when the preference is for high contrast #

For users who have indicated a preference for high contrast in their system settings, increase the --base-weight value from 400 to 700:

@layer demo {
  @media (prefers-contrast: more) {
    body {
      --base-weight: 700;
    }
  }
}

Now there's more contrast while reading.

Settings when the preference is for low contrast #

For users who have indicated a preference for low contrast in their system settings, decrease the --base-weight value from 400 to 200:

@layer demo {
  @media (prefers-contrast: less) {
    body {
      --base-weight: 200;
    }
  }
}

Now there's less contrast while reading.

Settings when the preference is for dark mode #

@layer demo {
  @media (prefers-color-scheme: dark) {
    body {
      --base-grade: -25;
    }
  }
}

Now the perceptual differences of light on dark vs dark on light have been accounted for.

All together now #

@layer demo {
  body {
    --base-weight: 400;
    --base-grade: 0;

    font-variation-settings:
      "wght" var(--base-weight),
      "GRAD" var(--base-grade)
    ;
  }

  @media (prefers-contrast: more) {
    body {
      --base-weight: 700;
    }
  }

  @media (prefers-contrast: less) {
    body {
      --base-weight: 200;
    }
  }

  @media (prefers-color-scheme: dark) {
    body {
      --base-grade: -25;
    }
  }
}

Or, for fun, all together with CSS nesting:

@layer demo {
  body {
    --base-weight: 400;
    --base-grade: 0;

    font-variation-settings:
      "wght" var(--base-weight),
      "GRAD" var(--base-grade)
    ;

    @media (prefers-contrast: more)     { --base-weight: 700 }
    @media (prefers-contrast: less)     { --base-weight: 200 }
    @media (prefers-color-scheme: dark) { --base-grade: -25 }
  }
}

The result is a reading experience that adapts the font to match the user's preferences. Full source code is available below in the Codepen.

See the Pen Pen rNQZMzo by web-dot-dev on Codepen

Designing the user experience of passkeys on Google accounts

2023-07-26T00:00:00Z

Passkeys are a simple and secure cross-device authentication technology that enables creating online accounts and signing in to them without entering a password. To log in to an account, users are simply shown a prompt to to use the screen lock on their device, such as touching the fingerprint sensor.

Google has been working with the FIDO Alliance for years, alongside Apple and Microsoft, to bring passkeys to the world. In 2022 we rolled out platform support for passkeys so that Android and Chrome users can seamlessly sign in to apps and websites across all their devices. In May 2023, we enabled signing in to Google Accounts with passkeys, bringing the security and convenience of passkeys to our users.

Google is in a unique position, as we are both working on the infrastructure for passkeys and are one of the largest services using them. We are rolling out passkeys for Google Accounts carefully and deliberately, so we can measure the results and use that feedback to continue to improve the passkey infrastructure and the Google account experience.

Transitioning users to passkeys #

Passwords have been the standard sign-in method since the advent of personalized online experiences. How do we introduce the passwordless experience of passkeys?

Research indicates that when it comes to authentication, users value the convenience the most. They want a smooth and fast transition to the real experience, which only comes after signing in.

Still, the transition to passkeys requires changing muscle memory and users need to be convinced it's worth making a switch.

The user experience of passkeys for Google.com has been strategically designed to emphasize two principles at every step of the authentication process: ease of use and security.

Leading with convenience #

For most users, this will be the first time they see passkeys.

The first passkey screen users see is light and easy-to-digest. The header is focusing on the user benefit, saying "Simplify your sign in."

The body copy explains "With passkeys you can now use your fingerprint, face or screen lock to verify it's really you".

The illustration is intended to ground the message in the value proposition made by the page. The large blue primary action invites the user to proceed. "Not now" is included as a secondary action to allow users to choose whether or not to opt in at this time, leaving the user in control. And "Learn more" is offered for the most curious users who would like to understand passkeys better before proceeding.

We explored many iterations of the pages used to introduce users to passkeys during sign in. This included trying content that emphasized the security, technology, and other aspects of passkeys—yet convenience was really what resonated most. Google's content strategy, illustration, and interaction design demonstrates this core principle for our implementation of passkeys.

Associating the term "passkeys" with familiar security experiences #

Passkeys are a new term for most users so we are intentionally gently exposing the users to the term to build familiarity. Guided by internal research, we are strategically associating passkeys with security.

The word "passkey" is included throughout the sign-in flow in the less-prominent body copy position. It's consistently nestled amongst the familiar security experiences that enable passkey use: fingerprint, face scan, or other device screen lock.

Our research has shown that many users associate biometrics with security. While passkeys don't require biometrics (a passkey can be used with a device PIN, for example), we are leaning into the association of passkeys with biometrics to boost user perception of passkeys' security benefits.

The additional content behind the "Learn more" has lots of valuable information for users, including reassurance for users that their sensitive, biometric data stays on their personal device and is never stored or shared when creating or using passkeys. We took this approach because most users found the convenience aspect of passkeys appealing, but only a few took into account the biometric element during testing.

Introducing passkeys when it's relevant to the user #

Google's heuristics carefully determine who will see the introductory screen. Some of the factors are whether a user has two-step verification enabled and whether they access that account regularly from the same device.

Users who are most likely to succeed with passkeys are selected first, and over time more users will be introduced (though, anyone can get started at g.co/passkeys today).

Select users are prompted to create a passkey after signing in with a username and password. There are a few reasons we chose this point in the user journey:

The user has just signed in, they're aware of their credentials and second step.
We are confident that the user is on their device–they just signed in, so it's unlikely they walked away or put their device down.
Statistically, signing in isn't always successful the first time–so a message around making it easier next time has tangible value.

Positioning passkeys as an alternative to passwords and not yet a replacement #

Initial user research shows that many users still want passwords as a backup sign-in method. And not all users will have the technology necessary to adopt passkeys.

So while the industry, Google included, is moving towards a "passwordless future", Google is intentionally positioning passkeys as a simple and secure alternative to passwords. Google's UI focuses on the benefits of passkeys and avoids language that implies getting rid of passwords.

The creation moment #

When users choose to enroll, they'll see a browser-specific UI modal that enables them to create a passkey.

The passkey itself is shown with the industry-aligned icon and the information used to create it. This includes the display name (a friendly name for your passkey, like your user's real name) and the username (a unique name on your service–an email address can work great here). When it comes to working with the passkeys icon, the FIDO alliance recommends using the proven passkeys icon–and encourages making it your own with customizations.

Passkeys icon is shown consistently across the user journey to create a familiarity with what the user will see when using or managing the passkey. The passkey icon is never presented without context or supporting material.

When users create their passkey, they'll see this page.

Above, we outlined how the user and the platform work together to create a passkey. When the user clicks "Continue" they'll be presented with a unique UI depending on the platform.

With that in mind, we learned through internal research that a confirmation screen once the passkey is created can be very helpful in terms of comprehension and closure at this step of the process.

Once the passkey has been created, users will see this page.

The confirmation screen is a deliberate ‘pause' to bookend the journey of introducing a user to passkeys and going through the process of creating one of their own. As it is (likely) the first time a user has engaged with passkeys, this page aims to provide clear closure to the journey. We chose a standalone page after trying some other tools like smaller notifications, and even a post-creation email–simply to provide a structured, stable end to end experience.

Once the user clicks "Continue" here, they're brought to their destination.

When users sign in again, they'll likely see this page.

Signing in #

Next time a user tries to sign in, they'll be greeted with this page. This uses the same layout, illustration, and primary call to action to evoke the first ‘creation' experience outlined above. Once the user has made a choice to enroll in passkeys, this page should feel familiar and they will recognize what steps they need to take to sign in.

The user will use this WebAuthn UI to sign in.

The same principle of familiarity applies here. Intentionally, this uses the same iconography, illustration, layout and text. The text within the WebAuthn UI is kept brief, broad, and re-usable–so everyone can use this both for authentication and reauthentication.

Passkeys management #

Introducing a whole new page within the Google Account settings pages required careful consideration to ensure a cohesive, intuitive, and consistent user experience.

To achieve this, we analyzed the patterns regarding navigation, content, hierarchy, structure, and established expectations that existed across the Google Account.

Passkeys management page in the Google Account.

Describe passkeys by ecosystem #

To create a high level category system that would be logical to understand we settled on describing passkeys by ecosystem. This way, a user could recognize where a passkey was created and where it is used. Each identity provider (Google, Apple, and Microsoft) has a name for their ecosystem, so we chose to use those (Google Password Manager, iCloud keychain, and Windows Hello respectively).

To support this, we added additional metadata, such as when it was created, when it was last used, and the specific OS that it was used on. In terms of user management actions, the API only supports renaming, revoking, and creating.

Renaming allows users to assign personally meaningful names to passkeys, which could help particular cohorts of users keep track and understand them more easily.

Revoking a passkey doesn't delete it from the user's personal credential manager (like Google Password Manager), but renders it unusable until it is set up again. That's why we chose a cross, instead of a trash or delete icon, to represent the action of revoking a passkey.

When describing the action of adding a passkey to their account, the phrase "Create passkey" resonated better with users compared to "Add a passkey." This is a subtle language choice to distinguish passkeys from tangible, hardware security keys (though it should be noted that passkeys can be stored on some hardware security keys).

Providing additional content #

Internal research showed that using passkeys is a relatively seamless and familiar experience. However as with any new technology, there are lingering questions and concerns that will come up for some users.

How the technology works behind the screen lock, what makes it more secure, and the most common "what if" scenarios Google came across in testing are addressed in Google's passkey Help Center content. Having support content ready with launch of passkeys is critical for an easy transition for users on any site.

Falling back from passkeys #

Reverting to the old system is as simple as clicking "try another way" when a user is asked to authenticate with a passkey. Additionally, exiting the WebAuthn UI will start users on a path to try their passkey again, or sign into their Google Account in traditional ways.

Conclusion #

We are still in the early days of passkeys, so when designing the user experience keep a few principles in mind:

Introduce passkeys when it's relevant to the user.
Highlight the benefits of passkeys.
Use opportunities to build familiarity the concept of passkeys.
Position passkeys as an alternative to passwords and not a replacement.

The choices we made for passkeys for Google Accounts were informed by best practices and internal research and we'll continue to evolve the user experience as we gain new insights from users in the real world.

Pyramid or Crab? Find a testing strategy that fits

2023-07-26T00:00:00Z

Welcome back! The last article laid down lots of groundwork about how to approach the different testing types and what they contain, and clarified the testing type definitions. Remember this little meme image? You might have wondered how all those testing types you learned about could work together.

Next, you will learn exactly that. This article gives an introduction on how to combine these testing types into reasonable strategies and choose one that matches your project.

You can compare the strategies to a number of shapes to better grasp their meaning. Here's a list of strategies with respective sizes and development scopes.

Application size	Team composition	Reliance on manual testing	Testing strategy
Small	Developers only	High	Testing Ice Cone Testing Crab
Small	Developers & QA engineers	High	Testing Ice Cone Testing Crab
Small	Developers only	Low	Test Pyramid
Large	Developers only	High	Testing Trophy Testing Diamond
Large	Developers & QA engineers	High	Testing Trophy Testing Crab
Large	Developers only	Low	Testing Trophy Testing Honeycomb

Let's take a closer look at the strategies and learn the meaning behind their names.

Determine testing goals: What do you want to achieve with these tests? #

Before you can start building a good strategy, figure out your testing goal. When do you consider that your application has been sufficiently tested?

Achieving high test coverage is often viewed as the ultimate goal for developers when it comes to testing. But is it always the best approach? There might be another critical factor to consider when deciding on a testing strategy—serving your users' needs.

As a developer, you also use many other applications and devices. In this respect, you are the user who relies on all these systems to “just work”. In turn, you rely on countless developers to do their best to make their applications and devices work. To turn this back around, as a developer, you also strive to live up to this trust. So your first goal should always be to ship working software and serve your users. This extends to the tests you write to ensure application quality. Kent C. Dodds sums it up very well in his Static vs Unit vs Integration vs E2E Testing for Frontend Apps post:

The more your tests resemble the way your software is used, the more confidence they can give you.
by Kent C. Dodds

Kent describes it as gaining confidence in tests. The closer you get to the users by choosing a testing type that fits, the more you can trust your tests to have valid results. In other words, the higher up you climb the pyramid, the more confident you get. But wait, what is the pyramid?

Determining test strategies: How to choose a testing strategy #

As a first step, determine which parts of the requirements you need to check to make sure they are met. Find out what test types to use and at what level of detail you can achieve the most confidence while maintaining an efficient cost structure. Many developers approach this topic by using analogies. Here are the most common ones, starting with the well-known classic.

The classic: The test pyramid #

As soon as you start looking for test strategies, you will probably come across the test automation pyramid as the first analogy. Mike Cohn introduced this concept in his book "Succeeding with Agile". Later, Martin Fowler expanded upon the concept in his Practical Test Pyramid article. You can represent the pyramid visually as the following:

As shown in this drawing, the test pyramid consists of three layers:

Unit. You find these tests at the base layer of the pyramid because they are fast to execute and simple to maintain. They are isolated and target the most minor test units. For example, see a typical unit test for a very small product.
Integration. These tests are in the middle of the pyramid, because they have an acceptable execution speed but bring you closer to the user than the unit tests can. An example of an integration test is an API test. You can also classify component tests as this type.
E2E tests (also called UI tests). These tests simulate a genuine user and their interaction. Such tests need more time to execute and thus are more expensive. They are at at the top of the pyramid.

Confidence versus resources #

As briefly covered before, the order of the layers is no coincidence. They show the priorities and the corresponding costs. This gives you a clear picture of how many tests you should write for each layer. You have already seen this in the definition of the testing types.

Because E2E tests are closest to your users, they give you the most confidence that you application is working as intended. However, they require a complete application stack and a simulated user, therefore, they are also potentially the most expensive. So the confidence is in direct competition with the resources you need to execute the tests.

The pyramid tries to solve this problem by making you focus more on unit tests and strictly prioritize the cases covered by E2E tests. For example, your most crucial user journeys or the places most vulnerable to defects. As Martin Fowler emphasizes, the two most essential points in Cohn's pyramid are as follows:

Write tests with different granularity.
The more high level you get, the fewer tests you should have.

Pyramid evolved! Adaptations of the test pyramids #

For several years, discussions have revolved around the pyramid. The pyramid seems to oversimplify testing strategies, leaves out a lot of testing types, and no longer fits all the real-world projects. Therefore, it may be misleading. Has the pyramid fallen out of shape? Guillermo Rauch has an opinion about it:

Write tests. Not too many. Mostly integration.
by Guillermo Rauch

It's one of the most commonly cited quotes on this subject, so let's break it down:

"Write tests". Not only because it builds trust, but also because it saves time in maintenance.
"Not too many". 100% coverage is not always good because then your testing isn't prioritized and there will be a lot of maintenance.
"Mostly integration". Here again the emphasis is on integration tests: they have the most business value by giving you a daily high confidence level while maintaining a reasonable execution time.

This makes you think again about the testing pyramid and shift your focus to integration testing. Over the last few years, many adaptations have been proposed, so let's look at the most common ones.

Test diamond #

The first adaptation removes the overemphasis on unit testing, as seen in the test pyramid. Imagine that you have reached 100% coverage on unit tests. However, the next time you refactor, you will have to update many of these unit tests and you might be tempted to skip them. So they erode.

As a result, and together with the higher focus on integration testing, the following shape may arise:

A pyramid evolves into a diamond. You can see the previous three layers, but with a different size, and the unit layer has been cut:

Unit. Write unit tests the way you defined them before. However, because they tend to erode, prioritize and cover only the most critical cases.
Integration. The integration tests you know, testing the combination of single units.
E2E. This layer handles the UI tests similar to the test pyramid. Take care to only write E2E tests for the most critical test cases.

Testing honeycomb #

There is another adaptation, introduced by Spotify, that is similar to the test diamond but further specialized for microservices-based software systems. The testing honeycomb is another visual analogy for the granularity, scope, and number of tests to write for a microservices-based software system. Due to their small size, the most considerable complexity in a microservice is not within the service itself, but in how it interacts with others. So a testing strategy for a microservice should primarily focus on integration tests.

This shape reminds us of a honeycomb, thus the name. It has the following layers:

Integrated tests. The article by Spotify uses a quote from J. B. Rainsberger to define this layer: “A test that will pass or fail based on the correctness of another system.” Such tests have external dependencies that you need to consider, and on the contrary, your system might be a dependency that breaks other systems. Similar to E2E tests in other analogies, use these tests carefully, only for the most essential cases.
Integration tests. Similar to other adaptations, you should focus on this layer. It contains tests that verify the correctness of your service in a more isolated fashion, but still in combination with other services. That means the tests will include some other systems too and focus on the interaction points, for example, via API tests.
Tests on implementation details. These tests resemble unit tests—tests that focus on parts of the code that are naturally isolated and thus have their own internal complexity.

If you want to find out more about this testing strategy, see the post that compares the test pyramid to the honeycomb by Martin Fowler and the original article from Spotify.

Testing trophy #

You can already see a repeating focus on integration tests. However, another type you came across in the previous article is not testing in theory but is still an important aspect you should consider in a testing strategy. Static analysis is missing from the test pyramid and in most of the adaptations you have seen so far. There's the testing trophy adaptation that takes static analysis into account while maintaining the focus on integration tests. The testing trophy originated from the earlier quote by Guillermo Rauch and was developed by Kent C. Dodds:

The testing trophy is an analogy depicting the granularity of tests in a slightly different way. It has four layers:

Static analysis. It plays a vital role in this analogy and lets you catch typos, style mistakes, and other bugs by merely running the debugging steps already outlined.
Unit tests. They ensure that your smallest unit is appropriately tested, but the testing trophy won't emphasize them to the same extent as the test pyramid.
Integration. This is the main focus as it balances the cost and the higher confidence in the best way, as with other adaptations.
UI tests. Including E2E and visual tests, they are at the top of the testing trophy, similar to their role in the test pyramid.

To read more about the testing trophy, see the blog post by Kent C. Dodds on this subject.

Some more UI-focused approaches #

That's all well and good but no matter how you call your strategy, a “pyramid”, “honeycomb,” or “diamond”, there's still something missing. While test automation is valuable, it's important to remember that manual testing is still essential. Automated testing should alleviate routine tasks and free the quality assurance engineers to focus on crucial areas. Instead of replacing manual testing, automation should complement it. Is there a way to integrate manual testing with automation for optimal results?

Testing ice cone and testing crab #

There are indeed two adaptations of the testing pyramid that focus more on these UI-focused ways of testing. Both have the advantage of high confidence, but are naturally more costly due to slower test execution.

The first one, the test ice cone, looks like the pyramid in reverse. Without the manual testing step, it is also known as the testing pizza.

The ice cone has bigger focus on manual or UI testing and the least focus on unit testing. It often takes shape in projects where developers started work with only a few thoughts on the testing strategy. The ice code is considered an anti-pattern and rightfully so. It is costly in terms of resources and manual work.

The test crab is similar to the test ice cone, but with more emphasis on E2E and visual testing:

This testing strategy includes one more aspect: it verifies that your application functions and looks good. The testing crab highlights the importance of visual testing, defined in the previous article. Integration testing, divided into component and API testing, moves further into the background, and unit testing plays an even more secondary role here. You can find further details on this testing strategy in this article on the testing crab.

While being more costly, these two testing strategies have their place: for example, in smaller projects where fewer tests are needed, or less complexity needs to be covered. In this case, a full-blown testing strategy focusing on integration testing might be over-engineered.

Although these two testing strategies are more costly, they have their place, for example, in smaller projects that require fewer tests and don't need to cover a lot of complexity. In this case, a full scale testing strategy focused on integration testing may be unnecessarily complex.

Practical advice: Let's strategize! #

You have now learned about the most common testing strategies. You started with the classic—the test pyramid—and got to know its many adaptations. Now you need to evaluate them for your product and decide which is be the best for your project. The answer to this question should start with everyone's favorite "It depends". That doesn't make it any less accurate though.

The choice of the most appropriate testing strategy from those described—and even the ones left out—depends on your application. It should fir your architecture, your requirements, and last but not least, your users and their requirements. All this might differ from application to application. That's completely normal. Remember that your most important goal is to serve your users, not a textbook definition.

More often than not, real-world tests are difficult to separate and define individually. Even Martin Fowler himself emphasizes the positive aspect of differing definitions, such as in the case of unit tests. As Justin Searls states correctly in his tweet:

[…] write expressive tests that establish clear boundaries, run quickly & reliably, and only fail for useful reasons.
by Justin Searls

Focus on the tests that report actual errors that the users might encounter, and don't get distracted from your goal. Tests should be designed to benefit the user, not just provide 100% coverage or to debate which percentage of which testing type to write.

Focus on tests that report real-life errors that your users might encounter and don't get distracted from your goal. Tests should be designed to benefit the user, not just provide 100% coverage or spark debates on what percentage of a particular testing type you should write.

How Back/forward Cache Helped Yahoo! JAPAN News Increase Revenue by 9% on Mobile

2023-07-25T00:00:00Z

Back/forward cache (or bfcache) is a browser optimization that enables instant back and forward navigation. It significantly improves the browsing experience for users, especially for websites that involve many back and forth navigations.

web.dev article on bfcache

Yahoo! JAPAN News, one of the most popular news platforms in Japan, drove a concerted effort to improve their bfcache hit rate and saw significant user experience and business improvements as a result. Specifically, the results of the A/B test they conducted showed that pages that use bfcache had a 9% increase in ads revenue.

This case study will explain how Yahoo! JAPAN News removed the blockers for bfcache, and how bfcache drastically improved the user experience.

Removing blockers for bfcache #

bfcache has been available since Chrome 86, and is also available on all modern browsers. However, taking full advantage of bfcache requires removing potential blockers on one's website. Some major blockers that Yahoo! JAPAN News faced were:

Use of unload handlers
Use of the no-store directive on Cache-control headers

You can check what major blockers there are for your website by going to Chrome Dev Tools > Applications > Back/forward Cache (more details), or by using the notRestoredReasons API to get a more comprehensive view of blockers based on actual usage in the field.

Here's how Yahoo! JAPAN News has removed their blockers:

Unload Handlers: Use the pagehide event instead of unload event, as the unload event is very unreliable. Also, permission-policy: unload was launched in Chrome 115 so that the websites can reliably remove unload handlers for specific origins. Chrome is also planning to gradually deprecate unload handlers.
Cache-control: no-store (or CCNS for short): Changing the Cache-control header from no-store to no-cache can enable bfcache. Chrome is also planning to start caching for bfcache even with a no-store header in certain circumstances.

CCNS is intended for pages that should never be cached under any circumstances. This comes with the caveat that any page with CCNS will not be able to benefit from any caching technology, including CDN edge servers and local caches.

If you have a CCNS header, this is a great opportunity to discuss what the right Cache-control strategies are for your website. Here are the main differences between no-store and no-cache.

`Cache-control: no-store`	`Cache-control: no-cache`
The response is not allowed to be stored in caches. Consequently, the response is fetched in full on every request. This should be used for private responses.	The response is allowed to be stored in caches as long as it's revalidated with the server before each use. This should be public responses you want revalidated every time (for example, the home page of a news website - though even then a very short caching time can improve performance and offload work from the main servers).

If you are interested in learning more about Cache-control options, this flowchart is a great help.

Impact of bfcache in numbers #

To measure the impact of bfcache, Yahoo! JAPAN News conducted an A/B test for 2 weeks, where they served a version of their pages with their bfcache fixes to one group, and a version with pages ineligible for bfcache to another. They picked the URL paths with a significant amount of traffic so that the test could achieve meaningful results. There were no other visual or functional difference between the 2 versions.

Here's a video comparing the website with bfcache and without bfcache. You can see that the website with bfcache enabled loads significantly faster during a back or forward navigation.

What's really promising is that the group with bfcache enabled had a significant increase in page views and ads revenue, especially on mobile devices.

Here are details about the impact observed by Yahoo! JAPAN News with their bfcache A/B test. (Further information can be found in their case study article).

Metrics	Uplift % (mobile)	Uplift % (desktop)
bfcache hit rate	+54.03 points (0.04% → 54.07%)	+47.28 points (0.02% → 47.30%)
Page views	+2.26%	+0.65%
Ads revenue	+9.0%	+0.6%

When back/forward navigations between pages become instantaneous with bfcache, users tend to stay on pages longer, thus increasing ad views, leading to an increase of ad revenue.

bfcache enhances seamless user experience on the website #

When pages load instantly, navigations feel more seamless.

In Yahoo! JAPAN News, one of the major user journey is as follows:

Go to the article list
Click on one article to read
Go back to the article list
Click on another article to read

Before bfcache, when users finished reading an article (step 2), they had to wait for the article list page to load again. This could be a friction factor for users who just want to go back to the article list to pick out another article to read.

Another source of friction during backward navigation was the scroll position. In practice, the browser tries to restore the scroll position when a backward navigation happens. However, because of dynamically-added ads or other layout changes, the scroll position often gets incorrectly restored, which could cause users to lose their bearings or even leave the page. This is never an issue when a backward navigation is powered by bfcache: the scroll position is immediately and correctly restored.

Now with bfcache, the friction in the user journey is gone—users can instantly navigate back to the article list page and pick another article to read without having to wait for the article list page to load.

The same thing happens when users browse from one article directly to another and back:

In a nutshell, the benefits of using bfcache for Yahoo! JAPAN News includes:

Increased pageviews: Users were more likely to navigate within the website when pages were cached with bfcache.
Increased revenue: As a result of increased pageviews per session, ads impression increased, which resulted in a 9% increase in revenue on mobile compared with the test group without bfcache.

Conclusion #

In short, bfcache not only makes your website instant, but can also reduce friction in overall user experience and increase engagement within your website.

The Chrome team is continually looking at bfcache blockers—especially the two reasons listed in this article as they are common reasons bfcache is not used. In the future, these may not prevent bfcache usage, but there's no need to wait until then. You can benefit from bfcache by looking at your bfcache blockers and avoiding these common, and other less common, patterns.

Three common types of test automation

2023-07-12T00:00:00Z

We've all been there: what is a recurring coding meme that happens all too often in real life?

This meme sums it up quite nicely: each drawer works perfectly well individually, but in combination with the other drawer, they block each other and fail to function. You want both drawers to work well with each other and be operable at the same time.

Apply this to web development: you wrote some tests, maybe even achieved 100% test coverage, but your application still needs to work once other parts fall into place. The units may work well on their own but not in relation to each other. Writing some tests is crucial but it's only one part of the ideal test setup for your project. As a very first step, you need to determine what parts of the application quality you need to ensure and how you can achieve that.

Simply put, you need a plan before you start writing the actual test code. To approach the topic of how to test practically, let's start with a clean slate and answer two basic questions:

How do you want to test?
What do you want to test?

This article focuses on the general things you need to know to answer the first question. To start from a common ground, let's first learn what testing modes exist and then focus on the common types of testing. In later articles, we will answer the second question, combine the answers, and find the testing strategy that works best for your project. Let's go! 🙌

Start with the basics: General testing modes #

When answering the question of how to test, the first point to clarify is very abstract. Should you test manually or let a computer take over? It's important, however, not to fall into binary thinking here.

Manual testing versus automated testing #

If you ask quality assurance engineers to define testing, they will probably break it down into two "modes" first:

Manual testing. This is a typical testing method conducted by actual people. A quality assurance engineer click through the application, check if it works and, at the same time, try to break it. The most common way is exploratory testing, where the engineer investigates the application using their knowledge of the application against a predefined path or checklist.
Automated testing. This is a type of testing conducted by a computer. Quality assurance engineers implement it to automate away repetitive and monotonous tests.

This series of guides will mostly focus on automated testing. However, you shouldn't focus on only one way of testing. Even if automation saves a lot of time and effort, humans and manual testing will always play a vital role. Rather, test automation should free up people to focus on exploratory testing and creative problem-solving. For example, ensuring the quality of user experiences or protecting the high-risk business logic. In other words, automation has your back. ❤️

Opaque box versus clear box #

So, you have defined the general modes of testing. However, that's not enough yet. To plan the testing strategy, there is one more question to answer: should you know how your application works under the hood or is it better to test without this knowledge? Depending on the answer, there are two procedures to choose from for deriving and selecting test cases:

Opaque box testing (or black box testing). It is based on analyzing a component or system's functional or non-functional requirements (specifications) without considering its internal structure.
Clear box testing (or white box testing) is a procedure that takes into account the internal structure of said box. In other words, how your application works under the hood.

Both procedures can be applied to manual and automated testing. However, some aspects of general testing modes may focus more on one of the two—we will cover that later. For now, let's further break down test automation into types.

Test automation types: How do you want to test? #

As you get closer to answering the "how" question, you have already decided to do some manual testing. However, choosing and applying test automation types is a bit more challenging. The types of automation testing are closely related to the metrics you want to create in your projects. So let's take a closer look at the most important ones.

As illustrated in the meme mentioned earlier, you have already come across two types: unit testing and integration testing. End-to-end testing is the third important one to consider. But that isn't all of them still. Let's take a closer look.

Unit testing #

Unit testing is a testing type in which minor testable parts or units of an application are individually and independently tested for proper operation. These units can vary in scope from functions, classes, or interfaces, to services or complete components. Their primary attributes are execution speed, isolation, and comfortable maintainability. If you want to dive deeper into unit testing, head over to this guide on unit testing.

Integration testing #

Integration testing focuses on interactions between components or systems. In other words, on how well they work together. Typical examples of integration tests are API or component tests.

End-to-end testing #

These tests are often called UI tests and this name explains their function even better. These tests interact with your application's UI, including the complete application stack, and test your application from one end to the other.

They resemble a system test if you refer to the theory of quality assurance. These tests simulate a genuine user and their interactions. End-to-end tests take more runtime because they involve the whole system and more runtime requires more computing power. As a result, this additional effort results in higher maintenance costs.

Visual UI testing #

An interesting subcategory of UI tests is visual tests. These tests are extended end-to-end tests that provide a means to verify the visible output of an application. Such a test takes a screenshot after a change and another screenshot containing the “status quo” (or golden file), then provides those results to a human reviewer to inspect and check. In other words, it helps find “visual bugs” in the appearance of a page, beyond purely functional bugs and not explicitly written down into assertions.

Static analysis #

There's one more thing to introduce here: static analysis. It isn't a testing type in the textbook sense. However, it will be an essential aspect in quality assurance strategies later on. You can imagine it working like a spell check function: it scans your code for more significant defects and syntax errors without running the program, thus detecting code style issues. This simple measure can prevent many bugs. This is a good point to learn about Static Analysis if you want to get to know it in more detail.

Testing in all shapes: How does this all work together? #

While searching for answers to all these questions, you might find a possible solution in some analogies. In the web and testing communities specifically, developers tend to use these analogies to give you an idea of how many tests you should use of which type.

The following five strategies depicted in this image are the most common ones:

Test Pyramid
Test Diamond
Test Ice Cone (also known as Test Pizza)
Test Honeycomb
Test Trophy

This is truly a lot of information to process. How should you decide on a matching test strategy based on all this? Don't worry, we've got you covered. In the next article, we will discuss these different strategies in more detail and explain how to choose the best fit for your project. Stay tuned! 🔥

New to the web platform in June

2023-06-30T00:00:00Z

Stable browser releases #

In June 2023 Firefox 114 became stable, so it's a single browser issue this month. Check out the beta browser releases section for details of several features that are about to become interoperable once those betas become stable.

WebTransport API #

Firefox 114 includes the WebTransport API, a modern update to WebSockets providing support for multiple streams, unidirectional streams, and out-of-order delivery.

Browser support

Chrome 97, Supported 97
Firefox 114, Supported 114
Edge 97, Supported 97
Safari, Not supported

Source

The SVG `crossorigin` attribute #

Firefox 114 also includes the crossorigin attribute, on the <image> and <feImage> elements in SVG, provides support for configuration of the Cross-Origin Resource Sharing (CORS) requests for the element's fetched data. This works in the same way as the HTML crossorigin attribute.

Browser support

Chrome, Not supported
Firefox 114, Supported 114
Edge, Not supported
Safari, Not supported

Source

Beta browser releases #

Beta browser versions give you a preview of things that will be in the next stable version of the browser. It's a great time to test new features, or removals, that could impact your site before the world gets that release. New betas are Firefox 115, and Safari 17 with Chrome 115 and Safari 16.6 still ongoing. These releases bring many great features to the platform. Check out the release notes for all of the details, here are just a few highlights.

Firefox 115 supports the CSS animation-composition property. Once this version of Firefox becomes stable on July 4th, animation-composition will be supported in all three major engines. Learn more in the article Specify how multiple animation effects should composite with animation-composition.

There is a whole stack of new features and fixes in the Safari 17 beta. Safari 17 adds Web Apps to macOS Sonoma. This means you can add a website to the Dock from the File menu or Share Sheet, and it will open in its own window.

Safari 17 also brings some features to interoperable status—contain-intrinsic-size, @counter-style, @font-face size-adjust, and the overflow-block and overflow-inline media features will be available in all major engines when Safari 17 ships.

Photo by Rodrigo Abreu.

The origin private file system

2023-06-08T00:00:00Z

Browser support #

The origin private file system is supported by modern browsers and is standardized by the Web Hypertext Application Technology Working Group (WHATWG) in the File System Living Standard.

Browser support

Chrome 86, Supported 86
Firefox 111, Supported 111
Edge 86, Supported 86
Safari 15.2, Supported 15.2

Source

Motivation #

When you think of files on your computer, you probably think about a file hierarchy: files organized in folders that you can explore with your operating system's file explorer. For example, on Windows, for a user called Tom, their To Do list might live in C:\Users\Tom\Documents\ToDo.txt. In this example, ToDo.txt is the file name, and Users, Tom, and Documents are folder names. C:\ on Windows represents the root directory of the drive.

Traditional way of working with files on the web #

To edit the To Do list in a web application, this is the traditional flow:

The user uploads the file to a server or opens it on the client with <input type="file">.
The user makes their changes, and then downloads the resulting file with an injected <a download="ToDo.txt> that you programmatically click() via JavaScript.
For opening folders, you use a special attribute in <input type="file" webkitdirectory>, which, despite its proprietary name, has practically universal browser support.

Modern way of working with files on the web #

This flow is not representative of how users think of editing files, and means users end up with downloaded copies of their input files. Therefore, the File System Access API introduced three picker methods—showOpenFilePicker(), showSaveFilePicker(), and showDirectoryPicker()—that do exactly what their name suggests. They enable a flow as follows:

Open ToDo.txt with showOpenFilePicker(), and get a FileSystemFileHandle object.
From the FileSystemFileHandle object, get a File by calling the file handle's getFile() method.
Modify the file, then call requestPermission({mode: 'readwrite'}) on the handle.
If the user accepts the permission request, save the changes back to the original file.
Alternatively, call showSaveFilePicker() and let the user pick a new file. (If the user picks a previously opened file, its contents will be overwritten.) For repeat saves, you can keep the file handle around, so you don't have to show the file save dialog again.

Restrictions of working with files on the web #

Files and folders that are accessible via these methods live in what can be called the user-visible file system. Files saved from the web, and executable files specifically, are marked with the mark of the web, so there's an additional warning the operating system can show before a potentially dangerous file gets executed. As an additional security feature, files obtained from the web are also protected by Safe Browsing, which, for the sake of simplicity and in the context of this article, you can think of as a cloud-based virus scan. When you write data to a file using the File System Access API, writes are not in-place, but use a temporary file. The file itself is not modified unless it passes all these security checks. As you can imagine, this work makes file operations relatively slow, despite improvements applied where possible, for example, on macOS. Still every write() call is self-contained, so under the hood it opens the file, seeks to the given offset, and finally writes data.

Files as the foundation of processing #

At the same time, files are an excellent way to record data. For example, SQLite stores entire databases in a single file. Another example are mipmaps used in image processing. Mipmaps are pre-calculated, optimized sequences of images, each of which is a progressively lower resolution representation of the previous, which makes many operations like zooming faster. So how can web applications get the benefits of files, but without the performance costs of traditional web-based file processing? The answer is the origin private file system.

The user-visible versus the origin private file system #

Unlike the user-visible file system browsed via the operating system's file explorer, with files and folders you can read, write, move, and rename, the origin private file system is not meant to be seen by users. Files and folders in the origin private file system, as the name suggests, are private, and more concretely, private to the origin of a site. Discover the origin of a page by typing location.origin in the DevTools Console. For example, the origin of the page https://developer.chrome.com/articles/ is https://developer.chrome.com (that is, the part /articles is not part of the origin). You can read more about the theory of origins in Understanding "same-site" and "same-origin". All pages that share the same origin can see the same origin private file system data, so https://developer.chrome.com/docs/extensions/mv3/getstarted/extensions-101/ can see the same details as the previous example. Each origin has its own independent origin private file system, which means the origin private file system of https://developer.chrome.com is completely distinct from the one of, say, https://web.dev. On Windows, the root directory of the user-visible file system is C:\. The equivalent for the origin private file system is an initially empty root directory per origin accessed by calling the asynchronous method navigator.storage.getDirectory(). For a comparison of the user-visible file system and the origin private file system, see the following diagram. The diagram shows that apart from the root directory, everything else is conceptually the same, with a hierarchy of files and folders to organize and arrange as needed for your data and storage needs.

Specifics of the origin private file system #

Just like other storage mechanisms in the browser (for example, localStorage or IndexedDB), the origin private file system is subject to browser quota restrictions. When a user clears all browsing data or all site data, the origin private file system will be deleted, too. Call navigator.storage.estimate() and in the resulting response object see the usage entry to see how much storage your app already consumes, which is broken down by storage mechanism in the usageDetails object, where you want to look at the fileSystem entry specifically. Since the origin private file system is not visible to the user, there are no permissions prompts and no Safe Browsing checks.

Getting access to the root directory #

To get access to the root directory, run the command below. You end up with an empty directory handle, more specifically, a FileSystemDirectoryHandle.

const opfsRoot = await navigator.storage.getDirectory();
// A FileSystemDirectoryHandle whose type is "directory"
// and whose name is "".
console.log(opfsRoot);

Main thread or Web Worker #

There are two ways of using the origin private file system: on the main thread or in a Web Worker. Web Workers cannot block the main thread, which means in this context APIs can be synchronous, a pattern generally disallowed on the main thread. Synchronous APIs can be faster as they avoid having to deal with promises, and file operations are typically synchronous in languages like C that can be compiled to WebAssembly.

// This is synchronous C code.
FILE *f;
f = fopen("example.txt", "w+");
fputs("Some text\n", f);
fclose(f);

If you need the fastest possible file operations and/or you deal with WebAssembly, skip down to Using the origin private file system in a Web Worker. Else, you can read on.

Using the origin private file system on the main thread #

Creating new files and folders #

Once you have a root folder, create files and folders using the getFileHandle() and the getDirectoryHandle() methods respectively. By passing {create: true}, the file or folder will be created if it doesn't exist. Build up a hierarchy of files by calling these functions using a newly created directory as the starting point.

const fileHandle = await opfsRoot
    .getFileHandle('my first file', {create: true});
const directoryHandle = await opfsRoot
    .getDirectoryHandle('my first folder', {create: true});
const nestedFileHandle = await directoryHandle
    .getFileHandle('my first nested file', {create: true});
const nestedDirectoryHandle = await directoryHandle
    .getDirectoryHandle('my first nested folder', {create: true});

Accessing existing files and folders #

If you know their name, access previously created files and folders by calling the getFileHandle() or the getDirectoryHandle() methods, passing in the name of the file or folder.

const existingFileHandle = await opfsRoot.getFileHandle('my first file');
const existingDirectoryHandle = await opfsRoot
    .getDirectoryHandle('my first folder);

Getting the file associated with a file handle for reading #

A FileSystemFileHandle represents a file on the file system. To obtain the associated File, use the getFile() method. A File object is a specific kind of Blob, and can be used in any context that a Blob can. In particular, FileReader, URL.createObjectURL(), createImageBitmap(), and XMLHttpRequest.send() accept both Blobs and Files. If you will, obtaining a File from a FileSystemFileHandle "frees" the data, so you can access it and make it available to the user-visible file system.

const file = await fileHandle.getFile();
console.log(await file.text());

Writing to a file by streaming #

Stream data into a file by calling createWritable() which creates a FileSystemWritableFileStream to that you then write() the contents. At the end, you need to close() the stream.

const contents = 'Some text';
// Get a writable stream.
const writable = await fileHandle.createWritable();
// Write the contents of the file to the stream.
await writable.write(contents);
// Close the stream, which persists the contents.
await writable.close();

Deleting files and folders #

Delete files and folders by calling their file or directory handle's particular remove() method. To delete a folder including all subfolders, pass the {recursive: true} option.

await fileHandle.remove();
await directoryHandle.remove({recursive: true});

As an alternative, if you know the name of the to-be-deleted file or folder in a directory, use the removeEntry() method.

directoryHandle.removeEntry('my first nested file');

Moving and renaming files and folders #

Rename and move files and folders using the move() method. Moving and renaming can happen together or in isolation.

// Rename a file.
await fileHandle.move('my first renamed file');
// Move a file to another directory.
await fileHandle.move(nestedDirectoryHandle);
// Move a file to another directory and rename it.
await fileHandle
    .move(nestedDirectoryHandle, 'my first renamed and now nested file');

Resolving the path of a file or folder #

To learn where a given file or folder is located in relation to a reference directory, use the resolve() method, passing it a FileSystemHandle as the argument. To obtain the full path of a file or folder in the origin private file system, use the root directory as the reference directory obtained via navigator.storage.getDirectory().

const relativePath = await opfsRoot.resolve(nestedDirectoryHandle);
// `relativePath` is `['my first folder', 'my first nested folder']`.

Checking if two file or folder handles point to the same file or folder #

Sometimes you have two handles and don't know if they point at the same file or folder. To check whether this is the case, use the isSameEntry() method.

fileHandle.isSameEntry(nestedFileHandle);
// Returns `false`.

Listing the contents of a folder #

FileSystemDirectoryHandle is an asynchronous iterator that you iterate over with a for await…of loop. As an asynchronous iterator, it also supports the entries(), the values(), and the keys() methods, from which you can choose depending on what information you need:

for await (let [name, handle] of directoryHandle) {}
for await (let [name, handle] of directoryHandle.entries()) {}
for await (let handle of directoryHandle.values()) {}
for await (let name of directoryHandle.keys()) {}

Recursively listing the contents of a folder and all subfolders #

Dealing with asynchronous loops and functions paired with recursion is easy to get wrong. The function below can serve as a starting point for listing the contents of a folder and all its subfolders, including all files and their sizes. You can simplify the function if you don't need the file sizes by, where it says directoryEntryPromises.push, not pushing the handle.getFile() promise, but the handle directly.

  const getDirectoryEntriesRecursive = async (
    directoryHandle,
    relativePath = '.',
  ) => {
    const fileHandles = [];
    const directoryHandles = [];
    const entries = {};
    // Get an iterator of the files and folders in the directory.
    const directoryIterator = directoryHandle.values();
    const directoryEntryPromises = [];
    for await (const handle of directoryIterator) {
      const nestedPath = `${relativePath}/${handle.name}`;
      if (handle.kind === 'file') {
        fileHandles.push({ handle, nestedPath });
        directoryEntryPromises.push(
          handle.getFile().then((file) => {
            return {
              name: handle.name,
              kind: handle.kind,
              size: file.size,
              type: file.type,
              lastModified: file.lastModified,
              relativePath: nestedPath,
              handle
            };
          }),
        );
      } else if (handle.kind === 'directory') {
        directoryHandles.push({ handle, nestedPath });
        directoryEntryPromises.push(
          (async () => {
            return {
              name: handle.name,
              kind: handle.kind,
              relativePath: nestedPath,
              entries:
                  await getDirectoryEntriesRecursive(handle, nestedPath),
              handle,
            };
          })(),
        );
      }
    }
    const directoryEntries = await Promise.all(directoryEntryPromises);
    directoryEntries.forEach((directoryEntry) => {
      entries[directoryEntry.name] = directoryEntry;
    });
    return entries;
  };

Using the origin private file system in a Web Worker #

As outlined before, Web Workers can't block the main thread, which is why in this context synchronous methods are allowed.

Getting a synchronous access handle #

The entry point to the fastest possible file operations is a FileSystemSyncAccessHandle, obtained from a regular FileSystemFileHandle by calling createSyncAccessHandle().

const fileHandle = await opfsRoot
    .getFileHandle('my highspeed file.txt', {create: true});
const syncAccessHandle = await fileHandle.createSyncAccessHandle();

Synchronous in-place file methods #

Once you have a synchronous access handle, you get access to fast in-place file methods that are all synchronous.

getSize(): Returns the size of the file in bytes.
write(): Writes the content of a buffer into the, optionally at a given offset, and returns the number of written bytes. Checking the returned number of written bytes allows callers to detect and handle errors and partial writes.
read(): Reads the contents of the file into a buffer, optionally at a given offset.
truncate(): Resizes the file to the given size.
flush(): Ensures that the contents of the file contain all the modifications done through write().
close(): Closes the access handle.

Here is an example that uses all the methods mentioned above.

const opfsRoot = await navigator.storage.getDirectory();
const fileHandle = await opfsRoot.getFileHandle('fast', {create: true});
const accessHandle = await fileHandle.createSyncAccessHandle();

const textEncoder = new TextEncoder();
const textDecoder = new TextDecoder();

// Initialize this variable for the size of the file.
let size;
// The current size of the file, initially `0`.
size = accessHandle.getSize();
// Encode content to write to the file.
const content = textEncoder.encode('Some text');
// Write the content at the beginning of the file.
accessHandle.write(content, {at: size});
// Flush the changes.
accessHandle.flush();
// The current size of the file, now `9` (the length of "Some text").
size = accessHandle.getSize();

// Encode more content to write to the file.
const moreContent = textEncoder.encode('More content');
// Write the content at the end of the file.
accessHandle.write(moreContent, {at: size});
// Flush the changes.
accessHandle.flush();
// The current size of the file, now `21` (the length of
// "Some textMore content").
size = accessHandle.getSize();

// Prepare a data view of the length of the file.
const dataView = new DataView(new ArrayBuffer(size));

// Read the entire file into the data view.
accessHandle.read(dataView);
// Logs `"Some textMore content"`.
console.log(textDecoder.decode(dataView));

// Read starting at offset 9 into the data view.
accessHandle.read(dataView, {at: 9});
// Logs `"More content"`.
console.log(textDecoder.decode(dataView));

// Truncate the file after 4 bytes.
accessHandle.truncate(4);

Copying a file from the origin private file system to the user-visible file system #

As mentioned above, moving files from the origin private file system to the user-visible file system isn't possible, but you can copy files. Since showSaveFilePicker() is only exposed on the main thread, but not in the Worker thread, be sure to run the code there.

// On the main thread, not in the Worker. This assumes
// `fileHandle` is the `FileSystemFileHandle` you obtained
// the `FileSystemSyncAccessHandle` from in the Worker
// thread. Be sure to close the file in the Worker thread first.
const fileHandle = await opfsRoot.getFileHandle('fast');
try {
  // Obtain a file handle to a new file in the user-visible file system
  // with the same name as the file in the origin private file system.
  const saveHandle = await showSaveFilePicker({
    suggestedName: fileHandle.name || ''
  });
  const writable = await saveHandle.createWritable();
  await writable.write(await fileHandle.getFile());
  await writable.close();
} catch (err) {
  console.error(err.name, err.message);
}

Debugging the origin private file system #

Until built-in DevTools support is added (see crbug/1284595), use the OPFS Explorer Chrome extension to debug the origin private file system. The screenshot above from the section Creating new files and folders is taken straight from the extension by the way.

After installing the extension, open the Chrome DevTools, select the OPFS Explorer tab, and you're then ready to inspect the file hierarchy. Save files from the origin private file system to the user-visible file system by clicking the file name and delete files and folders by clicking the trash can icon.

Demo #

See the origin private file system in action (if you install the OPFS Explorer extension) in a demo that uses it as a backend for a SQLite database compiled to WebAssembly. Be sure to check out the source code on Glitch. Note how the embedded version below does not use the origin private file system backend (because the iframe is cross-origin), but when you open the demo in a separate tab, it does.

Conclusions #

The origin private file system, as specified by the WHATWG, has shaped the way we use and interact with files on the web. It has enabled new use cases that were impossible to achieve with the user-visible file system. All major browser vendors—Apple, Mozilla, and Google—are on-board and share a joint vision. The development of the origin private file system is very much a collaborative effort, and feedback from developers and users is essential to its progress. As we continue to refine and improve the standard, feedback on the whatwg/fs repository in the form of Issues or Pull Requests is welcome.

Acknowledgements #

This article was reviewed by Austin Sully, Etienne Noël, and Rachel Andrew. Hero image by Christina Rumpf on Unsplash.

New CSS color spaces and functions in all major engines

2023-06-02T00:00:00Z

CSS now supports color spaces that allow us to access colors outside of the sRGB gamut. This means that you can support HD (high definition) displays, using colors from HD gamuts. This support comes with new functions to make better use of color on the web.

Accessing color spaces from CSS #

We already have a number of functions that allow us to access colors within the sRGB gamut—rgb(), hsl(), and hwb(). Now supported in browsers is the color() function, a normalized way to access colors within any RGB color space. This includes sRGB, Display P3, and Rec2020. You can see some examples in the following CSS:

.valid-css-color-function-colors {
  --srgb: color(srgb 1 1 1);
  --srgb-linear: color(srgb-linear 100% 100% 100% / 50%);
  --display-p3: color(display-p3 1 1 1);
  --rec2020: color(rec2020 0 0 0);
  --a98-rgb: color(a98-rgb 1 1 1 / 25%);
  --prophoto: color(prophoto-rgb 0% 0% 0%);
  --xyz: color(xyz 1 1 1);
}

Browser support

Chrome 111, Supported 111
Firefox 113, Supported 113
Edge 111, Supported 111
Safari 15, Supported 15

Source

Also supported are several functions allowing access to color spaces other than sRGB using lch(), lab(), oklch(), and oklab().

Browser support

Chrome 111, Supported 111
Firefox 113, Supported 113
Edge 111, Supported 111
Safari 15, Supported 15

Source

You can learn about all of these different color spaces in the High definition CSS color guide.

The `color-mix()` function #

As well as these new color spaces, all engines now support the color-mix() function. This function enables mixing of one color into another, in any of the color spaces. In the following CSS, 25% of blue is mixed into white, in the srgb color space.

.example {
  background-color: color-mix(in srgb, blue 25%, white);
}

Browser support

Chrome 111, Supported 111
Firefox 113, Supported 113
Edge 111, Supported 111
Safari 16.2, Supported 16.2

Source

Learn more about color-mix()

These new functions and color spaces promise to bring vibrant HD color to the web. For inspiration, make a start by creating some beautiful gradients using the HD gradient generator at gradient.style.

Hero image by Daniele Levis Pelusi

New to the web platform in May

2023-05-31T00:00:00Z

Stable browser releases #

In May 2023, Firefox 113, Chrome 113, Chrome 114, and Safari 16.5 became stable. Let's take a look at what this means for the web platform.

WebGPU #

Chrome 113 includes WebGPU, the successor to the WebGL and WebGL 2 graphics APIs for the web. It provides modern features such as GPU compute, lower overhead access to GPU hardware, the ability to render to multiple canvases from a single graphics device, and better, more predictable performance.

Browser support

Chrome 113, Supported 113
Firefox preview, Preview
Edge 113, Supported 113
Safari, Not supported

Source

First-Party Sets #

First-Party Sets (FPS) is part of the Privacy Sandbox. It is a way for organizations to declare relationships among sites, so that browsers can decide when to allow limited third-party cookie access for sites within a set. FPS began a staged rollout in Chrome 113.

CSS media features and more #

For CSS, Chrome 113 includes the overflow-inline and overflow-block media features.

Browser support

Chrome 113, Supported 113
Firefox 66, Supported 66
Edge 113, Supported 113
Safari, Not supported

Source

And the update media feature.

Browser support

Chrome 113, Supported 113
Firefox 102, Supported 102
Edge 113, Supported 113
Safari, Not supported

Source

Also included is the linear() easing function, which you can learn more about in the article Create complex animation curves in CSS with the linear() easing function.

Browser support

Chrome 113, Supported 113
Firefox 112, Supported 112
Edge 113, Supported 113
Safari, Not supported

CSS Color Level 4 features #

Firefox 113 includes the color(), lab(), lch(), oklab(), oklch(), and color-mix() functional notations, along with the forced-color-adjust property. This means that the new color spaces and functions are now supported across all three major engines. You can learn more about these color spaces and functions in the High definition CSS color guide.

Browser support

Chrome 111, Supported 111
Firefox 113, Supported 113
Edge 111, Supported 111
Safari 16.2, Supported 16.2

Source

More control over `:nth-child()` selections #

Firefox 113 also adds the ability to pass a selector list into :nth-child() and nth-last-child(). Learn more about this, and see examples in the post More control over :nth-child() selections with the of S syntax.

Browser support

Chrome 111, Supported 111
Firefox 113, Supported 113
Edge 111, Supported 111
Safari 9, Supported 9

Compressions Streams API #

Now supported in all three major engines due to inclusion in Firefox 113, the Compressions Streams API enables the compression and decompression of streams. This means that JavaScript applications no longer need to bundle a compression library.

Browser support

Chrome 80, Supported 80
Firefox 113, Supported 113
Edge 80, Supported 80
Safari 16.4, Supported 16.4

Source

CSS nesting #

Safari 16.5 mostly resolved issues, but also adds support for CSS Nesting, with the new nesting selector >, used to nest related style rules, in a way that will be familiar to developers who have used pre-processors:

.nesting {
  color: hotpink;

  > .is {
    color: rebeccapurple;

    > .awesome {
      color: deeppink;
    }
  }
}

Browser support

Chrome 112, Supported 112
Firefox, Not supported
Edge 112, Supported 112
Safari 16.5, Supported 16.5

Source

Balancing headlines with `text-wrap: balance` #

From Chrome 114 you can use text-wrap: balance. This allows you to balance headlines, avoiding the issue of having a single word on the final line, providing a more pleasing and readable result. You can find out more in CSS text-wrap: balance.

Browser support

Chrome 114, Supported 114
Firefox, Not supported
Edge 114, Supported 114
Safari, Not supported

Source

CHIPS: Cookies Having Independent Partitioned State #

As part of the work to phase out third-party cookies, CHIPS enables opting-in to third-party cookies being partitioned by top-level site using the new cookie attribute Partitioned. CHIPS is available in Chrome 114.

Also in Chrome 114 is the Popover API making it easier to build transient user interface (UI) elements that are displayed on top of all other web app UI.

These include user-interactive elements like action menus, form element suggestions, content pickers, and teaching UI.

The new popover attribute enables any element to be displayed in the top layer automatically. This means no more worrying about positioning, stacking elements, focus or keyboard interactions for the developer.

Learn more in Introducing the popover API.

Browser support

Chrome 114, Supported 114
Firefox 114, Behind a flag
Edge 114, Supported 114
Safari 17, Supported 17

Source

Beta browser releases #

Beta browser versions give you a preview of things that will be in the next stable version of the browser. It's a great time to test new features, or removals, that could impact your site before the world gets that release. New betas are Firefox 114, Chrome 115, and Safari 16.6. These releases bring many great features to the platform. Check out the release notes for all of the details, here are just a few highlights.

Chrome 115 includes multiple values for the CSS display property. This means that display: flex becomes display: block flex and display: block becomes display: block flow. The single values are maintained as legacy keywords, and once in Chrome Stable this makes the multiple values available accross all engines.

Also in Chrome 115 are the ScrollTimeline and ViewTimeline extensions to the Web Animations specification. These enable scroll-driven animations via CSS and JavaScript.

Firefox 114 includes the WebTransport API, a modern update to WebSockets providing support for multiple streams, unidirectional streams, and out-of-order delivery.

Photo by Photoz ace.

Deploying AVIF for more responsive websites

2023-05-24T00:00:00Z

AVIF is a new image format that is quickly gaining popularity on the web because of its high compression rates, efficient performance, and broad adoption. AVIF is an open, royalty-free image format that is based on the AV1 video codec standardized by the Alliance for Open Media. This blog post will provide an overview of how AVIF is adopted in the ecosystem, and what kind of performance and quality benefits developers can expect from AVIF for still images and animations.

What’s new with the AVIF ecosystem? #

Since the introduction of AVIF in Chrome, Firefox and Safari, usage of AVIF on the web has been growing steadily; almost all browsers support AVIF today.

In Chrome alone, AVIF usage grew to approximately one percent in a little over a year after Chrome added AVIF support in stable.

A number of image CDNs, such as Akamai, Cloudflare, Cloudinary and Imgix are serving AVIF images today. In a blog post announcing AVIF support, Imgix reported 60% file size savings compared to JPEG and 35% savings compared to WebP. These file size savings lead to significant storage savings, but also help pages load faster, yielding faster Largest Contentful Paint (LCP) times. LCP is one of the Core Web Vitals, and represents how quickly the largest block of content on the page has loaded. Using modern codecs to compress images is one of the key techniques to reduce LCP. Lighthouse is a great Chrome developer tool for testing your web site and to see how much savings AVIF would bring.

WordPress is the most popular website platform in the world, and there are number of plugins available for developers to convert their images to AVIF, such as:

For more hands-on developers, tools like ImageMagick and FFmpeg are a good starting point.

AVIF encode speed #

Fast encoding speed and high visual quality are critical for deploying image compression at scale. AVIF software encoding speed has improved significantly over the past two years. Compared to other modern still image formats, AVIF produces smaller files with similar visual quality (see the following graph, lower is better) but is also faster to encode.

The chart below (higher is better) illustrates how AVIF encoding speed compares to other image formats. Previous generation codecs like WebP benefit from the less complex (but also less efficient) compression algorithms. With a multi-threaded encoding scheme, AVIF achieves similar performance for common use cases while delivering significant compression gains.

For developers interested in more detailed encoding speed and visual quality comparisons, the Image Coding Comparisons site contains reproducible benchmark results.

While software implementations for modern image codecs like AVIF and WebP are optimized for x86 and ARM processors architectures, compressing vast amounts of images at scale can be computationally expensive. One alternative to reduce compression costs is to explore hardware acceleration. Bluedot has developed a hardware accelerated Pulsar-AVIF encoder running on programmable FPGAs, such as AMD's Alveo U250. Compared to software based avifenc, Pulsar-AVIF delivers a 7 to 23 times speed improvement with similar compression efficiency.

AVIF encode speed comparison

Test set: Kodak (24 images of 768x512)

Encoding 24 images simultaneously (24 processes)

Each software encoding process is executed with 4 threads. (-j 4)
Encoder	Encode time (ms)	Frames per second	CPU utilization	Hardware specification
Pulsar-AVIF (FPGA)	60	409.85	305%	AMD Alveo U250 1ea + Intel(R) Xeon(R) Platinum 8171 CPU at 2.6GHz, 10 cores
avifenc (libaom)	405	59.26	3200%	Intel(R) Xeon(R) Platinum 8370C CPU at 2.8GHz, 32 cores
avifenc (SVT-AV1)	1325	18.11	3200%	Intel(R) Xeon(R) Platinum 8370C CPU at 2.8GHz, 32 cores

Developers can deploy Pulsar-AVIF encoder with cloud virtual machines, such as Azure NP-Series.

AVIF features for responsive web pages #

AVIF has a few interesting features that will help to deliver more responsive web pages. This time we’ll dive a bit into animated AVIFs, which are by far the most efficient way of delivering cool animations on the web.

Animated AVIF #

Animated GIF is still a popular format for animated images, despite being 35 years old. Biggest drawbacks of animated GIFs are the support for 256 colors only and poor compression leading to very large file sizes while also limiting the resolution or frame rate for practical use cases. In contrast, animated AVIF coding is actually the same as AV1 video coding scheme which provides significant file size savings compared to animated GIF.

We ran a simple benchmark where we encoded a set of animated GIFs to both AVIF and JPEG XL. Over the test set, median file size savings percentage was approximately 86% compared to original GIF files and about 73% compared to animated JPEG XL files*.

* libavif and libjxl versions: libavif version 4cff6a3 (libaom version v3.5.0), libjxl version 176b1c03. Test set: 15 sample GIFs from Wikipedia.

Chrome, Firefox and Safari all support animated AVIF playbacks.

FFmpeg is one tool to use for creating animated AVIF files, here’s a basic example of converting a GIF to AVIF using FFmpeg:

ffmpeg -i "$INPUT_GIF" -crf $CRF -b:v 0 "$OUTPUT.avif"

$CRF is the desired output quality on a scale of 0 to 63. Lower values mean better quality and greater file size. 0 uses lossless compression. Start with a value of 23 for small animated AVIF files.

FFmpeg uses libaom by default for encoding AVIF images, but it can also use rav1e or SVT-AV1 when available. More information about encoder choices, tuning the encoding parameters for speed/quality trade-offs can be found in FFmpeg's AV1 encoding guide.

Another use case is to repackage an AV1 video into AVIF without re-encoding the original file. This is significantly cheaper than decoding/encoding the original AV1 file and makes the AV1 video available for use with the <img> element. Passing -c:v copy to FFmpeg can do this.

ffmpeg -i "$INPUT_AV1_VIDEO" -c:v copy -an "$OUTPUT.avif"

Conclusions #

AVIF use on the web has been steadily increasing since launch and is widely supported by browsers, image CDNs, WordPress plugins and encoding tools. All in all, AVIF is a great choice for serving images on the web; AVIF is fast to encode and decode while providing the best quality or smallest file size, whichever you prefer for your website. AVIF is the most efficient way to deliver animations on the web. If you have questions, comments, or feature requests, please reach out on the av1-discuss mailing list, AOM Github community, and AVIF wiki.

Hero image from Unsplash, by Amal S .

How redBus improved their website's Interaction to Next Paint (INP) and increased sales by 7%

2023-05-10T00:00:00Z

The web and its capabilities are evolving at a fast pace. You can now build rich and full-featured experiences on the web that can achieve much of what native applications can in terms of capabilities.

JavaScript is a primary driver for interactivity across the web, but if it's not used with care, interactions can feel sluggish, and lead users to perceive your website to be non-responsive or altogether broken. Thankfully, the Interaction to Next Paint (INP) metric was created to address this specific user experience problem.

INP measures all interactions made with a page during its lifecycle, and reports a single value that is representative of a website's speed in responding to user inputs. Simply put, if a page's INP is at or below the good threshold, all interactions made with a page can be said to be reliably fast.

redBus, a bus booking and ticketing website based in India, undertook a substantial effort to improve their website's INP, even during the time when it was still considered an experimental metric. As a result of their efforts, they were able to increase sales by 7%, illustrating once again the relationship between web performance and business health. Here's what redBus did to improve their website's INP.

Top goals #

When redBus set out to optimize their website's INP, they had three goals in mind:

Provide a better user experience for users by focusing on interaction latency regardless of network speed and device capabilities.
Optimize their website to keep interactions as fast as possible.
Ensure that responses from their API were as light as possible to ensure fast data transfer to the front end.

The journey #

redBus categorized interaction latency in two ways:

Interaction latency caused by blocking JavaScript on the client. When interactions use excessive JavaScript that blocks the main thread, rendering is delayed, and this affects a page's INP.
Network latency caused by API calls. While network activity is not something that INP measures, an interaction reliant on a call to a remote API can feel sluggish on slower networks, or if requests result in large responses.

redBus was initially quite confident that the INP for their website would be good, but the Real User Monitoring (RUM) data for this metric at the 95th percentile told a different story.

How redBus measured INP #

redBus relied on the web-vitals JavaScript library built by Google to track not just INP, but all important user experience metrics for all pages across their website. In addition to the web-vitals JavaScript library, redBus used ELK to analyze INP data that was collected on the front end.

However, how you track your website's INP in the field may be quite different from how redBus approached the problem. We highly recommend that you read about how to find slow interactions in the field to learn how to best to track INP for your websites, and subsequently how to reproduce them in the lab before you begin optimizing interactions.

Once redBus had a system in place for tracking INP, they were able to analyze the data in order to gain a better understanding of where slow interactivity was present.

A screenshot of the logging system used by redBus to analyze INP values collected from the field. (Click for a higher resolution version of this image.)

Use cases #

When users search for fares on the redBus website, they can change the date on the search page to filter selected fares for the desired destination. The interaction to change the date on this page was slow, and was a cause of poor INP.

Additionally, when a user scrolls through fares, additional fares are lazy-loaded from the API. Though scrolling itself isn't factored in how INP is measured, the scroll event listener itself schedules a lot of work that must run on the main thread. This work was causing contention on the main thread that increased interaction latency, leading to poor INP on the search page.

The lazy-loading behavior used to load additional fares from the API on scroll. (Click for a higher resolution version of this video.)

How redBus optimized INP for the search page #

To improve the search page's INP, redBus made several optimizations:

The scroll event handler was debounced in order to reduce the amount of times the event callback would fire in a given period. By lowering the frequency in which scroll event callback ran, the main thread was able to respond more quickly to user interactions on the search page.
The resulting rendering work was prioritized by using a requestAnimationFrame callback. requestAnimationFrame tells the browser that the work in the callback must be done before the next frame.

Before: scroll handlers firing without debouncing applied to the event callback. A considerable number of blocking tasks on the main thread are present, which will delay interactions.

After: scroll handlers firing with debouncing applied. The scroll event callbacks fire less frequently, giving the main thread more opportunities to respond to user interactions.

Additionally, the following further optimizations were made to the search results page:

New batches of results were fetched on the second to last card on the search results page in order to improve the user experience and visual performance by triggering lazy loading earlier.
Fewer results were fetched on each network call during lazy loading. By reducing fetches from 30 to 10 results, a reduction in INP ranges at 870 to 900 down to 350 to 370 were observed.

The lazy-loading behavior used to load additional fares from the API on scroll. (Click for a higher resolution version of this video.)

While these changes significantly improved the INP of the search page, there was still the problem where the change event on the search page's input fields would call an expensive reducer function to update the user interface. This resulted in unnecessary rerendering of the user interface, which affected the page's INP.

INP values reported in the console while the user types in an input field. The resulting INP value of 344 observed in a lab setting falls within the "need improvement" thresholds. (Click for a higher resolution version of this video.)

To optimize this interaction, redBus managed the state of input components locally and synced it with the Redux store only when an input's blur event was fired. This change reduced the number of rerenders and eliminated unwanted rerendering of the user interface by calling the reducer less frequently.

Improved INP as a result of calling the reducer less frequently on an input field change. (Click for a higher resolution version of this video.)

With this change, the page's INP improved by 72%, resulting in a faster and smoother user experience that users are more likely to engage with.

Business impact #

The relationship between business health and page performance is well-known. Though INP is a relatively new metric compared to other Core Web Vitals, redBus observed better business outcomes by focusing on improving this important user-centric performance metric. The result was a 7% overall increase in sales.

In short, INP helped to paint a picture of runtime performance issues on the redBus website. With the knowledge that there were improvements to be made, redBus was able to observe the problem, reproduce it, and use that crucial information to make optimizations that were beneficial to redBus and its business.

Introducing Baseline

2023-05-10T00:00:00Z

Baseline helps you to see, at a glance, whether a feature or API is safe to use in your site or web applications. In this post, learn about the ideas that led to this concept, and how we hope it will help you.

Keeping up with changes to the web platform #

The web of today changes rapidly. Our browsers are evergreen, with new features landing in stable browsers each month. This is exciting, however it also poses problems. How do web developers keep up with all of this change? How do you know when it's safe to use a feature? When is it the right time to start to learn, and to invest in new features?

In the past, we often explained browser support to stakeholders by tying it to a certain browser release (for example, Internet Explorer 11) because the line in the sand a non-evergreen browser created was clear to everyone. Today, the landscape can often seem less clear, with so many features landing it's a lot of work to check support for everything we use.

We know how much of a problem this is to developers, because you have consistently told us that it's a problem. Over two years ago we decided it was a problem we wanted to try to address.

Getting our own house in order #

We recognized that we were adding to confusion about the status of features, mixing experimental things in with stable content on our sites. So, we've improved the clarity of our own communication channels. We now use web.dev to publish content about the stable web, those things that we can now describe as part of Baseline, and those that are very close to that status. We also highlight the work of other browsers, as we all work together to improve the interoperability of the platform.

On web.dev you'll find content such as the newly interoperable series, celebrating features that are now supported in all three major engines. We also have our monthly series, covering what's new to the web platform sharing the work of all browsers, and updates about Interop 2023. This site is also home to our best practices guidance in subjects such as performance, accessibility, and fundamental web development skills.

On developer.chrome.com you can learn about the new things that Chrome is bringing to the web platform. Some of these things are experimental, or only in Chrome right now. Many of the things we post about on developer.chrome.com are coming to other browsers, and we hope to celebrate their interoperable moments very soon, but we want you to have clarity about their status and browser support.

We have also been adding clear browser support information to everything that we publish, and when our team talks about features at conferences.

Documentation is really important for adoption of new features, and this year we've made sure that the new features we are landing in Chrome have documentation over on MDN. For example, take a look at the documentation for View Transitions and WebGPU. We also help support Open Web Docs who contribute documentation for the entire web platform to MDN.

Working with others #

Improving what we do was important, however to address the bigger issue we needed to work with others. We've been successfully working with our partners at other browser vendors and related companies through Interop 2022 and 2023. Forming the WebDX Community Group brought everyone together to think about this issue of clarity across the platform as a whole.

The group is working together on a feature set, a way to group web platform features to show their support status, and this feature-set is key to the concept of Baseline.

Creating platform-wide clarity with Baseline #

Baseline is the line in the sand that is hard to identify in a world of evergreen browsers. Everything that is fully supported in the most recent two versions of major browsers will be part of Baseline. Therefore if your library states that all features used are part of Baseline, developers know what you mean. When creating a proposal for a new application, you can explain to stakeholders that browser support will be tied to Baseline, thus creating clarity for everyone as to levels of support.

From today you will start to see Baseline appearing on pages on MDN, and on web.dev.

As Baseline will be a continuously moving line, with new features becoming part of that set each month, every year we will publish a cut of features that are part of Baseline at one moment in time. For extra clarity, you can tie support to Baseline 24, for example.

What's next? #

We'll be continuing the rollout of Baseline across web.dev. When reading an article or tutorial, you'll be able to see when the features described are part of Baseline. You won't get part of the way through something and realize it uses something that doesn't have good browser support.

We'll be providing widgets that you can use on your own articles or libraries, indicating support for the Baseline feature set.

We'll also be working to ensure that new features we are landing in Chrome become part of Baseline as quickly as possible. Watch out for future posts where we'll talk more about that work.

And we'll be gathering feedback from developers to find out how this idea is working in practice, and what more you would like to see. Keep an eye on the Baseline page, or offer feedback right now via the WebDX Community Group.

Advancing Interaction to Next Paint

2023-05-10T00:00:00Z

Chrome's mission with the Web Vitals program is to help developers focus on the metrics that are essential to great user experiences—the Core Web Vitals. One important aspect of the user experience that we've been focusing on is responsiveness, which is the ability of a web page to react quickly to user interactions.

First Input Delay (FID) is the Core Web Vital metric that measures responsiveness, but as we've written in the past, there are known limitations of FID. This led us to explore and seek feedback on a (then) experimental metric that addresses these limitations more effectively. In 2022, we announced Interaction to Next Paint (INP) as that new metric, made it widely available in our tools, and started working with the community to test its efficacy.

After another year of testing and gathering feedback from the community, we're ready to take the training wheels off and announce that INP is no longer experimental. Furthermore, effective March 2024, we're also committed to promoting INP as the new Core Web Vital metric for responsiveness, replacing FID.

In this post, we'll cover more about the motivation behind the decision, exactly what's changing, and how to get started. For more on how this affects Google Search, refer to their blog post.

A better responsiveness metric #

FID was a huge step forward when we introduced it as a Core Web Vital in 2020. It offered developers a new way to measure responsiveness as real users experience it, which has always been an important part of the Web Vitals program. Unlike similar metrics that only approximate page interactivity—like Total Blocking Time (TBT) and Time To Interactive (TTI)—FID directly measures the user experience. Crucially, a page could have slow TBT or TTI and still be perceived as responsive, because of the way real users interact with the page.

While it did improve the way we measure responsiveness, FID wasn't without limitations. The name itself actually gives away two such limitations: "first input" and "delay". FID only reports the responsiveness of the first time a user interacts with the page. Even though first impressions are important, the first interaction is not necessarily representative of all interactions throughout the life of a page. Further, FID only measures the input delay portion of the first interaction, which is the amount of time the browser had to wait (due to main thread busyness) before even beginning to handle the interaction.

Enter INP. Rather than only measuring the first interaction, INP takes all interactions into account, reporting one of the slowest over the entire lifetime of the page. And, rather than only measuring the delay portion, INP measures the full duration from the start of the interaction, through the event handler, and until the browser is able to paint the next frame. Hence, Interaction to Next Paint. These implementation details make INP a much more comprehensive measure of user-perceived responsiveness than FID.

Evolving INP #

Starting today, INP is no longer experimental and will instead be considered a pending Core Web Vital metric. This is a new designation to indicate that INP has proven its readiness to replace FID—but we're not making the change just yet. To give the ecosystem time to adjust, INP will officially become a stable Core Web Vital metric in March 2024.

Graphic showing the timeline of INP phases.

Across our tools, you'll start to see INP without the experimental prefix or icon. If you programmatically consume INP data from any of the following APIs, you'll need to update your code to switch over to the non-experimental INP field.

Map of APIs to their old and new INP field name.
* Lighthouse will stop using the experimental INP field in version 11.
Tool	Deprecated field	New field
CrUX API	`experimental_interaction_to_next_paint`	`interaction_to_next_paint`
CrUX History API	`experimental_interaction_to_next_paint`	`interaction_to_next_paint`
CrUX BigQuery	`experimental.interaction_to_next_paint`	`interaction_to_next_paint`
PageSpeed Insights API	`experimental_interaction_to_next_paint`	`interaction_to_next_paint`
Lighthouse report*	`experimental-interaction-to-next-paint`	`interaction-to-next-paint`

To ease the transition and avoid breaking any downstream applications, these APIs will continue to serve the experimental INP field for another 90 days. API support for the experimental INP field will end on August 8, 2023.

Meanwhile, FID will remain a Core Web Vital until March 2024. At that time, INP will join Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS) as the three stable Core Web Vitals. In a future update, we'll share more information about the precise timing of the change and the plan for FID after it's replaced as a Core Web Vital.

Getting started with INP #

Graphic showing the thresholds for good and poor INP.

Don't wait for INP to become a Core Web Vital in 2024 to start improving it. Your website may very well be in the 93% of sites that have good FID performance on mobile devices; however, you might be surprised to learn that only 65% of sites have good INP on mobile devices. INP paints a much more accurate picture of responsiveness, so these numbers help us to more clearly see the room for improvement ahead of us.

To find out whether your site has INP issues, how to address them, and all things INP, the best place to start is the INP optimization guide. Whether you're learning about responsiveness for the first time or you're a performance expert, we've added a lot of new guidance to make it as easy as possible for everyone to learn how to measure and optimize INP.

INP might take some time to learn, and that's just fine. To help you focus on the optimizations with the biggest ROI, earlier this year we published a blog post to distill our guidance down to the most effective recommendations to improve Core Web Vitals. Specifically, we wrote about three must-know techniques that apply equally to optimizing FID and INP: avoid or break up long tasks, avoid unnecessary JavaScript, and avoid large rendering updates. You can learn more about these and many other INP optimization techniques in our documentation.

The road ahead #

A new bar for responsiveness has been set, and we're excited to see the community rise to the challenge for a better user experience. The early feedback and case studies have been promising, but we know that for many, it may be a long and unfamiliar road ahead. We strive to make that journey as easy as possible with improved diagnostics, tools, and documentation to help developers along the way.

Stay tuned for updates on INP's exact graduation date in March 2024. And even though the metric is not experimental anymore, we're always open to feedback at web-vitals-feedback@googlegroups.com to help us improve INP and the Web Vitals program as a whole.

Hero image from Unsplash, by Agê Barros.

Economic Times quest for fixing INP

2023-05-10T00:00:00Z

Interaction to Next Paint (INP) is a metric that assesses a website's responsiveness to user input. Good responsiveness means that a page is quick to respond to user interactions. The lower a page's INP is, the better it is able to respond to user interactions.

The fuzzy beginning #

When Google initially introduced INP as an experimental metric with the potential to evolve into one of the Core Web Vitals metrics, the Economic Times team took up the challenge to fix it before it graduates into one, since providing a world class user experience is crucial to our core business values.

INP has been one of the most difficult metrics to solve thus far. In the beginning, it was unclear on how to measure INP effectively. What made it more difficult was the lack of community support—including most Real User Monitoring (RUM) providers not supporting it yet. However, we had Google RUM tools like Chrome User Experience Report (CrUX), the web-vitals JavaScript library, and others supporting it, which gave us a sense of where we stood while we were evaluating the path ahead. Our INP was close to 1,000 milliseconds at the origin level when we started.

One thing that emerged while fixing INP in the field was that one of the lab metrics to target could be Total Blocking Time (TBT). TBT was already well documented and supported by the community. Despite already meeting the thresholds for Core Web Vitals, however, we weren't doing as well on the TBT front, as it was over 3 seconds when we began.

What is TBT, and what steps did we take to improve it? #

TBT is a lab metric that measures the responsiveness of a web page to user input during page load. Any task that takes more than 50 milliseconds to execute is considered a long task, and the time after the 50 millisecond threshold is known as the blocking time.

TBT is calculated by taking the sum of the blocking time of all long tasks during page load. For example, if there are two long tasks during load, the blocking time is determined as follows:

Task A takes 80 milliseconds (30 milliseconds more than 50 milliseconds).
Task B takes 100 milliseconds (50 milliseconds more than 50 milliseconds).

The page's TBT will be: 80 milliseconds (30 + 50). The lower the TBT, the better, and TBT also correlates well with INP.

Here’s a quick lab comparison of our TBT before and after taking steps to improve it:

The main thread during startup before optimizing TBT. The TBT is 3,260 milliseconds.

The main thread during startup after optimizing TBT. The TBT is 120 milliseconds.

Minimize main thread work #

The browser’s main thread handles everything from parsing HTML, building the DOM, to parsing CSS and applying styles, as well as evaluating and executing JavaScript. The main thread also handles user interactions—that is, click, tap, and keypresses. If the main thread is occupied with doing other work, it may not respond to user inputs efficiently, and may lead to a janky user experience.

This was the most difficult task for us, since we have our own algorithms to detect user identity for serving ads based on subscription status and third party scripts for A/B testing, analytics, and more.

We took small steps at first, such as de-prioritizing loading of less critical business assets. Second, we used requestIdleCallback for non-critical work, which can help to reduce TBT.

if ('requestIdleCallback' in window) {
  this.requestIdleCallbackId = requestIdleCallback(fetchMarketsData.bind(this), {timeout: 3000});
} else {
  fetchMarketsData(); // Fallback in case requestIdleCallback is not supported
}

Specifying a timeout is recommended when using requestIdleCallback, since it makes sure that if the given time is elapsed and the callback is not already been called, it executes the callback immediately after the timeout.

Minimize script evaluation time #

We also lazy loaded third party libraries using Loadable components. We also removed unused JavaScript and CSS by profiling the page with the coverage tool in Chrome DevTools. It helped us to identify areas where tree shaking was needed to ship less code during page load, and therefore reduce the initial bundle size of the application.

Reduce DOM size #

Per Lighthouse, large DOM sizes increase memory usage, causes longer style recalculations, and produces costly layout reflows.

We reduced the number of DOM nodes in two ways:

First, we rendered our menu items at the user’s request (on click). It decreased the DOM size by around 1,200 nodes.
Second, we lazy loaded less important widgets.

Because of all these efforts, we reduced TBT significantly, and our INP was reduced accordingly by almost 50%:

At this point, we nearly ran out of easy wins to further reduce TBT (and INP by proxy), but we knew we had a lot of room for improvement. This is when we decided to upgrade our custom-built UI boilerplate to the latest version of React along with Next.js to make better use of hooks to avoid unnecessary re-rendering of components.

Due to more frequent updates and comparatively lesser traffic as compared to the other portions of the website, we began to migrate our topic pages to Next.js. We also used PartyTown for offloading additional heavy main thread work to web workers, along with techniques like requestIdleCallBack for deferring non-critical tasks.

How has improving INP helped The Economic Times? #

Current TBT and INP on origin #

At the time of publishing this post, the TBT for our origin was 120 milliseconds, down from 3,260 milliseconds when we began our optimization efforts. Similarly, the INP for our origin was 257 milliseconds after our optimization efforts, down from over 1,000 milliseconds.

INP CrUX trend #

The traffic received on topic pages represents a significantly smaller portion of overall traffic. Hence, it was an ideal place for experimentation. The CrUX results along with the business outcomes were very encouraging, and led us to expand our efforts across the entire website to reap further benefits.

Akamai mPulse TBT Analysis #

We use Akamai mPulse as our RUM solution, which measures TBT in the field. We observed a consistent decrease in TBT, clearly mapping to the outcomes of our efforts to reduce INP. As can be seen in the screenshot below, TBT values eventually dropped from approximately 5 seconds in to around 200 milliseconds in the field.

Business outcome #

Overall, our efforts to bring down TBT by 30 times, along with migrating to Next.js helped us reduce INP nearly by 4 times, which eventually led to a 50% decrease in bounce rate and 43% uplift in pageviews on topic pages.

Conclusion #

To summarize, INP extensively helped to determine runtime performance issues on parts of the Economic Times website. It has proven to be one of the most effective metrics to positively impact business outcomes. Due to the very encouraging numbers we've observed as the result of this effort, we are motivated to scale our optimization efforts to other areas of our website and reap additional benefits.

web.dev

New to the web platform in September

Stable browser releases #

Beta browser releases #

Effectively loading ads without impacting page speed

Harnessing Core Web Vitals #

Largest Contentful Paint (LCP) #

First Input Delay (FID) and Interaction to Next Paint (INP) #

Cumulative Layout Shift (CLS) #

Structuring your webpage into distinct content blocks #

Prioritize important ad slots #

Above the fold ads #

Below the fold ads #

Lazy load ads where appropriate #

Refresh ads without refreshing the page #

Prioritize asynchronous loading #

Optimize ad sizes, position and formats #

Better Ads Standards #

Strategic evaluation of ad networks and providers #

Conclusion #

CSS Subgrid

Subgrid basics #

Sharing a page level "macro" grid #

Checking for support #

Devtools #

Resources #

Submit your proposals for Interop 2024

Four common types of code coverage

What is code coverage? #

Four common types of code coverage #

Function coverage #

Line coverage #

Branch coverage #

Statement coverage #

What type of code coverage should you choose? #

Is test coverage the same as code coverage? #

100% code coverage doesn’t mean no bugs #

A meaningless way to achieve 100% code coverage #

A bad metric is worse than no metric #

Using code coverage in different types of testing #

Conclusion #

How prefetching helped Terra increase ads click-through rate by 30% and speed up Largest Contentful Paint.

Prefetching strategy #

Business Impact #

Technical details #

Conclusion #

New to the web platform in August

Stable browser releases #

Beta browser releases #

To test or not to test, a technical perspective

General guidelines and patterns #

Keep it simple #

Test what's worth it #

Don't test implementation details #

Mocking: Don't lose control #

Should you mock in end-to-end tests? #

Test specifics: Dos and don'ts #

What belongs to a good unit test? #

What belongs to a good integration test? #

What belongs to a good end-to-end test? #

Defining test cases and priorities

What is a test case? #

Test paths: Typical kinds of test cases #

Best practice: Writing test cases #

New to the web platform in July

Stable browser releases #

Multiple values for the CSS display property #

Scroll-driven animations #

Privacy Sandbox APIs #

The animation-composition property #

Array methods #

Beta browser releases #

Adapting typography to user preferences with CSS

Getting setup #

Loading the Roboto Flex variable font #

CSS custom properties and media queries for the win #

Settings when there's no preferences (default) #

Settings when the preference is for high contrast #

Settings when the preference is for low contrast #

Settings when the preference is for dark mode #

Multiple values for the CSS `display` property #

The `animation-composition` property #

The SVG `crossorigin` attribute #