DEV Community: Kevin Farrugia

Priority Hints and optimizing LCP

Kevin Farrugia — Mon, 02 Jan 2023 22:35:25 +0000

Cross-posted from https://imkev.dev/fetchpriority-opportunity

Priority Hints are used to indicate to the browser the relative priority of a resource. You can set Priority Hints by adding the fetchpriority attribute to <img>, <link>, <script>, and <iframe> elements or through the priority attribute on the Fetch API.

The browser's loading process is complex. Browsers determine a request's priority mostly by its type and its position in the document's markup. For example, a CSS file requested in the document's <head> will be assigned the Highest priority, while a <script> element with the defer attribute will be assigned the Low priority. The browser downloads resources with the same priority in the order in which they are discovered.

`fetchpriority`

The fetchpriority attribute can be used to hint the browser to increase or decrease the priority of a requested resource. The enumerated attribute can have one of three values:

high - The resource is more important relative to its default priority
low - The resource is less important relative to its default priority
auto - The default value

<img src="/lcp.jpg" alt="A dog" fetchpriority="high" />

In the example above, we are hinting to the browser that the <img> priority is more important than its default priority.

The same values are supported for the priority attribute on the fetch method.

fetch("/api/data.json", { priority: 'high' })

In the fetch request above, we are indicating to the browser that the fetch request has an increased priority compared to its default priority.

Default priority

Priority Hints increase or decrease a resource's priority relative to its default priority. For example, images - by default - always start at a Low priority. Assigning fetchpriority="high" will increase their priority to High. On the other hand, a render-blocking stylesheet is assigned a Highest priority by default. Assigning it fetchpriority="low" will lower its priority to High - but not Low. fetchpriority is used to adjust a resource's priority relative to its default, rather than to explicitly set its value.

The influence of Priority Hints on resource prioritization in Chromium documents the different resource types, their default priority (◉), and the resultant priority when using fetchpriority="high" (⬆) and fetchpriority="low" (⬇).

Note that if an image is discovered to be within the viewport, then its priority is boosted to High. However, this could be quite late in the loading process and may have little or no impact if the request was already sent. Using fetchpriority="high" allows you to tell the browser to start in High priority, rather than waiting for the browser to find out if it is in the viewport or not.

"Tight mode"

Most browsers download resources in two phases. During the initial phase (Chromium also refers to this as "Tight mode"), the browser does not download Low priority resources unless there are less than two in-flight requests.

In the waterfall chart above, you could see that the resource image-1.jpg does not start downloading until style-2.css has finished downloading - even if it was discovered immediately. At this point, only one resource remains in-flight - script.js, so the browser begins to download the Low priority image.

The initial phase is completed once all blocking scripts in the <head> have been downloaded and executed (scripts with async or defer are not render-blocking). Even if there are more than two in-flight requests, the browser can now proceed to download any remaining resources based on their priority and the order in which they appear in the markup.

In the chart above, once the render-blocking JavaScript is downloaded and executed (pink bar), the browser begins downloading the images, even if the two CSS files are still in-flight. The yellow vertical bar illustrates DOM Interactive - or when the readystatechange event was fired.

preconnect

If the images reside on a separate domain, the browser needs to open a connection to the domain before downloading the files.

This is shown on the WebPageTest chart with the green, orange, and magenta bars preceding the downloading. We can start downloading the images earlier using the preconnect resource hint.

In the chart above, the connection to the cdn.glitch.global domain is opened during the initial phase - before the browser is able to start downloading the files. Once the browser exits the initial phase (yellow vertical line) it begins downloading the images immediately - saving approximately 350ms.

`preload`

If we were able to improve the download time using the preconnect resource hint, are we able to improve it further using the preload directive? Short answer: no. The preload directive allows you to inform the browser about critical resources that are "late-discovered". This is especially useful for resources loaded inside stylesheets or scripts, such as background-images or fonts. In our example, the image is declared in the markup and discovered early, so preload has little effect.

In the chart above, we have replaced the preconnect hint with the following:

<link
  rel="preload"
  as="image"
  href="https://cdn.glitch.global/.../image-1.jpg"
/>

Despite the preload, the image still doesn’t begin downloading until there are less than two requests in-flight.

`fetchpriority`

We can use Priority Hints to indicate to the browser that image-1.jpg is more important than its default priority using:

<img
  src="https://cdn.glitch.global/.../image-1.jpg"
  fetchpriority="high"
  alt=""
/>

This should increase the initial priority of the image from Low to High, allowing the image to be picked up in the initial phase.

The waterfall chart above shows that image-1.jpg is picked up during the initial phase, in parallel with the other critical resources. This gives us the greatest improvement so far.

Firefox

Firefox uses similar heuristics to determine which resources should be loaded during the initial phase. However, differently from Chromium-based browsers, it does not begin downloading any Low priority resources until all JavaScript in the <head> is downloaded and executed - even when there is only one High priority request in-flight.

The above screenshot is taken from Firefox Web Developer Tools and shows that the image resources (rows 5 - 8) are fetched after the script (row 2) is downloaded and executed and the page becomes interactive - vertical, blue line.

While Chrome waits for JavaScript declared in the <head> to be downloaded and executed, Firefox waits for all render-blocking JavaScript declared before the image elements - even if these are declared outside of the <head>.

Firefox does not support fetchpriority yet, however, we can increase the priority of image-1.jpg using the preload directive.

In the screenshot above, the file image-1.jpg is fetched in parallel with the other resources. This is similar to the behavior we have seen when adding fetchpriority="high" on Google Chrome.

Safari

Safari on iOS and macOS also has an initial phase although it behaves differently than Chrome and Firefox.

Low priority resources start being fetched when there are fewer than two in-flight requests. It is not dependent on the readystatechange event and even on pages without any render-blocking JavaScript, the browser will wait until there is one in-flight request.

In the screenshot above, taken from Safari's Web Inspector, the images do not start downloading until style-1.css finishes downloading and there are less than two in-flight requests.

On Safari, the initial phase only applies to resources from the same origin. If the Low priority resources are loaded from a different domain they will be fetched as soon as they are discovered.

In the screenshot above, the crossorigin images are fetched immediately without waiting for the High priority resources to finish downloading.

The preload directive does not affect the resource's priority. However, placing the <link rel="preload"> directive before High priority requests will cause it to download earlier; since at the time it is discovered there are less than two requests in-flight. This is the same behavior seen on other browsers and in most cases, I would advise against placing preload directives above High priority resources as render-blocking CSS should take precedence.

In this screenshot, the Low priority file image-1.jpg begins downloading before the High priority style-1.css file because the <link rel="preload"> is placed above it in the document markup.

Combining `preload` with `fetchpriority`

Priority Hints are only supported on Chromium-based browsers so far, however, they fail gracefully on unsupported browsers that do not recognize the fetchpriority attribute. This allows us to combine the preload directive with Priority Hints.

<link
  rel="preload"
  as="image"
  fetchpriority="high"
  href="https://cdn.glitch.global/.../image-1.jpg"
/>

Browsers that support Priority Hints will preload the resource using the assigned fetchpriority, while browsers that do not will use the preload directive.

The above chart shows similar results to the one earlier which included the fetchpriority attribute on the <img> element. The advantage of this method is unifying an approach that prioritizes the resource on browsers that support Priority Hints and on those that do not.

`fetchpriority` all the things

In this section, we will look at the potential benefit of using fetchpriority. All data is taken from the HTTP Archive and we are only considering pages that use HTTP/2 or HTTP/3 and where the Largest Contentful Paint (LCP) element is an image. All queries and results are publicly available.

Note: The HTTP Archive data is collected using a private instance of WebPageTest using Chrome. You can learn more about their methodology.

I am assuming the benefit from fetchpriority as the difference between the time the resource is discovered and the time it starts downloading. I refer to this as the opportunity. Therefore if a resource is discovered early but the browser starts downloading it late, then the opportunity is greater.

Note that if the images are served from a different domain, I am including the time to open the connection in the opportunity.

The chart above plots the opportunity (in milliseconds) against the LCP. The opportunity is bucketed in groups of 100ms, while anything greater than 1,000ms is grouped into a single bucket. The chart shows a strong correlation between the opportunity and the LCP - the greater the opportunity, the worse the LCP.

The above chart shows the distribution of the opportunity for mobile devices for Low and High priority. At the median, an LCP image requested with High priority starts to be downloaded 21ms after it is discovered, while an LCP image with Low priority is downloaded after 102ms. The difference grows even further at the 75th and 90th percentile.

In addition to fetchpriority="High", an image may have an initial High priority if the image is late-discovered, for example when using CSS background-image or adding an image using JavaScript. In these cases, fetchpriority would not help since the request already has a High priority.

We can conclude that there is a clear benefit in prioritizing your LCP image. The opportunity varies depending on your page's composition. We have already covered that Low priority resources are not fetched immediately when there is at least one render-blocking script and two or more in-flight requests.

The above chart plots the number of render-blocking resources against the opportunity (in milliseconds). Intuitively, the more render-blocking resources your page has, the greater the delay in downloading the LCP image.

Conclusion

There is a big opportunity available to prioritize your LCP image through Resource Hints and Priority Hints. Many pages have the LCP element queued and waiting, even when it is immediately discoverable in the main document.

The above chart shows that on the median mobile website, the LCP image is queued for 98ms until the browser starts downloading it. At the 90th percentile, the LCP image is queued for 810ms. Using Priority Hints could increase the priority of the LCP image and reduce this waiting time.

There are also case studies showing an improvement to Largest Contentful Paint (LCP) after adding fetchpriority="high" to the LCP image. Etsy saw a 4% improvement, some others reportedly saw 20-30% improvements.

Increasing the priority of a resource usually comes at the cost of another resource, so Priority Hints should be used sparingly. However, if the browser is queuing your LCP image, I recommend you experiment with Priority Hints to see if you can reduce this waiting time and improve your LCP.

In a nutshell,

Host your LCP image on the same domain as your HTML document. If this is not possible, use preconnect to open an early connection.
The LCP image should be part of the document markup. If you are unable to do this, use preload to tell the browser to download the image before it is requested.
Avoid blocking resources when possible. If your LCP image is downloaded with a Low priority, use fetchpriority to hint the browser to download your image earlier.
You can use preload to prioritize your LCP image on Firefox until fetchpriority is supported. Safari does not download images earlier when using the preload directive.

Let me know what you think. Your feedback is welcome. ♥

Special thanks

Special thanks to Barry Pollard for his advice and valuable feedback.

Photo by Denise Jans on Unsplash

Interaction to Next Paint

Kevin Farrugia — Fri, 17 Jun 2022 14:32:38 +0000

Cross-posted from https://imkev.dev/inp

In May 2022, Google added Time to First Byte (TTFB) and Interaction to Next Paint (INP) to their CrUX report. INP measures a website's responsiveness and might replace First Input Delay (FID) as a Core Web Vital in the future.

Let's take a look at what Interaction to Next Paint is and how can you prepare your website to have a good INP.

First Input Delay

Before looking at INP, let's review First Input Delay, the Core Web Vital currently used to measure responsiveness to user interaction. FID measures the delay it takes the browser to begin processing the first interaction on a page.

In single-threaded JavaScript, if the main thread is busy processing a task, any user input is delayed until the call stack is clear and all tasks have been completed.

An example of poor responsiveness. The user key events do not update the screen until a long task has been completed and all characters are added at once.

FID is directly correlated with JavaScript long tasks. The more long JavaScript tasks on your website, the more likely that the user input will be delayed as the browser must wait for the current long task to complete before processing input.

The number of websites achieving a good FID score has increased from 72.1% of origins in 2018 to 92.5% of origins in May 2022. FID on desktop was always > 98%.

Interaction to Next Paint

INP aims to build on FID but considers the responsiveness of all user inputs. It also captures the entire duration of the interaction, until the next frame is painted onto the screen. Check out this demo to get a feel of how frustrating a high INP could be.

What is an interaction?

An interaction is one of the following:

Clicking or tapping on an interactive element, such as a button or checkbox.
Pressing a key, including text input fields.

It does not include hover or scroll events.

How is an interaction's duration measured?

The phases of a single interaction. The input delay occurs from the time an input is received and may be caused by factors such as blocking tasks on the main thread. The processing time is the time it takes for the interaction's event handlers to execute. When execution finishes, we then enter the presentation delay, which is the time it takes to render and paint the next frame. Source: https://web.dev/inp/

An interaction consists of three phases, the input delay, the processing time and the presentation delay. The duration of an interaction as measured by INP is the sum of the time for all three phases. In simpler words, it is the time it takes from when the user interacts with an element or input until the next frame is painted on the screen. This could be any visual cue that the user input has been received, such as displaying the character in a textbox or displaying a loading animation after clicking a button.

What is a good INP?

In most cases, INP measures the worst interaction on your page. For highly interactive pages with more than 50 interactions, then INP will pick the 98th percentile. A good INP is one under 200 milliseconds, while a poor INP is one over 500ms. Anything in between means that your page needs improvement.

Why is INP important?

Even if Google does not add INP as a Core Web Vital, INP is descriptive of your user's experience on your website. Having a good INP means that your website responds quickly to user input and provides your users with a delightful experience.

A chart demonstrating a negative correlation between JS Long Tasks and Conversion Rate. The more long tasks, the less likely a user is to convert.

The above chart - taken from RUM data from a client of mine - shows a strong negative correlation between JavaScript long tasks and the conversion rate. The median conversion rate for users that experience < 500ms JS long tasks is 38.5%, while users that experience > 4000ms long tasks have a conversion rate of 11.8%. This has a tremendous business impact and is more strongly correlated than any of the Core Web Vitals!

And with INP 2x more correlated to Total Blocking Time (TBT) than FID, we expect to see a similar negative correlation between INP and the conversion rate.

How do you optimize INP?

As INP is correlated well with TBT, you could imply that reducing TBT will reduce your INP.

Minimize main-thread work.
Optimize your JavaScript bundles by code-splitting.
If you are working on a React app, you should minimize hydration and optimize your rerenders.
Audit your third-parties to ensure they aren't bloating your main thread on page load or affecting page responsiveness on user interaction, such as event handlers.

Tooling

The best way to measure INP is to collect metrics from real users. If your website meets the criteria to be included in the CrUX dataset, then you can use the CrUX API's experimental_interaction_to_next_paint field or via BigQuery.

INP is now available on PageSpeed Insights.

You may view INP data using PageSpeed Insights or Treo; however, these still rely on the CrUX dataset.

You can measure the INP metric yourself by using the web-vitals library and sending this data to Google Analytics or another analytics endpoint.

let maxDuration = 0;

new PerformanceObserver(list => {
  for (const entry of list.getEntries()) {
    // Comment this out to show ALL event entry types (useful e.g. on Firefox).
    if (!entry.interactionId) continue;

    if (entry.duration > maxDuration) {
      // New longest Interaction to Next Paint (duration).
      maxDuration = entry.duration;
      console.log(`[INP] duration: ${entry.duration}, type: ${entry.name}`, entry);
    } else {
      // Not the longest Interaction, but uncomment the next line if you still want to see it.
      // console.log(`[Interaction] duration: ${entry.duration}, type: ${entry.name}`, entry);
    }
  }
}).observe({
  type: 'event',
  durationThreshold: 16, // Minimum supported by the spec.
  buffered: true
});

If you're looking to debug INP on your website, you can create a PerformanceObserver and log the longest interaction. Note that this is a simplification of the INP metric and may vary.

INP in the wild

According to the HTTP Archive, only 56.4% of all mobile origins have a good INP. While 95.7% of desktop origins have a good INP.

Technology	Origins	Good INP
ALL	6,754,899	55%
jQuery	5,591,806	57%
AngularJS	85,049	46%
Vue.js	211,468	42%
React	582,000	35%
Preact	183,771	35%
Svelte	8,062	33%

CWV technology report - INP data for May 2022

The above table is extracted from the HTTP Archive as of May 2022, using the CWV Technology Report. Most modern front-end frameworks do poorly in INP, which isn't surprising considering how much heavy-lifting is being done in JavaScript.

Thank you for reading. I would love to hear your feedback and please reach out if you would like to see more correlations involving INP.

Image credits: Photo by David Pisnoy on Unsplash

React Sticky Children

Kevin Farrugia — Mon, 07 Mar 2022 11:07:29 +0000

I created a simple ReactJS plugin react-sticky-children to abstract away the complexities of the IntersectionObserver API and allow you to apply styles to a component as it approaches the top of the viewport. Useful for "Scroll to Top", complex "sticky" elements or animating components into view.

Demo

Usage

import { ReactStickyChildren } from 'react-sticky-children';

<ReactStickyChildren initialStyle={initialStyle} intersectingStyle={intersectingStyle}>
  <MyComponent />
</ReactStickyChildren>

Looking for feedback. 🙏

NPM: https://www.npmjs.com/package/react-sticky-children
GitHub: https://github.com/kevinfarrugia/react-sticky-children

Component Composition in React

Kevin Farrugia — Wed, 23 Feb 2022 08:49:24 +0000

Cross-posted from https://imkev.dev/component-composition

One of the most misunderstood design patterns in a React application is the render props pattern and component composition. While this isn't a new or novel approach and has been promoted since at least 2017, five years later I still encounter opportunities where it should have been used instead of an inheritance hierarchy. Component composition is the technique of combining different modular components to construct another component.

Render Props

"But almost all components are made up of sub-components, so what's so special about component composition?" I hear you say. I distinguish between a regular component and component composition by passing one or more of the sub-components as props to the parent component. These props are known as render props and the most commonly used render prop is the children prop which is included in React by default.

Let's take a look at an example.

import Title from "./Title";

export default function MyComponent({ title, text }) {
  return (
    <div className="container">
      <Title title={title} />
      <p class="text">{text}</p>
    </div>
  );
}

export default function App() {
  return (
    <div className="app>>
      <MyComponent
        title="Random title #1"
        text="Lorem ipsum..."
      />
    </div>
  )
}

Inheritance Demo

The component above might look fairly ordinary. A component MyComponent renders a div element and within it, there are two child elements. One being the <Title> component and the other being a <p> element. MyComponent receives two props, the title and the text component, which it outputs or passes onto the sub-component.

Let's see the same component using the component composition pattern.

export default function MyComponent({ children }) {
  return <div className="container">{children}</div>;
}

export default function App() {
  return (
    <div className="app">
      <MyComponent>
        <>
          <Title title="Random title #1" />
          <p className="text">
            Lorem ipsum...
          </p>
        </>
      </MyComponent>
    </div>
  );
}

Component Composition Demo

In this example, the role of MyComponent is reduced to creating a div element and placing the children prop within the div. The parent component which calls MyComponent is responsible for creating the <Title> and <p> elements. The generated HTML in these two examples is identical.

Single-responsibility principle

When I was still at University studying computer science, amongst the many practices we were taught, there were the SOLID principles. Without going into the merits of the SOLID principles, the S in SOLID stands for the Single-Responsibility principle and states (paraphrasing) that a class or function should only have one reason to change. A class or function should only have one role. I like that. It makes it easier to understand, easier to debug, and makes your code more portable.

The component composition pattern helps enforce this practice as the role of MyComponent in the example above is to only create the div and place the children in the correct place. The role of App is to construct the composition of different components required to build the module. Contrary to the first example, MyComponent is not responsible for choosing the order of the <Title> and <p> elements, and if you would want to change their order, you would need to change MyComponent. This violates the Single-Responsibility principle.

In practice

The above example is very simple and you are unlikely to encounter this scenario in a real-world environment. But the concept could be applied to any component structure.

In addition to displaying and outputting HTML, one of the more common tasks of a React component is to fetch data from a store or an API. Let's compare inheritance and component composition using an example where we are fetching a list of users and then displaying these in a <ul>.

export default function UserList({ quantity }) {
  const [users, setUsers] = useState([]);

  useEffect(() => {
    fetch(`${API_URL}${quantity}`).then(async (response) => {
      if (response.ok) {
        const { results } = await response.json();
        setUsers(results);
      }
    });
  }, [quantity]);

  return (
    <div className="container">
      {users && Boolean(users.length) && (
        <ul className="list">
          {users.map((n) => (
            <li key={n.login.username} className="item">
              <UserCard
                username={n.login.username}
                city={n.location.city}
                profilePicture={n.picture.thumbnail}
              />
            </li>
          ))}
        </ul>
      )}
    </div>
  );
}

export default function App() {
  return (
    <div className="app">
      <UserList quantity={3} />
    </div>
  );
}

Inheritance Data Demo

The UserList component receives a quantity prop indicating the number of items to retrieve from the API. Once the component is mounted, it will make a request, populate the result in the state, and then display a list of UserCard sub-components inside a <ul>.

Let's take a look at the same application if it were following the component composition pattern.

export default function Users({ quantity, children }) {
  const [users, setUsers] = useState([]);

  useEffect(() => {
    fetch(`${API_URL}${quantity}`).then(async (response) => {
      if (response.ok) {
        const { results } = await response.json();
        setUsers(results);
      }
    });
  }, [quantity]);

  return children({ users });
}

export default function App() {
  return (
    <div className="app">
      <Users quantity={3}>
        {({ users }) => (
          <div className="container">
            {users && Boolean(users.length) && (
              <ul className="list">
                {users.map((n) => (
                  <li key={n.login.username} className="item">
                    <UserCard
                      username={n.login.username}
                      city={n.location.city}
                      profilePicture={n.picture.thumbnail}
                    />
                  </li>
                ))}
              </ul>
            )}
          </div>
        )}
      </Users>
    </div>
  );
}

Component Composition Data Demo

The App component now renders a Users component. This component is solely responsible for fetching the users from the API and returning them as a prop to the children using the return statement return children({ users }). Any child component of Users will have access to the users as a prop. The App component iterates through the users it receives and creates the <ul>.

The latter approach allows you to separate fetching data from displaying it. If a change request comes in that requires the data to be filtered before being displayed, you immediately know that you do not need to do any changes to the Users component as the change request does not require changes to the fetching of data. Demo

Multiple Render Props

While in many cases you can use the children prop included in React, in some cases you may need to place multiple sub-components that will not be rendered beside each other in the DOM. In these cases, you may define further render props similarly to how you would assign an ordinary prop. The only difference is that you pass a component.

export default function MyComponent({ headerFn, children }) {
  return (
    <>
      <div className="header">{headerFn}</div>
      <hr />
      <div className="container">{children}</div>
    </>
  );
}

export default function App() {
  return (
    <div className="app">
      <h1>Component Composition</h1>
      <MyComponent headerFn={<Title title="Random title #1" />}>
        <p className="text">
          Lorem ipsum...
        </p>
      </MyComponent>
    </div>
  );
}

In this simple example, we have added headerFn prop to MyComponent and passed <Title title="Random title #1" /> to it. MyComponent is only responsible for the DOM structure and placing the correct CSS classes, while App is responsible for defining the components to be rendered.

Conclusion

The component composition pattern can simplify your applications, making the code more portable, maintainable, and DRY. Once you become accustomed to this pattern, it is easy to apply it in almost any situation you would have previously used inheritance.

I hope this helped convince you to make use of component composition more often. If you're not yet convinced, ReactJS docs go as far as to say that they haven’t found any use cases where they would recommend creating component inheritance hierarchies and Michael Jackson has a fantastic video (one of many) on this topic Never Write Another HoC.

Thank you for reading. Have a good one! 👋

Image credits: Photo by Ricardo Gomez Angel

React Router and nested routes

Kevin Farrugia — Wed, 02 Feb 2022 09:50:40 +0000

Cross-posted from https://imkev.dev/react-router-nested-routes

Following the public launch of Remix v1, nested routes have become all the rage - at least within my tiny corner of cyberspace. But what are nested routes, why are they meaningful, and how can you use nested routes in your React app?

React Router

Nested routes have existed in React Router since very early on - heck, it was initially named react-nested-router. Now on version 6, React Router is one of the most popular React packages and will be used throughout this post to demonstrate the concept of nested routes. I will also include React Router v5 code samples and demos but, I will refer to the v6 version when explaining the code.

Nested routes

In my own words, a nested route is a region within a page layout that responds to route changes. For example, in a single-page application, when navigating from one URL to another, you do not need to render the entire page, but only those regions within the page that are dependent on that URL change.

In the wireframe above, when clicking on a header link (4), the main content (1) will be rendered to show the content for this route, while the header remains unchanged. Similarly, when clicking on the left navigation links (2), the page's content section (3) will update to show the new content, but the header, footer, and navigation menu remain unchanged.

This layout could be implemented in several ways.

export default function App() {
  return (
    <div className="app">
      <BrowserRouter>
        <Routes>
          <Route path="/catalog/:id" element={<Catalog />} />
          <Route path="/catalog" element={<Catalog />} />
          <Route path="/welcome" element={<Welcome />} />
          <Route index element={<Home />} />
        </Routes>
      </BrowserRouter>
    </div>
  );
}

Flat routing structure - v6 | Flat routing structure - v5

In the above flat structure, we have four routes declared in a single file. /catalog/:id and /catalog would render the <Catalog> component which includes the left navigation and the content area. If the :id param is present, then it would show the content for that :id, if not it would show some default content. /welcome shows a welcome message and the final catch-all route shows the home page, including the <Header> and <Footer>.

Navigating between the different routes would cause the main section (1) to render with the updated content. This includes the <Header>, <Footer>, and <Nav> - even if they are not changing. If you play around with the demo, you will probably feel that it works well, is snappy and there are no glaring bugs. This routing structure is fairly common and I have personally encountered it numerous times on production. However, this structure is not optimized and when navigating from one URL to another, the CPU is doing a lot of work that it doesn't need to. In our example this overhead is negligible, but on a more complex application, it may result in visible jank & deteriorate the user experience.

To make re-renderings more apparent, I have added the following code snippet but initially left it commented out. If you are sensitive to flashing images, please use caution.

  React.useLayoutEffect(() => {
    if (ref && ref.current) {
      ref.current.style = "background-color: #fa9a9a;";

      setTimeout(() => {
        ref.current.style = "background-color: none;";
      });
    }
  });

Let's get nested

The above routing structure could be optimized by using nested routes to avoid rendering components that have not changed. As a default rule, we only want to render what has changed. When a user clicks on the left navigation links, the only component we want to render is the content section. Similarly, when a user clicks on a header link, we only render the main section.

export default function App() {
  return (
    <div className="app">
      <BrowserRouter>
        <Routes>
          <Route path="/welcome" element={<Welcome />} />
          <Route path="*" element={
            <Header />
            <Routes>
              <Route path="/catalog/*" element={
                <div className="two-column" ref={ref}>
                  <Nav />
                  <div className="content">
                    <Routes>
                      <Route path=":id" element={<Content />} />
                      <Route
                        index
                        element={<p>Use the left nav to selet a catalog item</p>}
                      />
                    </Routes>
                  </div>
                </div>
              } />
              <Route index element={<Home />} />
            </Routes>
            <Footer />
          } />
        </Routes>
      </BrowserRouter>
    </div>
  );
}

Nested routes (v6) | Nested routes (v5)

Instead of having three routes on a single level, we now have six routes spread over three levels. At the topmost level, we have two routes, path="*" and path="/welcome". These two routes were separated because the <Header> and <Footer> are not visible on the <Welcome> page.

On the second level, we have two routes, path="/catalog/*" and index. These are used to render the <Catalog> or <Home> respectively. As you can see in the code snippet above, the <Header> and <Footer> are included in the element attribute for path="*" instead of being declared within <Catalog> and <Home> as we had done in the flat-structure.

Finally, on the inner-most level, there are two more routes. The first path exposes the :id param with path=":id". Since this route is a nested route of path="/catalog/*", then the path is built onto its parent's, matching in /catalog/:id. The index route is used when no :id is present.

If you experiment with the demo, you will see that each component is only rendered when needed, making this solution much more optimized than the one we saw earlier. I love it!

Conclusion

Nested routes aren't a new concept. If I remember correctly, I was using some form of nested routes way back in 2009 on C#'s MVC framework (it's been a while so let me know if I'm mixing things up). Yet I still encounter cases when developers opt for a flat structure when nested routes would be the better solution. While I believe that nested routes could help you today, I expect that nested routes would become even more important in the near future, with concepts such as Islands Architecture and frameworks like Remix gaining traction. Give it a go and you won't turn back.

Thank you for reading & have a good one!

Image credits: Photo by Jamie Morrison

Should you optimize every re-render?

Kevin Farrugia — Tue, 07 Dec 2021 10:35:35 +0000

Cross-posted from https://imkev.dev/optimizing-rerenders

One of the more frequent discussions I have with my colleagues is whether we should be investing the effort to optimize a React re-render (re-render).

React determines which components need to be re-rendered during the render phase. During this phase, React traverses the current Fiber tree and creates a list of effects that need to be applied to the Fiber nodes. The current tree reflects the state of the application that was used to render the UI. As React processes effects, it clones the current tree and performs these updates on the current tree, resulting in a new workInProgress tree. Once all updates are processed, React will flush the workInProgress tree to the DOM and this will become the current tree. If you're interested in more detail, I cover the React Reconciliation algorithm in a separate post.

A render is usually required whenever your props or state change.

const MyComponent = React.memo(({ data }) => {
  return (
    <ul>
      {data.map((n) => (
        <li key={n}>{n}</li>
      ))}
    </ul>
  );
});

In the example above, if data changes, then we need to re-render the component with the latest values so these changes are reflected on the screen. Since we know that the component's output is dependent on data, if data does not change, then there is no need to recalculate the output as that is also unchanged. This allows us to use React.memo or React.PureComponent.

What we do not want, is to re-render the component when data does not change. This is what I refer to as an unnecessary re-render.

Not all re-renders are bad

Not all re-renders are equal. Some re-renders are more CPU intensive than others. You may debug React re-rendering using the React Profiler Chrome extension.

{.centered}

The left column shows which components have been re-rendered, while the right column shows you how many times the component has re-rendered. Each re-rendering also includes the component's self-time - the time it takes to execute the render() method for that component.

In most cases, the time spent rendering each component is a few milliseconds. This has led to the argument that not all unnecessary re-renders are bad; a statement I have to disagree with*.

While not all re-renders are equally important, I believe that all unnecessary re-renders should be eliminated to improve your applications reliability.

const ClickCounter = () => {
  const [count, setCount] = useState(0);

  const handleClick = () => {
    setCount(count + 1);
  };

  return (
    <>
      <button onClick={handleClick}>Update counter</button>
      <Counter count={count} />
      <MyComponent data={["A", "B", "C"]} />
    </>
  );
};

Demo: /src/ClickCounter.js {.caption}

Whenever count is updated, MyComponent will be re-rendered, even if it is not dependent on count. This is caused as you are passing a new array reference on each render.

["A", "B", "C"] === ["A", "B", "C"]; // false

The correct solution would be to create a constant and place it outside of the ClickCounter component.

const data = ["A", "B", "C"];

const ClickCounter = () => {
  const [count, setCount] = useState(0);

  const handleClick = () => {
    setCount(count + 1);
  };

  return (
    <>
      <button onClick={handleClick}>Update counter</button>
      <Counter count={count} />
      <MyComponent data={data} />
    </>
  );
};

Demo: /src/ClickCounter.js {.caption}

This no longer renders MyComponent whenever the user clicks on the button to update count. But how much faster is our application following this optimization? Most likely, the improvements are negligible. So does this mean you shouldn't bother optimizing your re-renders?

const data = ["A", "B", "C"];

const Demo = () => {
  const location = useLocation();

  return (
    <>
      <span>{location.pathname}</span>
      <ul>
        <li>
          <MyComponent data={["A", "B", "C"]} />
        </li>
        <li>
          <MyComponent data={data} />
        </li>
      </ul>
    </>
  );
};

Demo: /src/Demo.js { .caption }

In the example above, we have two instances of MyComponent; one which re-renders on each render and one which is correctly optimized. The Demo itself component will render whenever location changes, using the useLocation hook from React Router.

In most cases, these two components will behave identically. But in the first MyComponent, there is the premise for obscure bugs which would be hidden by causing the component to needlessly re-render.

const MyComponent = memo(({ data }) => {
  const location = window.location;

  return (
    <>
      <span>{location.pathname}</span>
      <ul>
        {data.map((n) => (
          <li key={n}>{n}</li>
        ))}
      </ul>
    </>
  );
});

Demo: /src/MyComponent.js { .caption }

If the rendered output of a component is dependent on more than its props, then needlessly re-rendering the component may hide this issue. In MyComponent, the rendered output includes the location.pathname, which would change whenever the URL changes. If the component does not re-render, then the updated location.pathname would not be visible on the screen. As a result, the MyComponent which needlessly re-renders would reflect this change on the next render, while the optimized component would not.

const MyComponent = memo(({ data }) => {
  const location = useLocation();

  return (
    <>
      <span>{location.pathname}</span>
      <ul>
        {data.map((n) => (
          <li key={n}>{n}</li>
        ))}
      </ul>
    </>
  );
});

Of course in this example, we are simplifying things greatly and the issue is both easy to find and fix. However, from my experience, sometimes these bugs could go unnoticed for a very long time, making them very difficult to debug and eventually resolve.

Other unnecessary re-renders

There are other forms of unnecessary renders. Similar to the new array reference, passing an object or a function will cause the component to re-render.

return <MyComponent data={{ title: "Title" }} />;

This could be mitigated by either placing the object outside of the component's render method or memoizing the prop using React.useMemo. The latter is usually required if the prop is dependent on other prop or state variables.

return (
  <MyComponent
    onClick={() => {
      doSomething(a, b);
    }}
  />
);

React includes React.useCallback which returns a memoized callback function.

const onClickHandler = React.useCallback(() => {
  doSomething(a, b);
}, [a, b]);

return <MyComponent onClick={onClickHandler} />;

Passing a React component as a prop will have a similar effect.

const Demo = () => {
  return <MyComponent header={<Header />} />;
};

And once again, the recommended solution is similar.

const Header = <Header />;

const Demo = () => {
  return <MyComponent header={Header} />;
};

Conclusion

While the performance improvements from optimizing every render may not always be significant, maintaining a pure codebase makes your work more predictable. If the output of every component is dependent on its inputs, then you minimize the risk of unwanted side effects. And you also get good performance "out-of-the-box".

Let me know what you think. 🤙

Getting your HTTP Cache-Control headers right

Kevin Farrugia — Mon, 29 Nov 2021 14:04:12 +0000

Cross-posted from https://imkev.dev/cache-control

Caching plays a fundamental role in performance. What's quicker than a fast request? No request. Getting your caching strategy right can make a huge difference to your users - both repeat and first time.

"There are only two hard things in Computer Science: cache invalidation and naming things." (Phil Karlton)

25 years later, this well-known saying still holds true and while I cannot help you with the naming, I want to share what I know about caching to make it easier for you to decide on a caching strategy. Disclaimer: The scope of this article isn't to serve as a comprehensive guide to all possible caching strategies and how they work - there's already plenty of content like that around. My goal is to provide you with a reference which you could use to answer the question, "How should I cache this resource?"

What is caching?

A cache is a store where you could put a resource. This could be done to avoid having to recalculate an expensive computation or to place the content closer to the user. In websites, this is dictated by the Cache-Control header; which is defined in the HTTP/1.1 specification.

Note: The Expires header is no longer needed as its behavior is covered by the Cache-Control header.

Private and shared caches

In addition to caching in your browser, if your content is behind a CDN then your cache-control headers influence how the CDN caches your content on the edge. Browser cache is referred to as a private cache, while a CDN cache is referred to as a shared cache. The cacheability of a resource is set using the directives below:

public - Any cache may store the response, including a CDN.
private - The response is intended for a single user and should only be stored by the browser cache.
no-store - Should not be stored on any cache.

Demo

To test the different cache-control headers, I have created a repository containing a simple NodeJS server. Please feel free to explore the source code on GitHub and run the application locally.

Static assets

Static assets refer to files whose contents do not change and are not generated on request. This includes scripts, stylesheets, and images. As these files are generated at build time, most modern build tools can assign a unique hash to each file. This hash serves as a unique fingerprint for each version of the file and is included in the resource's URL. This could be in the form of a query string parameter (e.g. app.js?v=c4d27698), or filename (e.g. index-0e6a410d.js). Having a unique URL means that you can cache these assets for a very long time, even up to one year.

cache-control: max-age=31536000

When the website is redeployed and the contents of one of the source files have changed, then it will be assigned a new URL and create a new cache entry. If the files are served through a CDN, then the CDN will cache this file. Most CDNs will purge the old files on each redeployment.

Freshness - Guaranteed.
Performance - First user to request the file will receive it from the origin server. Every other user will receive a cached copy.

Caching the HTML page

One of the major headaches with caching is your HTML page. Generally speaking, your HTML page will make requests for other resources which are needed to render the page, such as CSS, images and JavaScript files. Whenever your website is redeployed, it will update the references to the static assets within the HTML document.

<link rel="stylesheet" href="/style.v1.css" />

becomes

<link rel="stylesheet" href="/style.v2.css" />

So if the HTML document is cached, users with a cached copy will request the old stylesheet, style.v1.css; which no longer exists on the origin server. So while style.v1.css is likely to be cached on the user's browser because of its long expiry, it is possible that some users encounter a broken website too. If the cached resource style.v1.css is removed from the cache before the cached HTML resource, the user will see a broken layout.

To complicate matters, your HTML may also contain server-side rendered content retrieved from a CMS. If the content is updated on the CMS, the cached HTML is now stale.

Scenarios

When deciding your caching strategy, it is usually a trade-off between performance and freshness. Instead of explaining the different cache-control directives and their applications, I will be describing some real-life scenarios I worked with and how I would set my cache-control headers for that type of website.

Blog

If you are looking to cache your blog, the chances are that the content is not time-sensitive and you would prioritize performance over freshness. Users are more likely to go directly to the article page instead of navigating through the website. If they revisit your blog, they are likely to return when a new article is published - that is after the cache has expired. The CSS and JavaScript files probably do not change that often either.

cache-control: public, max-age=600, stale-while-revalidate=60

The blog you're reading uses a public, max-age, and stale-while-revalidate combination. By applying a max-age of 600 (10 minutes), you can cache the page for the duration of the user's session. If they leave the page and return within 10 minutes, it would load instantly.

The public directive states that the resource may be cached on both private and shared caches. Therefore if the resource has expired in the user's browser cache, it would request it from the CDN. The CDN may have the resource cached and serve it instantly. If it has expired on the CDN, then it would fetch it from the origin and update the caches.

Using stale-while-revalidate means that the resource can be served stale for an additional 60 seconds after it has expired while it is being revalidated.

In my specific case I am able to cache the HTML file rather aggressively as I ship very little JavaScript - none of which is critical to the user experience - and the critical CSS is inlined in the HTML file. Depending on how important your subresources are to the user experience, you may want to cache for a shorter period. If your blog does not work at all without JavaScript, then you might want to reduce the max-age to avoid the race condition described earlier.

Freshness - Users may receive a worst-case 11-minute old response.
Performance - The first user to request the resource will wait for it to be fetched from the origin. If the user returns within 11 minutes, they will receive a cached response. If they return after 11 minutes, they will be served a cached copy from the CDN. If no users visit the website for 11 minutes, the first user to visit the website will wait for the resource to be fetched from the origin.

News website

A news website is updated frequently, with new articles being added to the home page and the content of some articles updated several times per day.

cache-control: public, max-age=30, stale-while-revalidate=30, stale-if-error=600

By applying a combination of max-age, stale-while-revalidate, and stale-if-error you can always serve content quickly while minimizing the risk of stale data. Resources will be cached on shared or private caches for 30 seconds. When the resource expires, the cache will serve the stale data for another 30 seconds. The stale-if-error directive indicates that if the origin server does not respond when revalidating the resource, the cache may serve the stale data for another 10 minutes.

Note: The stale-if-error directive isn't widely supported on the browser but is supported on most CDNs.

Freshness - In the worst case, the user may receive a 1-minute old response. The max-age and stale-while-revalidate values may be adjusted to calibrate this worst-case scenario.
Performance - The first user to request the resource will wait for it to be fetched from the origin. If the same user or any other user revisits the page within 30 seconds, they would get a cached response. If they visit the page beyond 30 seconds but within 60 seconds, then they would get an instant (stale) response while the cache is revalidated. If they revisit the page beyond 60 seconds, then the resource is fetched from the CDN. If no user visits the page for 1 minute, the next user will fetch the resource from the origin.

Live event

If your website is showing a live event and content is updated frequently, you want the data to be as fresh as possible. An example of a live event may be a sports match showing real-time scores or an election results page.

cache-control: public, no-cache

Setting no-cache indicates that a cache must not be used for a subsequent request without revalidating it with the origin server. This is the equivalent of must-revalidate, max-age=0. Once again, setting public will enable your CDN to cache the resource and avoid hitting your origin server for each user request.

Freshness - Users will always receive a fresh resource.
Performance - Each request will incur a network call. If the resource has not changed, then the payload would only include the response headers.

Logged-in pages

Any page or resource which is only available for a logged-in user or contains data specific to a logged-in session should not be cached.

cache-control: no-store

Freshness - Users will always receive a fresh resource.
Performance - Each request will be fetched from the origin.

Conclusion

HTTP Cache-Control headers remain a cornerstone for good performance. When choosing a caching strategy, take your time to consider the following:

Not all resources are equal.
Measure the performance gains a user would benefit from if you cache a resource.
Can you get away with serving stale content?
Identify how likely your cached resources may become out of sync and what your users would experience in that eventuality.

Code-splitting is hard

Kevin Farrugia — Tue, 17 Nov 2020 11:02:47 +0000

Occasionally code-splitting and chunking is avoided as a performance optimisation because it is thought of as complex or "black-magic". I hope to address those fears, because in most cases code-splitting could be done with relative ease and may reward you with considerable gains; especially for apps which are heavily reliant on JavaScript.

The hardest part about code-splitting may be deciding on how to split your code & bundles. This is not convered in this article, but there is lots of material on this topic. You may want to read: Improved Next.js and Gatsby page load performance with granular chunking or The 100% correct way to split your chunks with Webpack

The code for this demo is available on GitHub. Contributions & feedback are always welcome.

The demo is built using Webpack and ReactJS, using React.lazy route-based code-splitting and react-router-dom.

Will stylesheets be bundled in separate chunks?

If one or more stylesheets are imported in a single module or its dependencies, then a reference to the bundled stylesheet will only be included in that module's chunk. For clarity, a chunk may consist of more than one file (JS & CSS).

In our example, Page1 imports a stylesheet:

  import styles from "./style.scss";

As it is the only file which references this stylesheet, then it will be chunked. Additionally, Page1 is the only module which imports the Glider component; which in turn imports another two stylesheets and also has a dependency on the third-party glider-js.

src/js/components/glider/index.jsx

  import "glider-js";
  import "glider-js/glider.min.css";

All these will be included in a single chunk, together with the output of style.scss above.

On the contrary, if a stylesheet is imported in more than one module, then the bundler will output a single stylsheet referenced by both modules.

In our example, Page2 imports a shared stylesheet:

  import sharedStyles from "../home/style.scss";

This stylesheet is also imported in the Home module and therefore is not included in the Page2 chunk.

What about images?

By design, images are only downloaded when needed and present in the DOM. This means that images should have no impact on your bundle sizes.

If you are importing your images using file-loader's esModule then you will also benefit from module concatenation and tree-shaking on your images; but this is not specifically code-splitting.

However, if you are using url-loader and your images are being encoded into Base64 or SVG strings, then they will be encoded into each chunk resulting in duplicate code.

May I use CommonJS imports?

Yes, CommonJS & ES6 module imports work equally well.

In our example, in Page2 the below two lines would result in equivalent chunks:

  const styles = require("./style.scss");
  //import stylesfrom "./style.scss");

When using route-based code-splitting, is it possible to have some routes lazy-loaded while others loaded regularly?

Yes, definitely.

In this demo, the Home module is loaded regularly while the other pages are loaded lazily.

  import Home from "../home";
  const Page1 = React.lazy(() => import("../page1"));
  const Page2 = React.lazy(() => import("../page2"));

  <Suspense fallback={null}>
    <Switch>
      <Route path="/1" exact>
        <Page1 />
      </Route>
      <Route path="/2" exact>
        <Page2 />
      </Route>
      <Route>
        <Home />
      </Route>
    </Switch>
  </Suspense>

Does code-splitting work with named exports?

React.lazy requires you to have a default export, however you may still use named exports for other components, even for those which are being referenced by the lazily loaded component.

What about re-exporting? Will `export * from "./my-module"` be tree-shaken?

Using export * from "./my-module" means that any export in ./my-module, regardless of whether it is used or unused, would need to be evaluated and executed in case one of those exports has side-effects. As a result, you need to explicitly inform Webpack that the file has no side-effects using the sideEffects package.json property. Sean Larkin has an excellent explanation on Stack Overflow.

The example code in our demo includes a component Page3 which exports an unused component ../glider-named-export. Without sideEffects: false, the resultant chunk includes the contents of ../glider-named-export, even if it is never actually being used.

Does this work with critical (inlined) CSS?

Yes it does.

The configuration used in this demo inlines a single critical CSS file which includes all critical CSS defined across the project. This is done using the following code inside scripts/webpack.config.js:

criticalStyles: {
  name: "critical",
  test: /critical\.(sa|sc|c)ss$/,
  chunks: "initial",
  enforce: true,
}

The output of this chunk is then inlined in src/templates/index.hbs:

<% if (/critical(\..*)?\.css$/.test(htmlWebpackPlugin.files.cssindex])) { %>
  <style>
    <%= compilation.assets[htmlWebpackPlugin.files.cssindex].substr(htmlWebpackPlugin.files.publicPath.length)].source() %>
  </style>
<% } %>

Will users have to wait to download the chunks on successive routes?

In theory yes, because these files were not downloaded yet and will only be downloaded once the user requests them by visiting the page; but this could be mitigated through the use of a service-worker precache which will download the remaining chunks after the initial page load.

In the demo I am using the highly recommended WorkboxPlugin:

new WorkboxPlugin.InjectManifest({
  swSrc: `${ROOT_DIR}/src/sw.js`,
  swDest: "sw.js",
  include: [/\.js$/, /\.css$/],
})

Thank you for reading and please leave me your feedback. As always, it would be very welcome & appreciated. If you want to get in touch, you could reach me on Twitter @imkevdev.

Loading CSS - Web Performance Cheatsheet

Kevin Farrugia — Fri, 25 Sep 2020 12:23:04 +0000

As part of my role as a web performance consultant, I constantly need to test two (or more) versions of a website and compare the resultant performance. Since performance isn't a single clearly defined metric and is comprised of a host of other metrics, each measuring different aspects of the loading experience, including page load, start render, LCP (largest contenful paint), FCP (first contentful paint), FID (first input delay), CLS (cumulative layout shift)...etc; very often the tests don't have a clear and absolute winner, "This is the fastest!"

This is not a unique problem to the website I am working on. As your users are likely to be distributed over a wide range of devices & varying network conditions, what might improve the performance for one user may degrade it for another. There are other factors too, for example some websites may have a larger segment of users visiting the website in Incognito or Private Browsing. Ultimately, to get the most accurate picture of your users' experience, you should make use of RUM (Real User Metrics). If your website receives enough visitors, you can access this data on Chrome UX Report. If not, you would need to collect this data yourself using tools such as SpeedCurve (paid) or Google Analytics.

This does not discard the importance of lab tests and very often, well-prepared tests can give a good indication of the expected behaviour for real-users once the changes are deployed to the production environment. On occassion, I also need to re-evaluate some decisions which were taken weeks or months earlier; sometimes due to the evolution of business requirements but more commonly due to changes to the website's code (ex: shipping more JavaScript, less images...etc). I therefore felt the need to create a reference which helps address my two needs:

Remind me how each test compares to another.
Helps me explain why one solution was preferred over another and why the preferred solution may have or have not changed.

Loading CSS

I created a GitHub repository where I will be adding different test cases together with sample code & test results from WebPageTest. Please feel free to contribute & leave feedback. The repository is also deployed on kevinfarrugia.github.io/performance-test-results-cheatsheet

Initially I only have a number of test cases where I compare the performance of different strategies to load CSS assets.

Inline CSS - Instead of only inlining the critical CSS, all the webpage's CSS is combined into a single CSS file of 22.0KB. Consequently, there are no requests for external CSS files.
Render-blocking CSS - Possibly the most "old school" way of loading CSS from the test cases. The CSS is combined into a single 22.0KB file and downloaded using an ordinary <link rel="stylesheet" type="text/css" href="main.css" /> placed inside the <head>
Inline critical CSS - Only 1.4KB of critical CSS (used above-the-fold) is inlined inside the <head> while the remaining 21.4KB of CSS (bottom.css) is downloaded asynchronously using the media="print" trick. The remaining CSS also contains some minor styling which marginally impacts the view above the fold.
Inline critical CSS & preload - Similarly to above, except the remaining 21.4KB of CSS are preloaded using the resource hint <link rel="preload" href="bottom.css" as="style" />
preload to render-blocking CSS - Similarly to the render-blocking test case above, except the CSS file main.css is preloaded using <link rel="preload" href="main.css" as="style" />

Test Results

All tests were done using the Moto G4 - Chrome - 3G Fast browser preset on WPT. You may follow this link to access the data behind the test results described below.

As seen in the video above, the first pages to show any content are the inline-critical-css and inline-css and as a result they are the quickest to Start Render.

Interestingly, the page which inlines all the webpage's CSS still performs at-par with the one which only inlines the critical CSS, even if it needs to download more HTML (24.6KB). It is recommended to keep the initial HTML file under 14KB because of TCP's slow start, however we do not see that as holding true for our tests. 🤷

The next page to start rendering content to screen is the preload-inline-critical-css, slightly behind the equivalent without preloading bottom.css. Taking a look at the waterfall, it is clear that the cause for this delay is the preloaded file taking priority over critical resources, in this case the JavaScript file critical.js.

In the meantime, the first page with all CSS inlined has downloaded the image and is visually complete. A few milliseconds later, render-blocking-css paints to the screen for the first and last time. Therefore, when compared to inlining CSS (critical or all), it takes significantly longer to begin painting to screen and as a result the user is unaware if the page is loading and cannot see any content until all HTML & CSS is downloaded & parsed (images may still load afterwards).

The identical same results are observed for the preload-render-blocking-css page because the CSS file is already located in the head and treated with HIGHEST priority, therefore preloading it will not give you and performance improvements. In the video, it is coincidentally slightly slower because of a slower TTFB of the server; which is unrelated to the test itself. Successive tests registered identical results as without the preload hint.

And finally the inline-critical-css page is visually complete once the bottom.css is downloaded and applied. As a result, this page is the one which incurs the largest (albeit not significant) layout shift and scores the highest (lower is better) score for CLS.

Conclusion

I hope you found these tests interesting and perhaps learnt something new. Personally I always like to test any hypothesis, even if it is something that I have been doing almost instinctively and then use the test results to understand why the page is faster or slower. Feel free to get in touch if you would like to contribute or suggest new tests, have feedback on the above or anything else web performance related really. Thank you for reading and stay safe.

Should I host two websites on a single domain?

Kevin Farrugia — Wed, 05 Aug 2020 08:57:09 +0000

I have two websites, one for mobile and one for desktop (i.e. this is not a responsive website). Both websites show similar (not identical) content for the same routes, so going to /about-us for each site would show the same content (80-90% similar, main content identical but peripheral content might change) within a different HTML structure.

Ordinarily, I would setup one website on m.mydomain.com and the other on mydomain.com. However we have been looking into using the same domain (no subdomains) for both websites.

A load-balancer would send the traffic to the respective server based on the user-agent (to recognise mobile/desktop traffic). This might seem similar to what Amazon.com does (not aware of the internal workings)

Is this setup a good idea or is it going to lead to problems?

Pros:

An improved user experience (debatable)
Possibly improved SEO as only a single website is indexed

Questions:

Will there be caching issues since assets are different? What about service-workers?
What about redirects? If one of the websites has a 301/302 redirect that is cached.

React Reconciliation Rendering Order

Kevin Farrugia — Mon, 03 Aug 2020 11:14:42 +0000

Cross-posted from https://imkev.dev/react-rendering-order

I was recently asked to measure & track the performance of a React component (and all its sub-components) as part of a huge refactoring project the company had undertaken. In a nutshell, we wanted to track how long the component takes until its rendering is complete. Since the component was made up of a number of smaller sub-components, many of these connected to the Redux store and fetching data asynchronously, it was important to understand how the React rendering algorithm works. I have already written about my learning experience when measuring the time each component takes to render which goes into greater detail about the algorithm itself; while this blog post takes a very simplified and high-level overview of the order in which components are rendered and re-rendered using examples.

Demo

To demonstrate the order in which React components are rendered, we have created a simple component tree and tagged each component with a unique ID.

<Component id="A0">
  <Component id="B0" />
  <Component id="B1">
    <Component id="C0" />
    <Component id="C1" />
  </Component>
  <Component id="B2" />
</Component>

By adding a React.Profiler component to each Component we are able to measure when each component renders. The sequence for the above component tree is

This is because the React reconciliation algorithm follows a depth-first traversal to beginWork and a component's rendering is complete (completeWork) only once all its children's rendering is complete. As a result, the root component in your tree will always be the last one to complete render.

You may experiment with the source code if you wish.

But what about connected components & async rendering?

Very often (as was our case) components and sub-components are connected to Redux store or asynchronously fetching data from an API. In some cases, we are also using the render prop technique, in which case data is fetched by a parent component and then passed down to its children. In these cases, how does the React reconciliation algorithm behave?

<Component id="A0">
  <Component id="B0" />
  <Component id="B1">
    <Component id="C0" />
    <Component id="C1" />
    <RenderProps id="C2" timeout={2000}>
      {prefix => (
        <>
          {prefix && (
            <Component id={`${prefix}D0`}>
              <Component id={`${prefix}E0`} />
              <Component id={`${prefix}E1`} />
            </Component>
          )}
          <Component id={`${prefix}D1`} />
        </>
      )}
    </RenderProps>
    <Container id="C3" timeout={1000}>
      <Component id="D2" />
    </Container>
  </Component>
  <Component id="B2" />
</Component>

In the above example, Container simulates a component which fetches data asynchronously, while RenderProps simulates a component which fetches data asynchronously and then passes this to its children as a prop (prefix); some of which render conditionally based on its value (initially false). In both cases, the timeout prop is used to define how long the asynchronous event would take until the data is "fetched" and it is only there for demonstration purposes as it has no impact on our test.

Similarly to the previous example, we are able to determine when each component finishes rendering thorugh the use of React.Profiler. Initially, the components will render based on the same rules as above, depth-first traversal and all children must complete render.

After 1000ms, the component C3 should resolve its asynchronous event as its data is fetched. As a result, it is re-rendered, together with its parents nodes until A0. Therefore, the order of this re-render is:

Note that only the parents of C3 are rendered, while its siblings and children do not re-render.

Another 1000ms later and component C2 now resolves. Similarly to C3, its data is fetch and re-rendered. Additionally, it will also pass the render prop prefix to its children and the conditional render is now truthy. The resultant render complete order is as follows:

As can be seen, when using render props, in addition to having the parent components render, all children are re-rendered - with same rules as the each render, depth-first traversal and all children need to complete for the parent to complete.

You may experiment with the source code for the above example too.

So which is the last render?

Using the above information, we were able to confidently say that the entire component tree is ready from rendering when our root node (A0 in the example above) has rendered for the last time. Unless within a finite amount of time, measuring the "last" of anything is difficult as on each iteration you do not know if there will be a successive one. To solve this, we looked and imitated how Largest Contentful Paint works, as it has a similar challenge (how do you know an element is the largest if you don't know what's coming next?). Ultimately, the solution was relatively straightforward as we created a performance.mark for each render of our root component. The last mark is the last render and each previous mark was the last render until that point.

window.addEventListener("unload", () => {
  // get the last performance.mark entry
  const data = performance.getEntriesByName("lastRender")[performance.getEntriesByName("lastRender").length - 1];
  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.
  (navigator.sendBeacon && navigator.sendBeacon('/analytics', data)) ||
      fetch('/analytics', {data, method: 'POST', keepalive: true});
});

The final piece of the puzzle was to send this data to the performance monitoring tool we were using. In our case it is SpeedCurve, which provides an API; but the same approach used by SpeedCurve works for Google Analytics or other RUM tools. Using the non-blocking sendBeacon() API on unload and on history change (if your app is a SPA); you could POST the timings of the last performance.mark to an endpoint.

And that's a wrap 🌯. Thank you for reading and shout out to @maxkoretskyi for his fantastic articles on the topic.

Inlining Critical CSS

Kevin Farrugia — Wed, 29 Jul 2020 10:12:11 +0000

Cross-posted from: https://imkev.dev/inlining-critical-css

During a recent (highly recommended) talk by Addy Osmani as part of Chrome's web.dev/live event, Addy explains how Chloé optimised their website for performance and Google's core web vitals. There are a lot of great takeaways from the talk, some of which could be implemented into your own project relatively easily; however one technique stuck out slightly for me.

To dynamically generate the critical CSS we developed a script that runs at build-time extracting all the CSS blocks containing the custom critical: this property and inlining them in the head of the page. The inlined CSS rules are removed from the original CSS files, which are loaded with low priority using the media=’print’ technique.

The above is taken from the case study from Chloé’s engineering blog.

The goal of inlining critical CSS is to prevent a flash of unstyled content (FOUC). CSS is a render-blocking resource, meaning that it needs to be downloaded and parsed to create the CSSOM. This is then combined with the DOM to create the render tree, which is used to layout the different elements and feed the paint process which ultimately outputs the pixels to the screen. Having a single large CSS file will delay the start render, as all CSS, regardless of whether it will be used or not will have to be downloaded. Inlining the CSS, will also avoid a network request to download the CSS file.

So can I inline all my CSS?

Nope. You should try to keep your initial HTML + CSS under 14KB. Why?

Unfortunately, stylesheets do not support the async attribute, as <script> do and a variety of different approaches to asynchronously downloading the stylesheets have been implemented. The simplest and widely supported approach is the media="print" technique quoted earlier. It might seem ugly, but it works well.

Therefore, given the following SCSS file:

/* this bit is critical */
.list {
  width: 100%;
  padding: 0;
  margin: 0;
}

/* this bit is not critical as it only shows after user interaction or is below the fold */
.list-item {
  position: relative;
  display: block;
  padding: 1em;
  border-bottom: 1px solid rgba(0, 0, 0, 0.05);

  &:hover .remove {
    opacity: 1;
  }
}

We would expect it to output critical CSS and a media="print" link to the remaining stylesheet.

<head>
  ...
  <style>.list {width: 100%; padding: 0; margin: 0;}</style>
  <link rel="stylesheet" href="/style.css" media="print" onload="this.media='all'">
</head>

What's this magic?

The Chloé engineering team developed a script that extract the CSS blocks marked with critical: this. I have seen similar scripts which worked by extracting blocks prefixed by // !critical or extracting CSS which is generated on the server-side as critical (in the case of universal applications). There are also npm modules which generate the critical CSS using puppeteer, such as penthouse.

But in most cases, I prefer something simpler and I am able to achieve the similarly good results through a simple webpackconfiguration using chunking and HtmlWebpackPlugin. For starters, I separate critical and non-critical CSS into two SCSS files. From experience, a module would either be critical or not (for example a hero banner may be treated as critical) and all its SCSS should belong in one file anyway. Webpack is then configured to extract all SCSS from files named critical.scss into a separate chunk.

  optimization: {
    // ...
    splitChunks: {
      // ...
      cacheGroups: {
        criticalStyles: {
          name: "critical",
          test: /critical\.(sa|sc|c)ss$/,
          chunks: "initial",
          enforce: true,
        },
        // ...
      },
    },
    // ...
  }

The resultant CSS file (using MiniCssExtractPlugin) then needs to be injected into our HTML using HtmlWebpackPlugin. This requires that HtmlWebpackPlugin is configured with the option inject: false so that we can create our own HTML output. We then add a condition to output the contents of the chunk and thus inline our critical CSS.

<% for (let index in htmlWebpackPlugin.files.css) { %>
  <% if (/critical(\..*)?\.css$/.test(htmlWebpackPlugin.files.css[index])) { %>
    <style>
        <%= compilation.assets[htmlWebpackPlugin.files.css[index].substr(htmlWebpackPlugin.files.publicPath.length)].source() %>
    </style>
  <% } else { %>
    <link rel="stylesheet" href=<%= `${process.env.CDN_URL}${htmlWebpackPlugin.files.css[index]}` %> media="print" onload="this.media='all'">
  <% } %>
<% } %>

With relatively little effort, we are able to inline our critical CSS. This technique works both with CSS modules and not and can be easily added to an existent project.

Performance-First React Template

While writing this blog, I decided to clean up my Webpack configurations and build scripts to make them more accessible. This work is available in Performance-first React Template and includes the critical CSS configuration described in this blog and much more if you would be interested in taking a look. Feedback is highly welcome, so feel free to reach out to me on @imkevdev.

Thank you for reading.

DEV Community: Kevin Farrugia

Priority Hints and optimizing LCP

fetchpriority

Default priority

"Tight mode"

preconnect

preload

fetchpriority

Firefox

Safari

Combining preload with fetchpriority

fetchpriority all the things

Conclusion

Related links

Special thanks

Interaction to Next Paint

First Input Delay

Interaction to Next Paint

What is an interaction?

How is an interaction's duration measured?

What is a good INP?

Why is INP important?

How do you optimize INP?

Tooling

INP in the wild

React Sticky Children

Usage

Component Composition in React

Render Props

Single-responsibility principle

In practice

Multiple Render Props

Conclusion

React Router and nested routes

React Router

Nested routes

Let's get nested

Conclusion

Should you optimize every re-render?

Not all re-renders are bad

Other unnecessary re-renders

Conclusion

Recommended Reading

Getting your HTTP Cache-Control headers right

What is caching?

Private and shared caches

Demo

Static assets

Caching the HTML page

Scenarios

Blog

News website

Live event

Logged-in pages

Conclusion

Recommended reading

Code-splitting is hard

Will stylesheets be bundled in separate chunks?

What about images?

May I use CommonJS imports?

When using route-based code-splitting, is it possible to have some routes lazy-loaded while others loaded regularly?

Does code-splitting work with named exports?

What about re-exporting? Will export * from "./my-module" be tree-shaken?

Does this work with critical (inlined) CSS?

Will users have to wait to download the chunks on successive routes?

Loading CSS - Web Performance Cheatsheet

Loading CSS

Test Results

Conclusion

Should I host two websites on a single domain?

React Reconciliation Rendering Order

Demo

But what about connected components & async rendering?

So which is the last render?

Inlining Critical CSS

What's this magic?

Performance-First React Template

`fetchpriority`

`preload`

`fetchpriority`

Combining `preload` with `fetchpriority`

`fetchpriority` all the things

What about re-exporting? Will `export * from "./my-module"` be tree-shaken?