DEV Community: Boris Schapira

Cumulative Layout Shift, The Layout Instability Metric

Boris Schapira — Mon, 21 Sep 2020 15:11:04 +0000

Have you ever started reading an exciting news article but then lose your line because all the text shifted downwards? This happens to me a lot, mostly because of ads loading around the content I’m reading.
This kind of user experience can be frustrating, but until now we’ve had trouble measuring it quantitatively. Cumulative Layout Shift addresses this challenge.

When you see a web page, you automatically break it down into visual elements. You perceive their relationship to each other according to their arrangement on the page. This is how you can identify where the relevant content is located. If this content moves by itself, or if another element is injected into the layout and moves the others, then you may lose sight of what you are focusing on.

LeMonde.fr Home page load. Inserted and moving contents are identified by light blue areas. The contents of about 2/3 of the screen moves during the page load.

And it’s even worse if you thought the layout was stable, and you were about to interact with the page. For example by clicking on a button (image on the left). If other content appears right before the click and pushes the other content downward (image on the right) you might interact with the wrong element of the page.

Within a product listing, the user is about to click on an image of a chair, when suddenly a text insert appears, shifting all the content downwards. The user unintentionally clicks on an image of a backpack.

Overview

In this article, we will discuss the Layout Instability API and its use to compute the Cumulative Layout Shift (CLS). We’ll see how to visualize CLS in Chrome and how to optimize for it. Finally, we will address some of its unusual characteristics and conclude.

A Dedicated In-Browser API…

Viewing the elements that are shifted when loading and while using a page has been a long-standing need. A decade ago, you would need a custom-configured rendering engine (in the following example, Gecko, the Firefox rendering engine) to show every paint reflow.

Caution

This video contains lots of repaint. Don’t play if you are photosensitive or have vestibular disorders.

In Chrome today, you can use the Layout Instability API. Its original intent was to find more relevant signals than the onload event to determine when a page is loaded. Layout stability, or “lack of shift” was one of them. As stated in the API abstract, it “provides web page authors with insights into the stability of their pages based on movements of the elements on the page”. To do that, the API monitors the position of the visual representation of every node that is visible in the viewport. If a node’s visual representation shifts from the previous frame by 3 or more pixel units in either the horizontal or vertical direction, the API notifies a layout shift and scores it.

… Used To Penalize Jank

Let’s go back to our example:

How does the Layout Instability API score this? To compute the layout shift score, the algorithm first evaluates the area affected by the shift and multiplies it by the length of the shift.

The area affected by the shift, or impact fraction, is the total area of the moved node, from its first position to its final position. Here, 78 % +32 % = 110 %. As you can see, the impact fraction can be greater than100 % (the viewport size).

The length of the shift, or distance fraction, is measured according to the viewport’s largest dimension. So in this example, we’ll consider the height. The existing element moves by a height equivalent to 34 % of the height of the viewport.

In this example, and for this particular layout shift, the layout shift score is:

layout shift score = 110 % (impact fraction) × 34 % (distance fraction) = 0.374

The Cumulative Layout Shift (CLS) metric is the sum of (nearly) all individual layout shift scores.

The 500-millisecond window

To prevent websites from being penalized for transitions or animations that are the result of user interaction with the interface, the CLS algorithm does not record the layout shift for 500 ms after each active user interaction with the document (e.g. clicks, type, tap), or any event that directly changes the size of the viewport. We can consider that such shifts, resulting from an action, are expected by the user.

According to Google, to provide a good experience, sites should strive to have a CLS of less than 0.1 for most (75%) users. This is bad news for the developers of the above example!

Keep in mind that the impact fraction and distance fraction are highly dependent on the viewport’s characteristics. A change in your viewport’s dimensions or even orientation can change your layout – adapting responsively to the available space. Thus your impact fractions,distance fractions and, in the end, your Cumulative Layout Shift will change.

How To View Layout Shifts in Chrome

Layout shifts can be displayed in Chrome.

In the DevTools, open the Command Menu with Control + Shift + P or Command + Shift + P (macOS)
Start typing ‘Rendering’
Run the “Show Rendering” command.
Enable the Layout Shift Regions checkbox. As you interact with a page, layout shifts are highlighted blue.

Warning

As stated above, this feature may cause flashing. If you are photosensitive or have vestibular disorders, use it with caution.

Since Chrome 84, you can also visualize Layout Shifts and get information about their attribution (even down to the shifted nodes) in the Performance tab, on the ‘Experience’ line.

On a timeline, a succession of screens helps to understand the visual sequence. Below, several lines expose what happened at the same time, including the Experience line, that contains red inserts, one for each Layout Shift. At the very bottom, a description gives more precise information about the selected Layout Shift.

How To Optimize Your Cumulative Layout Shift

A page accumulates layouts shifts throughout its use. Each time new elements are visually inserted without the necessary space to display them being reserved by the browser. These insertions will often be images, but you also have to be careful with ads, web fonts, embedded content, and contents injected following an interaction that generate waiting times of more than 500 ms.

Images

When it receives the HTML code for your page, the browser doesn’t know much about the images used in it. With no more information than the URL of an image, the browser does not know its size, so it cannot allocate the proper space for the image to display. This has become even more complex since the advent of Responsive Web Design. The display size of an image often depends on the context.

To give as much information as possible to the browser so that it can do its job to the best of its ability, always set a width and a height attribute on your <img> tags (in pixels). Even if these are not the actual display dimensions (which may depend on style rules), the browser will use them to infer the width / height ratio (called aspect-ratio) of the image, and thus calculate the height to be reserved based on the display width defined by the CSS.

Did you know?

Edge, Firefox and Chrome have an internal mapping of aspect-ratio for images that defines both width and height attributes. An experiment is ongoing on Chrome to open the feature to developers.

.el {
    aspect-ratio: 16 / 9;
}
/* internal rule for img, using the --webkit prefix (in Chrome)
img[width][height] {
  --webkit-aspect-ratio: attr(width) / attr(height);
}*/

Learn more about aspect-ratio with Chris Coyier, on CSS Tricks.

And of course, remember to serve the right file size regarding the context. Use srcset to help the browser select the best image in your image set with the same aspect ratio (this depends on the rendering width). Use picture and source for different aspect-ratio or different image formats based on the context and browser support.

Ads, embed, iframes, and on-load dynamically created content

As with the images, the browser needs to allocate the appropriate space to render the final content. But you can’t give much info to the browser, as you have yourself little information about the future content. In the following I will only talk about ads, because they raise the most challenges. But the mechanics are the same for the other types of injected content.

In the following, we will discuss the impact of content injections on the main page template. It’s worth noting that if an iframe produces CLS within itself, it does not impact the main page.

More often than not, advertising space is allocated to a bidding service that injects a container into a dedicated node. Then, this space is ‘rented’ to the highest bidder, allocated to a network that then injects an advertisement. The space may be resized several times before the final ad is displayed, and in the case of timed ads, additional injections may occur multiple times during the users session.

How to prevent layout shifts from happening?

Explicitly define the space allocated to the ad container. If the ad is smaller than the allocated space, plan a background cover that will skin the available space. If the advertisement is larger than the reserved space, some of it will not be displayed.

Sometimes no advertising fills the area. Plan for visuals of the correct size so that you don’t have to collapse the advertising space and provoke a layout shift. If your network provides you a way (through a JS callback, for example) to inject useful content in the absence of advertising, of course, do not hesitate.

Another way to solve this problem is to position the ads in the negative space left by the content of the site, out of the page flow. If your ad has a fixed position in the page template, and that position does not interfere with the flow of the rest of the content, then inserting the ad does not cause any shift.

Using negative space to position ads.

You can also move your advertising slots lower down on your pages. This will prevent the layout shift impact fraction from being too large, but this will likely reduce your revenue.

Web fonts

When a browser needs to display text with a web font, it identifies whether the font is needed and available (on the system or in the browser’s cache). If the font is necessary but unavailable, then the browser fetches it. During the fetching phase, the browser follows the font-display instructions (or lack of) to determine whether it should render the text with a fallback font or allocate the space with invisible text. When the font is available, or if the waiting time is too long, then the browser proceeds with the final rendering.

In other words, whenever the browser has to fetch a font, it allocates the area with text using a fallback font, visible or not. And when the font is finally available, the browser renders the text area again using the web font.

However, the temporary font does not necessarily have the same characteristics as the final one. Baselines, point sizes, kernings can differ and the final text may appear shorter or longer than the temporary text, causing layout shifts.

Every time I need to remember how font display management works, I go back to the font-display playground, by Monica Dinculescu.

To avoid these layout shifts, you can speed up font loading. You can also choose web fonts with characteristics similar to system fonts, or consider the web font as optional the first time the page is loaded. It will then not be used on this page, even if downloaded and cached. Instead, it will be available on the next page. You can read more about this in ‘eBay’s Font Loading Strategy’ by Senthil Padmanabhan.

Content injected more than 500 ms after an interaction

The CLS algorithm ignores Layout Shifts for 500 ms after each active user interaction with the document or change in viewport size. Thanks to this behavior, most user interactions do not cause layout-shifts that are recorded in the Cumulative Layout Shift.

But you have to make sure your UI will react to the user interaction within the500 ms window. If your UI relies on network requests or heavy javascript processing, shifts might occur after 500 ms and will so be taken into account in the Cumulative Layout Shift value.

To optimize your CLS:

Make sure that your transitions and animations that follow user interaction last less than 500 ms.
Measure and optimize your APIs response time.
Anticipate the result of the network call(s) or long treatment by allocating the result area during the 500 ms, even if it is to be filled later on (you can use an optimistic UI pattern).
Implement a specific UI paradigm for long processing and network call (queuing and completion notification system, modals etc)
Only animate CSS properties that do not trigger layout changes in Blink.

Of course, always test. While conducting some experiments to write this article, I discovered that layout shifts are created when the duration of a translate transition is 0 (this is fixed now). Edge cases like this will always exist. Please report them to the Chromium Team.

Tip: two-step processing

Take the example of a “Load 20 more articles” button at the end of a page. If the processing (aka network call + rendering) takes less than 500 ms, no problem. But if it takes longer than 500 ms, the rendering may cause the footer to shift and increment your Cumulative Layout Shift.

To avoid this, you can monitor the elapsed time and split the task in two parts if need be. Instead of rendering systematically after the network call, you can change the button label to “Show all 20 retrieved items”. This will force users to interact again with the page and grant you 500 additional milliseconds for rendering the content.

Of course, do not hesitate to ask the users to check if the use of the functionality better meets their needs. Optimizing the CLS should not be at the expense of the UX.

Counter-intuitive behaviors

Continuous accumulation in Single-Page Applications (SPAs)

While most performance indicators are related to the loading of the page, the CLS is focused on the whole experience of loading and interacting with a website.

Many websites are structured on a page to page, URL to URL navigation paradigm. For them, the CLS is reinitialized with each navigation. Some sites, on the other hand, are built around a single page the content of which evolves through interactions, through JavaScript. These are called Single-Page Applications (SPAs).

On SPAs (including applications that use progressive enhancement turbolinks-like libraries), the Cumulative Layout Shift may never stop increasing during a user’s sessionsession, as the navigation between contents is not achieved by navigating between pages. The Cumulative Layout Shift will only be collected when the user leaves the page. If the Cumulative Layout Speed value you see in the Search Console (in the ‘Core Web Vitals’ section) seems high, maybe that’s an explanation.

Note

This specific point about Cumulative Layout Shift is particularly important. As it means that the goal of SPA developers should not be to reduce the number of layout shifts, but to design interfaces that don’t produce any layout shift at all. If they don’t, the more popular their interfaces are, the longer the session durations will be, and therefore the higher their reported CLS will be.

Scrollbars appearance penalty

This may seem counterintuitive to some, but horizontal and vertical scrollbars are part of the viewport. A great example of this is they’re included in the viewport-percentage length such as vw or vh. This implies that the appearance or disappearance of scrollbars does not modify the viewport size even though it changes the area available for content, and causes layout shift.

Unfortunately, on some Operating Systems, like Windows, scrollbars are hidden until they’re needed, which can lead to a scrollbar missing from First Paint, then added later during the page load, and that may cause layout shifts.

To avoid this behavior, you can add html { overflow-y: scroll } to enforce a scrollbar at First Paint, or wait for the implementation of CSS Overflow Module Level 4 and the new scrollbar-gutter property.

Impact of the timing-function

In the following example, we compare two flex arrangements. In the first one, the central element doubles in size when hovered, using an “ease” timing-function. In the second example, a “linear” timing-function is used.

As you can see, the second example generates much less Cumulative Layout Shift. To explain this, we need to go back to the Layout Instability API spec, and more precisely, to what is called “Unstable nodes”.

A Node N has shifted in a coordinate space C if the starting point of N in C differs from the previous frame starting point of N in C by 3 or more pixel units in either the horizontal or vertical direction.

This “three pixels between two frames” rule introduces a speed criterion in the instability measurement. All elements moving below this speed are not considered unstable, and these animations do not produce a layout-shift.

Unfortunately, this means that to reduce CLS, some site owners might be tempted to use linear animations, which have a constant speed, rather than ones more intuitive to humans, such as “ease”, that speeds up at the beginning of the animation and slows down at the end.

The linear function has a constant growth. The ease function accelerates until the middle of the time, then slows down.

Other strange behaviors of the metric

Animated elements that create layout shifts may continue to do so if they are not visible to the user (for example, even with a color that blends with the background). But if you use visibility: hidden, they won’t.
The web.dev CLS page recommends using transform and translate to create animations that do not produce layout-shift. However, a bug in Chromium seems to create layout-shifts when the transition time is 0 in Chrome, until version 86.

Conclusion

Cumulative Layout Shift is a metric that measures the layout instabilities of a web page. To optimize it, and improve the user experience, you should avoid injecting content for which the browser has not allocated the right amount of space. There are several techniques that exist for images, but this will, however, make advertising management much more complex.

The way the CLS is calculated results in some unusual features. The current algorithm of CLS is probably not a good fit for Single Page Applications, as the attribution of results at page-level is not properly handled. Thus, Core Web Vitals as a ranking signal might be particularly challenging in such cases.

Keep in mind that CLS is a new measure. We still lack feedback at scale. When in doubt, always focus on improving the User Experience instead of the metric itself. Some CLS optimizations may work against this goal and should be avoided.

Browser Support

Steve Kobes announced that Blink (the Chrome rendering engine) intended to implement such an API in October 2018. Work on the draft Layout Instability API began in May 2019, and the API released with Chrome 77 in September 2019 and later in Edge (80+). Daniel Holbert created a ticket for Firefox in July 2020. We did not find any mention of the Layout Instability API in Safari’s public ticketing platform.

Resources

My own Cumulative Layout Shift experiments
“Layout Instability API specification”, by Steve Kobes, Nicolás Peña Moreno & Emily Hanley
“Cumulative Layout Shift”, by Philip Walton and Milica Mihajlija
“Optimize Cumulative Layout Shift” and “Infinite Scroll without Layout Shifts”, by Addy Osmani
“Web Vitals - A New Hope in Web Performance Measurement”, by Dave Smart

Thanks to Damien Jubeau and to Matt Hobbs for their contributions and for helping me improve my English!

Self Restraint

Boris Schapira — Wed, 03 Jun 2020 15:00:24 +0000

Sometimes I write a tweet or a blog post and then I delete it.
Because the world doesn’t need it.
Because it can hurt some people.
Because there are other ways.
Because I can live without publishing it
and my followers deserve that I don’t.

Please do the same with your JavaScript.

How to Optimize Third-Party Services Performance

Boris Schapira — Tue, 19 May 2020 13:29:49 +0000

Embedding an existing library or service as a third party can increase productivity, but often has a cost on perceived performance. Once you embed external code, how can you ensure that this code will not affect the performance and interactivity of your site? Here are some ideas for a more efficient third party code.

Building a Front-End Web project is about fulfilling a set of business requirements through code. You can produce this code yourself or transfer this responsibility to libraries or services that have already proven themselves on the market.

When you reference one of these libraries or services from a web page rather than embedding it in your code, neither you nor the browser of the visitor has control over this resource, since it is produced, managed and hosted by a third party vendor. These are called "Third Party" (or "3p") resources.

How does it work?

Using third-party resources, in HTML, is usually done through the <script> tag (which allows you to load and execute a script), <link> tag (which references resources later needed by the page) and <iframe> tag (which creates a completely different navigation context within the page). They are very commonly used.

According to the Web Almanac 2019, 93% of desktop pages include at least one third-party resource and nearly 76% of these pages query an analytics domain (such as Google Analytics, for example).

Third parties can concern a wide variety of areas: advertising, analytics, customer relationship, social network integration, marketing, user management, videos... Very often, references to these resources are gathered in a tag manager, which centralizes their management and provides an entry point for discussions about the third parties used on the page.

Using third parties increases the productivity of your development teams (who delegate some features to these third parties). On the other hand, this will increase your operational cost, since you may have to pay for a software license, and most certainly monitor the proper functioning of this software component that you no longer have control over.

Note that you generally cannot request any changes to the way the third-party resources or services you use work: the fact that these resources are used by a very large number of sites means that the publisher is sheltered from individual pressures.

What about performance?

While often criticized, third parties have an impact on rendering and usage performance that it is important to balance. If we take, for example, the most common JS libraries, served as third parties by CDNs: they are among the most efficiently delivered resources, with efficient minification and obfuscation, often coupled with low-latency CDNs. Although their use often degrades the Start Render, this is more often because these scripts are loaded synchronously rather than to their third-party status.

The biggest impact on performance comes from ads and social network scripts which cost on the network and performance is rarely outweighed by the features they provide to users, at least during the initial page loading phase.

One example is Facebook's "Like" button. Its interest from a user experience perspective is debatable, and it is certainly not relevant until the user has seen the content of the page. You should therefore always load it "lazyly" (late, in the process of loading the page).

Quite often, once you have assessed the relevance of your third parties and their respective loading modalities, you will certainly discover that the way you load your third parties can be optimized.

Delaying a resource or service loaded too soon.

When a third-party resource (or several) is loaded before all the critical elements of the page have been displayed and became interactive, you may want to delay them. An example would be the loading of Youtube videos, located below the fold, consuming bandwidth even when they are not visible.

In this case, it will be necessary to revise the declaration of the <script>, <link> or <iframe> responsible for the inclusion of the third party resource in the site, so that this inclusion occurs later, deferred: either in reaction to an event raised during the loading of other resources or after an event provoked by the user (an issue of Lazy-Loading already discussed for the loading of images).

Prioritizing a resource or service that is too late in the queue

If you are using third parties to define or improve the design (fonts, JS scripts that define the dimensions of elements in the layout), or even to retrieve part of the content to be displayed, you will want to prioritize their loading and usage. However, very often, the use of these resources is slowed down by:

the DNS resolution of the origin that hosts them - the connection to this origin - the downloading of these resources

How to tell the browser the behavior to adopt to optimize their loading? Have a look at my previous article on Preload and Resource Hints!

The Googles Fonts case

When it comes to web fonts, Google Fonts are predominant: according to the Web Almanac 2019 ("Fonts" chapter), at least 74% of web font requests come from Google Fonts, and 29% of pages contain a link to a Google Fonts CSS style sheet.

This type of request presents a real risk because the loading of a CSS stylesheet is synchronous. The browser interrupts the rendering of the page while it requests, downloads, and analyzes the CSS file. The request represents a Single Point of Failure (SPOF): if there is no response, then the page remains frozen. It is very easy to simulate such a failure with Dareboost (targeting fonts.googleapis.com).

To mitigate this, you can use asynchronous loading techniques based on attribute alterations or JavaScript libraries that expose the life cycle of your fonts.

A simpler optimization is to download Google Fonts. A feature offered natively on the Google Fonts site but also available via Mario Ranfti's Google Webfont Helper tool which will help you generate the CSS file to declare them.

By doing so, however, you will lose the benefit of Google Fonts content negotiation, detailed in this article by Barry Pollard. In short: Google Fonts optimizes the CSS file it delivers to provide the right font formats and character sets for the requesting browser.

At the moment, the best solution may be to use a resource proxy. On the surface, these are your sub-domains that serve the third-party resources you need. Under the hood, they are web applications that perform resource fetching and caching on external domains, filtering the information sent to those domains ( forwarding what is relevant for content negotiation but not privacy-related data). With such a tool, you serve fonts from your domain, while benefiting from Google Fonts content negotiation. This technique, also available for JavaScript scripts, is well described in this article from Decitre Tech team: "Limiting the damage of third party JS loading [FR]".

This complex technique is not within everyone's reach. An alternative is to use a mix of preload (for the CSS stylesheet) and preconnect (to the domain serving the fonts) to get the best possible optimization.Harry Roberts discusses this subject in detail in an article published today: "The Fastest Google Fonts".

Conclusion

Third-party resources or services provide features to your site, but the way they are loaded may negatively impact the user experience. To optimize their usage, start by determining the tradeoffs that need to be made to prioritize each item. Once these priorities are determined, then you can delay or prioritize third-party loading to get the most out of it, sometimes by delivering them through your domain (first-party), either directly or through a proxy.

Preload, Prefetch and Preconnect: Speed Up your Website with Resource Hints

Boris Schapira — Fri, 08 May 2020 15:14:05 +0000

Loading a web page requires fetching a whole set of resources which collectively allow the page to be displayed and interacted with. To increase the user’s perception of speed, you may need to influence the order in which these resources are fetched and executed. And that’s where preload and Resource Hints come in.

A web page consists of a main HTML document and optional additional resources designed to format it, add media, or behaviors. According to the Web Almanac 2019 (chapter "Page Weight"), more than half the pages contain more than 68 resources added to the main document.

Hence we can assume that under normal circumstances, downloading a resource is a recurring task for the browser. This task can be broken down into several steps, including:

Revolve the DNS of the resource’s origin (if necessary, i.e. if the browser has not already done so);
Connect to the origin server (if necessary, i.e. if the browser is not already connected);
Fetch the resource (if necessary, i.e. if the resource is not already in the user agent cache and still valid);
And – according to the type of resource and the reason for which it was fetched – its evaluation and use.

For the browser to download resources more efficiently, you can indicate how to optimize these different steps.

You can even tell (ask?) the browser to download some resources in advance, to improve future browsing experience on your site.

The directives and how to use them

To leverage resource loading, you can use preload, dns-prefetch, preconnect, and prefetch. We'll call all of these directives "Resource Hints" in the following, but be aware that preload has its own specification, while the other Resource Hints are defined in a separate specification, mostly because `preload' is not just a hint to the browser, but rather a command.

To write these directives, you can use either the <link> HTML tag or the Link HTTP response header. As for specifying the character set, we recommend you to use the HTTP header, since it will be taken into account by the browser before it starts interpreting the HTML code for the page.

In the HTML page body:

<link href="resource-url" rel="directive" as="ressource-type" crossorigin="value" />

Through an HTTP header:

Link: <ressource-url>; rel="prefetch"; as="ressource-type"; crossorigin="value"

Whichever syntax you choose, the parameters are always the same:

The URL of the resource, of course
The directive to use
The type to consider for the resource, which allows you to adapt the Content-Security-Policy to the nature of the resource (learn more)
The crossorigin attribute, which we'll discuss later

These settings can be used to define 4 directives supported by most modern browsers:

dns-prefetch: indicates to the browser that it should perform the resolution of a given domain name (determining the IP to contact) before that domain is used to download resources
preconnect: indicates to the browser that it should connect a given origin, before that domain is used to download resources. Preconnecting involves, like - dns-prefetch, the DNS resolution, but also the TCP handshake and TLS negotiation (if the page is secure)
prefetch: indicates to the browser that it can download a given resource, even if it is not detected in the page. The resource is downloaded with a low priority
preload: tells the browser that it must download a given resource as soon as possible, with high priority.

Using dns-prefetch can be interesting in the context of critical third parties: by resolving the domain upstream, a few milliseconds can be saved cost-effectively. However, in most cases, you may want to use preconnect' instead ofdns-prefetch', so as to anticipate the whole connection.

If your site must be compatible with Internet Explorer, which does not support preconnect, you can use the rel="preconnect dns-prefetch" syntax .

Use preload for resources that you know will be useful very early in the page load but that would not naturally be prioritized by the browser. This makes preload useless for synchronous scripts present in your <head>, which are already considered by the analyzer to have a high priority. You can use it to increase the priority of execution of an asynchronous script declared in your <head>. preload is also used to load resources referenced by other resources (such as web fonts, images, or other stylesheets referenced using @import) to retrieve them while the parent resource is fetched and parsed.

prefetch is a directive that sets a very low priority, don’t use it for essential resources. Actually, it can be very relevant for improving navigation on subsequent pages. One of the great use case is to include some prefetch directives during the authentication of a user, to take advantage of the time it takes them to input their login and password to preload the static resources needed to render the page they will see once authenticated.

The `crossorigin` attribute

The crossorigin attribute – which is optional – is used when fetching resources from origins that are different from the main origin (CORS). For many resources (such as CSS, or images), you don't need to specify it, unless you want to request these resources by passing authentication headers, cookies, etc. (with the use-credentials value).

For other types of resources, defined in more recent specifications, crossorigin must be explicitly stated. This is the case, for example, for fonts (see the specification), even when they come from the main origin.

But be aware of the implications: for example, if you are using preconnect on a third party domain from which you are retrieving images and fonts, make two declarations in order to create two connections: one without crossorigin, for the images, and the other with it, for the fonts.

Consume in moderation

Reading this article, you might assume it’s relevant to declare many Resource Hints so that the browser loads the page as quickly as possible to. That is not the case.

Since it sets a low download priority, you can use prefetch without any real impact on the current page load. Be careful though: its use will increase data consumption on your site, which can present issues both for you (increased traffic on your server), and your users (unnecessary over-consumption of resources).

Use preload sparingly, as it overrides the priorities set by the browser’s analyzer, both in terms of download and execution. For example, imagine that you have an async script in your <head>. Thanks to the async attribute, its download priority is low. However, once fetched, like any non-deffered script, its parsing and execution interrupt the main thread (you need to use the defer attribute to change that). If you add a preload directive matching this resource URL, the browser will fetch it faster, so it will parse it faster, negating the effect of your async attribute by interuptiing the main thread very early in the page load).

Though preconnect cost is low, it is not null. If the open connection is not used quickly, then the preconnect directives only add extra CPU usage (both client and server) and unnecessary network competition.

[…] use it wisely: each open socket incurs costs both on the client and > server, and you want to avoid opening sockets that might go unused. As always, > apply, measure real-world impact, and iterate to get the best performance > mileage from this feature.

"Eliminating Roundtrips with Preconnect [EN]", Ilya Grigorik

This advice from 2015 is still relevant, particularly for connections to secure origins, for which the validation of certificates adds some CPU and network overhead.

The same kind of recommendations can be found in the work of Ivan Akulov, who even advises to switch to dns-prefetch, which is cheaper, if more than 4 to 6 domains are concerned.

As you can see, with great power comes great responsibility. If you want to get your hands on the priorities generated natively by the browser, then you must proceed in a moderate and responsible way, in order to avoid reproducing network congestion and CPU consumption that would affect your users. This can be very profitable, especially to optimize third party services (analytics, web fonts, etc.).
Like many web performance topics: test, measure and iterate!

Performance timing: wait for the next frame (when using the User Timing API)

Boris Schapira — Thu, 03 Oct 2019 15:10:07 +0000

The usual web performance metrics (First Byte, Speed Index…) are very interesting but I often need to add custom temporal markers, based on events that make sense from a business point of view.

I use the User Timing API (see on MDN) to create named timestamps that belong to the browser's performance timeline. As I can retrieve this timeline in Dareboost, I can track their evolution over time.

Some Custom Timings of this site

Using the API in JavaScript is quite simple (and broadly supported), for example:

    // The thing you want to monitor the occurrence of
    document.getElementById("content").classList.add("blue");
    // The timestamp
    performance.mark("mark-blue");

You can then retrieve the value in your browser developers tools, using:

performance.getEntriesByType('mark');

However, I recently¹ realized that I often forgot something important: just because the browser execute some JavaScript code does not mean that the user can see the results of this execution. The browser must update the display, and its ability to do so depends on the JavaScript code that follows the piece of code we're interested in.

In the following example, I inject a 1-second blocking loop after my performance mark, preventing the browser to update of the display.

    // The thing you want to monitor the occurrence of
    document.getElementById("content").classList.add("blue");
    // The timestamp
    performance.mark("mark-blue-sync");

    // A snippet of code that consumes resources during 1 second
    let n = performance.now();
    while (performance.now() - n < 1000) {}

Of course, in real life, you won't have a simple loop. You will have other tasks that may or may not take a long time. You can't know it and, in fact, you can't even test it, because it all depends on the customer context that you don't control.

To get around this problem, we can use requestAnimationFrame() to ask for our mark to be put set before the browser performs the next repaint:

    // The thing you want to monitor the occurrence of
    document.getElementById("content").classList.add("blue");
    performance.mark("mark-blue-sync");
    // The timestamp, before the next repaint
    window.requestAnimationFrame(() => {
      performance.mark("mark-blue-frame");
    });

    // A snippet of code that consumes resources during 1 second
    // but we don't care anymore
    let n = performance.now();
    while (performance.now() - n < 1000) {}

If you want to see this for yourself, here's a test page.

IN A NUTSHELL

Call the User Timings API to create custom business-related timestamps.

Encapsulate them inside requestAnimationFrame() callbacks to get to understand how the UI behaves, rather than the code execution.

If you want to have an idea of the display latency, attach two marks: one after the event to be followed, the other in a requestAnimationFrame() callback.

Reading "Performance metrics for blazingly fast web apps", by Conrad Irwin ↩

First Contentful Paint (FCP), Start Render, First Paint. How to properly measure the beginning of page rendering?

Boris Schapira — Wed, 18 Sep 2019 13:29:10 +0000

How to properly measure how fast a web page starts to display its content? Several Web performance metrics exist to answer this question, including First Paint, Start Render and one of the newest: First Contentful Paint (FCP). How does FCP stand out, what are its limitations? Let’s dive into the metrics that measure the browser’s early rendering of web pages.

After a click or any other navigation action, a user can only perceive a page is loading if some content has started to be rendered. How do we know the moment this rendering starts? One of the simplest ways of finding when the browser first renders something after navigation is to ask the browser itself. This is called “First Paint”, and one of the earliest web performance metric.

First Paint, however, can be misleading: the “paint” is from the browser perspective, not the user’s. And a browser can perform a paint that is not visible to a user. For example, if an element is rendered with the same background as the default background, First Paint is triggered all the same.

Using First Paint to track the performance of your page does not guarantee you’re tracking when something is displayed for your visitors.

How can we focus on what makes sense to a visitor? That’s the question the First Contentful Paint is trying to answer. According to the Paint Timing specification:

FCP is the point when the browser renders the first bit of content from the Document Object Model (DOM), which may be text, an image, SVG, or even a canvas element.

Paint Timing 1
Editor’s Draft, 13 June 2019

As for First Paint, the browser returns the information when processing the rendering of web elements, but it additionally checks the element type (text, image, SVG or a canvas).

First Contentful Paint can be found in Dareboost, WebPageTest or in Google services like Lighthouse or Chrome UX Report which data is used in PageSpeed Insights. For now, FCP is only available on Chrome and Opera. Firefox considers to support it as well.

Here’s how you can get First Contentful Paint from Chrome DevTools:

let fcp = performance.getEntriesByName(``"first-contentful-paint"``)[0].startTime;

Unfortunately, FCP also has a few limitations.

First, it doesn’t take iframes into account, which can be an issue if your main content is relying on an iframe to be loaded (but that’s definitely an edge case to be avoided).

Secondly, FCP can be biased by a text node waiting for a pending web font to be rendered. In the following example, we would presume the FCP to be fired around 900 ms, as we don’t see any content before that:

The filmstrip of our example

The actual FCP value is around 600 ms because that’s the time the text node is first rendered by the browser even if the font is not loaded yet, so the text stays “blank” (invisible) for a while. This phenomenon is called Flash Of Invisible Text (FOIT).

To avoid that behavior on your websites, make sure that you’re using the @font-face CSS directive with a non-default value for the font-display descriptor. If you’re using Google Fonts, please note that the service now encourages its users to use font-display:swap value. Make sure that your Google Fonts import declaration specifies a value for the “display” parameter in the URL query.

<link href="https://fonts.googleapis.com/css?family=Caveat&amp;display=swap" 
 rel="stylesheet">

One of the main limitations you may be facing with First Contentful Paint is the metric is not bound to the viewport. Wherever is the piece of content displayed, it will trigger FCP, even if the content is not above-the-fold, and thus not visible for a visitor.

To really track the time at which we’re sure there is something displayed and visible for the user, we have to use another metric: Start Render. The Start Render algorithm is based on video analysis of the page loading, looking for the first altered pixel in the viewport.

Even if Start Render will trigger regardless of content type (as the First Paint), it’s a great way to track the time when a user can perceive that the page is loading, while avoiding to track browser-related, “technical”, paints.

Start Render is only available through Synthetic Monitoring tools because a video analysis is required, whereas FCP and First Paint can be directly requested from the browser, making them usable in Real User Monitoring (RUM) as well.

In a nutshell:

First Paint: The first paint action of the browser, from the browser own perspective. Not necessarily visible from a human.
First Contentful Paint: The first paint action of the browser, from the browser own perspective, concerning a text, an image, an SVG or a Canvas. Iframes are excluded, and text can be painted but still not visible (because of a webfont still being loaded, or outside of the viewport).
Start Render: Something is visible by the user in the viewport. Whatever it is, even if it’s only a background.

With Dareboost, you can measure and monitor these metrics very easily. We’re advising to focus on one of them only, and we would suggest the Start Render as it’s the one with the fewer edge cases.

If you’re not already one of our amazing customers, do not wait anymore to ask for a trial on our Synthetic Monitoring Service.

We Love Speed 2019 on September 20 in Lille, France

Boris Schapira — Tue, 30 Jul 2019 13:58:41 +0000

After a most successful 2018 edition, Dareboost is proud to keep sponsoring the French Web Performance event: We Love Speed.

The 2019 edition will take place on September 20, in Lille (1h hour from Paris by train), and will be even more interesting than the previous one, including some feedback from Dareboost customers such as Antonio Gomes Rodrigues (SeLoger.com) or Loïc Troquet (PagesJaunes.fr).

More than 200 people are expected for this one-day, two-track conference hosting 16 talks (11 in French, 5 in English).

Given by Web Performance or Web Quality experts who will have – sometimes – crossed the Atlantic (Estelle Weyl, Jérémy Wagner) or the English Channel (Matt Hobbs, Ryan Townsend), when they don’t travel from Sweden (Peter Hedenskog), the talks will address various central web performance topics such as usability, management of optimization projects, JavaScript performance, third-party governance, Progressive Web Apps, image compression, network protocols, CSS and eco-design.

Their shared experiences, acquired within the IT departments of OUI.sncf, Wikipedia, L’Équipe.fr, Protonmail, Shift Commerce, the United Kingdom government or within the SiteSpeed.io or Fasterize solutions will certainly echo yours, and inspire discussions.

As in the previous edition, moments of exchange will be arranged so that developers, decision-makers and Web Performance experts can interact in a user-friendly environment, to mutually enrich each other with technical and methodological tips, but also with enlightening anecdotes about their own initiatives.

An independent event in which we believe

Customer Success Manager at Dareboost for almost two years, I have, once again, invested a lot of time and energy into this event, along with a fantastic team of professionals from Fasterize, BrainCracking, Cdiscount and Theodo, all determined to make this event an important moment for the WebPerf in France.

We have shared our technical and organizational knowledge, but above all we have listened carefully to your expectations to build an enriching, open and grounded conference that will provide you with the opportunity to return to your teams with new perspectives.

And even if the conf promises to be twice as rich as last year, its price remains the same: 180 € for the entire day. Get your ticket now!

Dareboost will be on-site with a booth. Feel free to come and talk to us: we are always happy to exchange with our users. Do you want to discover Dareboost before the event? Feel free to ask us for a free trial.

Other sponsors, without whom the event would not be possible, will also be present. We thank them for their support!

Measuring Interactivity with TTI: Time To (consistently) Interactive

Boris Schapira — Mon, 20 May 2019 10:04:16 +0000

When we talk about web performance measurement, what we’re actually trying to determine is the moment when a user can effectively achieve his or her goal. Meaning the users can consult the content they are looking for and/or interact with the page in a satisfactory way. Some metrics endorse rendering actions by the browser, others measure the progress of the display through the recording of a video. However, a great mystery remains: how to properly measure interactivity.

For a few years now, Google has been pushing an ambiguous metric: Time To Interactive. What does it mean? Let’s define it and explain how and when to use it (or not).

Measuring interactivity is like getting on a moving ride. When can we consider that the carousel is slow enough to consider that we can jump on it? There’s no precise answer.

TL;DR

The measurement of interactiveness is a pregnant challenge for Web
Performance experts. Synthetic monitoring solution vendors, especially, find it
difficult to provide a computable metric in the absence of user input.

Google’s Time To Interactive is a sophisticated measure designed to determine
the ideal conditions for interactivity by monitoring both the JS main thread
activity and the network. It’s quite effective at determining a time when you are sure that an interaction will be seamless.

However, TTI is also a complex metric to understand and to exploit that does not measure what most people think it measures, which is
the time it takes for a page to become interactive.

Real User Monitoring (RUM) remains the only way to capture user’s actions and
even there, we still don’t have a single KPI which simply
depicts the relationship between users behavior and the interactivity of the
page over time.

The quest for a new metric

What are we trying to measure?

Accessing a web page is an experience that the web performance world generally describes as 4 moments:

The user has confirmation that loading has started.
The user has enough information in front of them to think that they can interact with the page.
The user can interact with the page (this particular moment being dependant of the type of the interaction).
The user’s interaction with the page is effortless and intuitive, with no delays and jank.

Several signals give the user indications that the loading has started: the url and title change, the browser may animate the tab and / or the favicon, the first non-blank pixels appear, then the rest of the page…

Speed Index and First Contentful Paint give a good idea of the visual perception of visitors. They help to understand the perceived load of the page. They have limitations that can be identified at a glance by a human being through video or filmstrip because their algorithm is directly related to what is displayed.

However, when talking about measuring interactivity – points 3 and 4 – things get harder. Truth is, we don’t actually know how to measure it. The only thing we know how to do well is to collect information that allows us to deduce these particular moments.

For example, Akamai has been looking for new ways to measure user activity for years. They rely on the Boomerang library, created by Philip Tellis. Philip came to We Love Speed 2018 to expose the new user experience metrics that the Boomerang team has been collecting to measure page responsiveness: Rage Clicks, Missed Clicks, Dead Clicks, and Cursor Trashing. By analyzing the distribution of this data qualifying user frustration, we can infer approximately when the user expects the page, or a particular component, to be interactive.

There’s a clear linear correlation between rage clicks and 1.2 to 1.5× the time to Visually Ready (when the page would look to the user like they could interact with it – see the full definition on Boomerang documentation).

This type of correlation requires large amounts of data collected from real users, either through JavaScript libraries like Boomerang, or in-browser RUM like the Chrome UX Report. This data can only be collected on production environments with large amounts of visitors.

Testing optimizations in this environment is risky. Without prior testing, deploying in production can introduce regressions/slowdowns and hurt your business. Moreover, you’ll have to wait to collect large enough volume of data, and it will be difficult to evaluate, because RUM data is not so easy to analyze.

Synthetic Monitoring solutions can perform accurate performance measurements on all environments, while controlling test contexts. They would be even more useful if they could provide an interactivity metric.

But since they do not involve real users, they are forced to engage in shenanigans…

Let’s introduce… Time To (Consistently) Interactive

NOTE

Although there are several definitions, we will focus on the definition put forward by Google through their tools and websites.

Interactivity can be considered in two ways: either as a switch between two states (non-interactive and interactive) or as a continuum. Knowing when a page becomes interactive for the first time is interesting but if the interface does not respond quickly, the UX will be very degraded. By "interactivity", we refer here both to the fact that the page is interactive and to the fact that interactions can take place in a satisfactory way.

Time To Interactive, previously known as "Time To Consistently Interactive", is an experimental synthetic metric that attempts to measure when your web application is both visually rendered and interactive.

As moving things are difficult to grasp, we often rely on approximations and models.

TTI is an interactivity metric that does not rely on real users interactions. Instead, the algorithm makes an approximation by considering that a satisfactory interaction can only happen in specific conditions, and focuses on determining the prevalence of these conditions.

To determine the TTI, the algorithm advances along the timeline, performs checks, and redefines its candidate value for the TTI until it finds a moment where all conditions are met. First, it chooses, as the lower limit, when the user feels that the primary content of the page is visible. Several metrics are available for this: the "Time To Interactive Explainer" uses the First Meaningful Paint, but you can also use the First Contentful Paint, as WebPageTest does.

Then, the TTI’s algorithm verifies that the browser is able to handle the interaction. As many user inputs are handled by client-side JavaScript, working in a single thread environment, the algorithm must then ensure that no long-lasting JavaScript tasks are currently occupying that thread, preventing JS from handling the user inputs right away. For the W3C, a task is "long" if it lasts longer than 50 ms (Long Task). TTI will observe the JS tasks and wait for a 5-second period of time without Long Tasks.

However, all this is useless if the JS code necessary to handle the interaction is not yet downloaded. Rather than finely observing each HTTP response to see if JavaScript resources are downloaded, the Time To Interactive algorithm will use a signal: it will wait until it observes a period of at least 5 seconds during which it never sees more than 2 resources (all types combined) being downloaded in parallel.

If one of the conditions (Long Task and Network) is not met, the algorithm moves its candidate value for the TTI forward and resumes observation to find another Long Task and another 5-second network-quiet window after the last observed Long Task. At that point, the candidate value for the TTI corresponds to the end of the last observed Long Task.

But we’re not finished! At last, the algorithm does not consider a page to be interactive until the browser has finished parsing the document so if the DOMContentLoadedEnd event occurs after our candidate value for TTI, this moment is chosen as the final value for Time To Interactive.

Schematic diagram of the definition, in the "Time To Interactive Explainer".

How to use the TTI?

When you start to look at the performance in terms of display, you quickly discover the Visually Complete, i.e. the moment when the entire rendering of the visible area of the page is finished.

Time To Interactive is pretty much like Visually Complete: a time marker for the end of something. The main question is "what?". Tim Dresser found out the most adequate way to define this: TTI is a "no jank past this point" metric and that’s something you would want to monitor and optimize or, at least, not deteriorate without good reasons.

Indeed, the TTI is computed from the indirect observation of both the CPU –
through the JS Long Tasks – and the network activity. If the TTI increases, it definitely means that a JS Long Task happened later than before, during the page load, and it is important to know why. Has a new Long Task been introduced? Is it a previously known tasks pushed back by a new piece of code? Is this a consequence of some newly-implemented third-party dependency?

As we’ll demonstrate later in the article, this Long Task is not necessarily harmful to your UX (for example, if you defer your scripts, then the Long Tasks they produced will occur later) but you can certainly optimize to make sure they don’t happen (for example, you can delegate complex JavaScript algorithms to Web Workers, making them run in background tasks, therefore not occupying the JavaScript main thread).

Common misconception about Time To Interactive

Time to Interactive is not the time until a page is interactive

"Time To Interactive" is a really ambiguous name.

Even in the Lighthouse documentation, you can read short misleading definitions like:

The Time to Interactive (TTI) metric measures how long it takes a page to become interactive.

Fortunately, the sentence is followed by a definition of what "interactive" means here, but for someone who wouldn’t read any further, the damage is done.

As a matter of fact, the Time To Interactive does not measure how long it takes for a page to become interactive, it measures how long it takes to be sure, regarding the conditions, that a interactivity can happen in a satisfactory way, for at least 5 seconds. That’s why the metric was previously known as Time To Consistently Interactive.

We can totally have a very fast and usable page that, however, has a massive TTI. To do this, all you need is for the page to perform Long Tasks of the shortest possible duration, at a rate sufficient to interrupt the TTI observation window. This page, for example, executes a 51ms task every 2 seconds, during a total of 20 seconds and its TTI is over 19 seconds.

Still, the page is perfectly interactive way sooner than the TTI suggests.

In the TTI algorithm, the "network quiet" subwindow is only a signal

TTI is always linked to the last JS long task. The "quiet network" heuristic is just a signal. I’ve seen people asking if they need to improve their waterfall to artificially create cascades containing less than two simultaneous requests. If none of these requests involve a Long Task, you can relax, your TTI will not suffer.

However, as this is a signal only, it does not guarantee that the JS code required to handle the interaction is available at all. You can have pretty good Time To Interactive and a page that is not interactive – as expected by user – at all.

Google’s TTI is not everyone’s

Every time Google introduces a new concept, there is a strong market demand. But be careful, Time To Interactive is not a standard!

Akamai’s Boomerang, one of the most famous Real User Monitoring solution, has its own definition of Time To Interactive, that differs a lot from Google’s. They use different signals like Frame Rate, Long Tasks, Page Busyness (via setInterval) and delayed user interactions. Even if they keep the W3C 50ms Long Tasks definition, their window of quiescence is only 500ms long (instead of 5 seconds), which mitigates TTIs from being extended due to isolated tasks.

During my research, I’ve also found that some Synthetic Monitoring solutions claim to support the Time To Interactive metric but, as with load time, you should always verify their definition, because some solutions do not hesitate to brand a "TTI" label on other metrics (such as the domInteractive event) that have nothing to do with Google’s TTI.

Time to Interactive is not easy to stabilize

A metric that is not predictable is difficult to understand. In researching this article, we have gathered this evidence that suggests that the TTI is one of those complex metrics, hard to stabilize.

I tried it out and it was a too unstable metric to measure Wikipedia. Here’s an example: https://phabricator.wikimedia.org/T176369
Peter Hedenskog, Software Engineer (Contractor), for the Wikimedia Foundation

There are few feedbacks on the TTI

There is little data on the correlation of TTI in the wild and none of them allow us to say that it’s more interesting than the existing metrics.

Based on a first study by Deepanjan Roy (a 28-website scoresheet), Time To Interactive has later been qualified by Tim Dresser, without much success. To be honest, these correlations are very difficult to obtain: as we can see from Tim’s analysis, the correlation of more stable metrics like FCP in the wild vs. in the lab is not good either.

I found one study from 2017, by Nic Jansma, quoted by Addy Osmani, where he explains that improving the TTI has a real impact on conversion rate in a real Use Case but the slides don’t give access to the data nor the experimental conditions.

Other Use Cases available online often consist in removing all JavaScript from the Landing Pages which is a pretty partial move, where other solutions (like downloading and byte-caching the JS in a Service Worker for future use) could have been chosen. Don’t get me wrong, I’m all for reducing the JavaScript to its smallest share, but never at the expense of the user journey.

Time To Interactive is entering a Web Performance landscape that already offers multiple metrics, some of which are easier to understand and comment. Most of the Use Cases I read about Time To Interactive do not clarify whether the existing metrics were sufficient to qualify the situation. Most site owners only monitor and report on 3 or 4 web performance metrics. Before we ask them to drop one of them for this one, I think it’s important that they can get an extensive idea of their respective relevance.

The Long Task "50ms" definition creates a threshold effect

The TTI thresholds have the merit of raising awareness of the importance of performance budgets. TTI is kind of a performance budget: "the main thread activity must stay under the 50ms budget".

However, the definition of any threshold has impact.

Let’s take a really simple blog post page, and test it on Desktop with WebPageTest. The page is visually ready and completely interactive as soon as 1.2s. At that moment and during several seconds, a visitor can read and scroll freely. Around 3.5 seconds, a reCaptcha script execution creates a 150ms Long Task (in red, on the bottom bar) that push the Time To Interactive forward. Will this delay be perceived by the visitor? By the way, how long would a delay take to be felt by a visitor?

According to the RAIL performance model (Response, Animation, Idle, Load), the user perception of performance delays depends on the nature of the delay. Interaction delays are perceived after ~100ms. A value consistent with Nielsen’s 1993 post, based on Miller & Card et al. studies.

If the perceived delay is 100ms, why consider a JS task as long from 50ms? The explanation lies in the Long Task API specification:

The RAIL performance model suggests that applications should respond in under 100ms to user input (for touch move and scrolling, in under 16ms). Our goal with this API is to surface notifications about tasks that may prevent the application from hitting these targets. We surface tasks that take 50ms or more. A website without these tasks should respond to user input in under 100ms: it will take less than 50ms to finish the task that is being executed when the user input is received and less than 50ms to execute the task to react to such user input.
Long Task API 1

In other words: handling an interaction requires both that the browser is able to handle the user input by not being already busy (interactivity) and that is can handle fast enough the potential JS code execution triggered by the user action (responsiveness). As we don’t know the actual response time of the browser to handle the triggered processing, we consider this time should be less than 50ms. That leaves 50ms for the browser to be free enough to react to the input.

But in practice, all browsers and browsing contexts are different and there are many factors that can influence the time taken by the browser to process a task.

Interactivity measurement: is TTI enough?

TTI as a new reference metric?

Creating and promoting a metric is a performative act especially when the metric is defined as THE reference metric for interactivity: when pushed by Google, the metric not only evaluates the Web, it shapes it. SEO/SEM experts highly value it to their customers, companies use it in rankings. Quickly, everyone considers the metric as a reference, without questioning its rationale.

However, its many limitations, consistent with its definition based on many approximations, make the TTI a rather binary metric. Either the TTI is very low and you can be happy because you are absolutely certain that the web page offers the best conditions for quality interactions ; or it’s not, and you need to investigate further to know what is happening. Some tasks can be delaying the TTI without bothering end-users but the page may also be unusable. You just don’t have any way to distinguish the two possibilities without further investigation.

A bad TTI is a sign that not all conditions are perfect for interactivity. This does not mean that interactions will necessarily be degraded. More investigation is always needed.

A milestone more than an evaluation of a continuum

Time To Interactive is to interactivity what the Visually Complete is to display: a final milestone. What we’re missing is "a Speed Index of interactions" where each Long Task would be weighted by its duration and the time at which it occurs, in relation to other metrics (e. g. rendering metrics) to infer the user’s frustration.

In the previously mentioned study, Nic Jansma observed the distribution of Long Task durations and found a correlation with conversion. I hope that we will make progress on this subject in the coming years.

Nic’s study did not observe a decrease in conversion as long as the First Page Long Tasks were shorter than – not 50ms – but 100ms. Isn’t that interesting?

In the meantime, a lot of other metrics exist regarding interactivity, mainly in RUM, where real user activity can be monitored. For example, I think the distribution of First Input Delays is an extremely relevant self-explanatory information but this would be a story for another blog post.

Remember: if you need to understand what’s happening with your JavaScript code in Synthetic Monitoring, you can still use Custom Timings to deploy a full instrumentation. It’s the best way to grasp what matters to your business.

More about interactivity and the Time To Interactive:

A touch of archaeology

[1993] "Response Times: The 3 Important Limits", Jakob Nielsen
[2015] "Measure Performance with the RAIL model", Meggin Kearney, Addy Osmani, Kayce Basques, Jason Miller
[July 2016] "Time To Interactive", Tim Dresser, Paul Irish, Brendan Kenny
[December 2016] "Update on defining firstInteractive", Deepanjan Roy
[January 2017] "Evaluating definitions of firstInteractive", Deepanjan Roy
[August 2017] "First Interactive and Consistently Interactive", Deepanjan Roy (anchor to the definition of the TTI)
[February 2018] "Time To Interactive Explainer", Tim Dresser, Deepanjan Roy
[May 2018] "First Input Delay: Correlation with TTI", Tim Dresser
[January 2019] "Web Page Usability Matters", Addy Osmani
[February 2019] "User-centric Performance Metrics", Philip Walton

Thanks to Henri, Phillip, Peter, and Tim for having helped me to shape my ideas, and Damien for his multiple proofreading and advice.

Lazy Loading, faster webpages, SEO friendly

Boris Schapira — Wed, 20 Mar 2019 16:20:28 +0000

Images are a key content on your website? If you’re serious about your website performance, you have probably optimized them. But have you considered to lazy load your images? Lazy loading images improves the user experience by saving bandwidth for important content first.

Some reject the technique for SEO considerations. But properly lazy loading your images does not prevent them from being indexed. Let’s find out why you should implement lazy load, and how to make sure you build it in a SEO friendly way.

Images are everywhere on the Web. Serving the right image in the right context can be really challenging. Images need to be optimized, adapted to its rendering area, and only loaded if required.

Images Lazy Loading is a set of techniques designed to answer this last requirement. An image will be loaded only if it is useful for the visitor: the download of an image is triggered when it’s needed: after a specific interaction, as a result of a scroll… or never.

According to HTTPArchive, 420 KB (median value) could be saved per page by lazy-loading offscreen and hidden images.

Some use cases

There are many concrete cases where Lazy Loading is involved. Let us take a few minutes to cite a few examples.

E-Commerce Search Results. These pages often contain so many results that a lot of products are outside the viewport. Is it useful to download their images? With Lazy Loading, you can delay their loading until the page is scrolled.

Carousels. You know about them, right? Why should the user load all of the images whereas it will only showcase the first one during several seconds… Lazy load them! Load the first one, and trigger the download of the next when in the background a couple of seconds before the carousel animation.

Menus and tabs. Images contained in a menu or a tab are often hidden, only displayed after a click. With Lazy Loading, you can delay the loading of the images until the button displaying the element is hovered or clicked.

Depending on the nature of your page, other cases are possible. No images should be included on your pages without previously asking yourself the question of delaying their download. Because at the end of the day, there are significant performance gains.

The bare necessities

By postponing the loading of images that are not immediately required – or, in some cases, not loading them at all – the browser saves resources (bandwidth as well as CPU). The page loads faster and the user experience is improved as saved resources can be affected to more critical content. There are also server-side gains. The CPU and bandwidth required to delivered the resources are subjected to less stress, reducing the hosting and/or CDN costs.

As said in the introduction, Lazy Loading do not prevent your images from being indexed by search engines. But it can be tricky and all the techniques are not equals, as all the best practices are not implemented by the various libraries and plugins available on the market. To preserve your organic SEO, you need to understand how Lazy Loading works, and how to use it safely.

LazyLoad with JavaScript

In a perfect world, the browser would automatically lazy load the images. This may be the case in the future, as a Lazyload Feature Policy is under study, but we’re not there yet. In the meantime, we have to explore other solutions, every one of them implying a modification of the HTML markup and the addition of a JavaScript (JS) dependency.

IMPORTANT
You don’t need to – and shouldn’t – lazy load all your images. If you know that some images will be displayed most of the time , let them be loaded and rendered normally. Lazy Loading is only recommended for the other images. Do not add complexity when it’s not required!

The most traditional solution consists of using JS to reassess, at regular intervals and for each image (or each element displaying an image as a background), if it needs to be loaded. High-performance libraries such as lazysizes are built on this paradigm and are compatible with older browsers. lazysizes can even detect if the User-Agent is able to scroll and, if not, load the images right away.

However, running those tests so regularly has a cost. This cost can be avoided for web browsers supporting the Intersection and Mutation Observer APIs (that provide the ability to react to specific DOM situations rather than having to test continuously). yall.js and lozad.js are good examples of this condition-based technique (they are only compatible with modern browsers, but you can use a polyfill to emulate the missing feature for older browsers).

TIP
As the browser may interpret any omission of src as an error, I strongly recommend that you still define the src attribute value, using a really small transparent image placeholder, even inline, like:

data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==

Whichever JavaScript solution you choose on the client side, you must modify your backend to return the right HTML code. The HTML markup for the lazy-loading of an image is always similar: the final value of the src attribute is temporarily placed in a data-src attribute which prevents the <img> element from loading the final image right away.

<!-- Lazy loaded image: before -->
<img data-src="garden.jpg" src="placeholder.jpg" class="js-lazyload" src="dat…" />

<!-- Lazy loaded background image: before -->
<div data-class="bg-image-garden" class="container js-lazyload">…</div>

The library identifies its target images through an attribute, quite often using a specific class (for example, here, we are using the js-lazyload class). When the library detects it’s time to load the image, the data-src attribute is used to populate the src attribute and the browser starts loading the image. The technique is the same for other media types (video, iframes) or images adapted for responsive web design (for example, the data-srcset attribute can be used to temporarily retain the final value of the srcset attribute).

<!-- Lazy loaded image: after -->
<img src="garden.jpg" class="js-lazyload" … />

<!-- Lazy loaded background image: after -->
<div class="container js-lazyload bg-image-garden">…</div>

No JavaScript? Fallback with style (and `<noscript>`).

Search engine bots, such as Googlebots, are crawlers that browse the web for the purpose of content indexing. No one knows for sure when the Googlebots will execute JavaScript on their pages, and at what capacity. As demonstrated by Stephan Boyer in 2016 and later confirmed by Tom Greenaway at Google IO 2018, Googlebots do not execute JavaScript during their first visit. The final render can actually arrive several days later.

Because Googlebots actually runs two waves of indexing across web content, it’s possible some details might be missed.
Tom Greeaway

Like some images.

Because if JavaScript properly executed, lazy loaded images will not be handled by it and the src attribute is never populated, preventing the browser from starting the download and displaying the images.

How to serve these images despite the absence of JavaScript? There’s a specific HTML element you can use: <noscript>. The content of an <noscript> element is displayed only if scripting features are not supported or are disabled. That’s exactly what we need!

So if your HTML response contains:

<img data-src="garden.jpg" src="dat…" alt="A spacious garden dominated by a large pine tree." class="lazyload" />
<noscript>
    <img src="garden.jpg"  alt="A spacious garden dominated by a large pine tree."… />
</noscript>

then:

when JavaScript is available, only the first <img> element will be displayed;
when JavaScript is not available, both <img> elements are considered during the page display. The second one (in the <noscript> element), is displayed and indexable by search engines. The technique, confirmed by John Mueller, Webmaster Trends Analyst at Google, is exactly the same for background images:

<div data-class="bg-image-garden" class="container js-lazyload">…</div>
<noscript>
    <div class="container bg-image-garden">
        … A spacious garden dominated by a large pine tree. …
    </div>
</noscript>

Beware: don’t miss adding a specific style that will be applied when JavaScript is not available, hiding the non-lazy-loaded images.

You may be afraid of the resulting verbose HTML related to code duplication. Don’t worry, your HTML documents have to be compressed with gzip or brotli before being sent on the network, hence a marginal impact in transfer size (if you’re not sure your website is properly using compression, audit your pages on Dareboost).

Of course, it remains true that entering all these tags is tedious. When managing responsive images, artistic direction… the markup of images can be very, very complex. So anyway, you should not enter this HTML code manually: dealing automatically with this kind of complexity should be the work of your CMS or a task of your contribution workflow whatever it is.

Mark-up an image from The Guardian, even before the implementation of a Lazy Loading

Testing the implementation

Once you’ve implemented Lazy Loading, you’ll need to test that it works. The simplest solution is, of course to run a full web performance diagnosis with Dareboost to detect if all the images outside of the viewport are lazyloaded. If it’s not the case, we’ll tell you and give you the URLs of the images for which loading can be postponed.

If you have conditioned the loading of your images to a browser or a custom event, feel free to use your report’s Waterfall to check that the loading of images follows the correct sequence. In the case of a custom event, feel free to also use a Custom Timing: you’ll be able to find the event in the Waterfall.

It may also need to do manual tests. Open your browser on the concerned webpage, open the Developper Tools and select the Network tab (every modern browser features it). Empty the network stack to better visualize new calls, then provoke the interaction meant to start the lazy loading.

Here is an example on Chrome, with the Lazy Loading activated during scrolling:

You may consider automating these tests by using browser-based tools to perform tests. Puppeteer is one of them and can be used to test the behavior of your lazy loading on Chrome or Chromium, to make sure that your real users will see your images.

To verify that crawler bots will also see your images, you can ask Google itself, using the URL Inspector tool of the Google Search Console. You will view your page exactly as fetch by Google. Just insert your URL for Googlebot to test your page and screenshot the result to confirm that your <noscript> fallback is working.

Here we are, you now know everything there is to know about Images Lazy Load, its SEO impact and the best way to get around it. Let’s trim some pages!

Content Encoding: why and how to use the meta charset tag and the Content-Type header

Boris Schapira — Mon, 19 Nov 2018 14:44:58 +0000

Improving the speed at which a web page is displayed often means making the browser’s life as easy as possible. When the browser receives an HTTP response, it actually receives text encoded in bytes, where each byte or sequence of bytes represents a given character. If the browser does not have a clear information about the used encoding, it will waste time trying to guess and may fail in some cases.

Although the Web is intended to be universal, the various human groups that use it have their own specificities. One of these specificities is language, especially when written. All textual content is composed of characters from a directory intended for a type of use. Hiraganas, for example, are phonetic system intended for the unambiguous transcription of the Japanese language.

Table showing the writing direction of hiraganas
by Karine WIDMER (CC-BY-SA-3.0 · Source

To be able to designate each character unambiguously, we must assign a unique identifier to each of them. The whole set of identifiers will be called a character set. Once this correspondence table has been defined, each character need be converted into a sequence of bytes so that we can store or share them between computers. This is called character encoding.

Imagine that I use a character set to write text and a corresponding encoding to convert it to bytes, which I later send to you. How would you decode it, and read the content, without knowing which encoding, or set, I used? Eventually, you would have to use some of the most common character set & encodings you know, expecting the result to make sense… What could go wrong?

Replace a semicolon (;) with a greek question mark (;) in your friend’s JavaScript and watch them pull their hair out over the syntax error.

Ben Johnson (@benbjohnson), November 16, 2014

So yeah… not a great idea.

For example, the bit sequence 1100 0011 1010 1001 represents the character "é" in the UTF-8 encoding. If you decode this sequence assuming you have to use the Latin-1 encoding and not UTF-8, you will read "Ã ©".

In Latin-1, the character "é" is represented by the sequence 1110 1001.

When the browser receives bytes from your server, it needs to identify the collection of letters and symbols that were used in writing the text that was converted into these bytes, and the encoding used for this conversion, in order to reverse it. If no information of this kind has been transmitted, the browser will try to find recognizable patterns within the bytes to determine the encoding itself, and eventually try some common charsets, which will take time, delaying further processing of the page.

To speed up the display of your pages, you must specify the content encoding into your HTTP response.

How to choose the right character set?

There was a time when hundreds of character encodings coexisted, all limited and not able to contain enough characters to cover all the languages of the world. Sometimes, no encoding was adequate for all letters in a single language.

Nowadays, Unicode – a universal character set, defining all the characters necessary to write the majority of languages – has become a standard, no matter what platform, device, application or language you’re targeting. UTF-8 is one of the Unicode encodings and the one that should be used for Web content, according to the W3C:

Everyone developing content, whether content authors or programmers, should use the UTF-8 character encoding, unless there are very special reasons for using something else. (If you decide to not use UTF-8, you must choose one of the few encodings that are interoperably implemented across all browsers.)

"Introducing Character Sets and Encodings", W3C

Note: if you’re using a database to store your content on the server side, you may be tempted to also use the "utf-8" charset too. Beware: on MySQL and MariaDB, it’s an alias for "utf8mb3", a UTF-8 encoding called "Basic Multilingual Plane" – or BMP – that only stores a maximum of three bytes per code point. Instead, you’d rather use "utf8mb4", an encoding that stores a maximum of four bytes per code point. Otherwise, you won’t be able to use some popular characters, such as 🚀, otherwise known as "U+1F680 ROCKET"!

How to advertise your character encoding… and the best way to do it.

Before going any further, let’s take a look at the vocabulary in use.

Historically, the terms "character encoding", "character map", "character set" and "code page" were synonymous in computer science[…]. But now the terms have related but distinct meanings,[…] Regardless, the terms are still used interchangeably, with character set being nearly ubiquitous.

"Character encoding", Wikipedia

We find this use of "character set" or "charset" to designate, in reality, an encoding, in the HTML specifications. We will do the same in the rest of this article.

One of the easiest ways to specify a charset in an HTML page is to put in a <meta> tag in the element:

<meta charset="utf-8">

Declaring a character set this way requires certain constraints to be respected, one of them being that the element containing the character encoding declaration must be serialized completely within the first 1024 bytes of the document, to ensure that the browser will receive the information with the first IP packets transiting through the network and can use it to decode the rest of the document. As the charset <meta> tag is the only one with this kind of requirement, the most common tip is to place it directly after the element opening tag:

<html …>
  <head …>
    <meta charset="utf-8">

If you’re afraid to forget this, don’t worry. This is obviously one of the checks that Dareboost will perform for you within our website quality analysis tool. However, you may find yourself in a situation where this declaration is not sufficient, and the browser does not take it into account. Why? Because the Content-Type metadata of the page may indicate another character set and in the event of a conflict, this information – defined in the page HTTP headers – has priority.

To make sure of the information transmitted through the page metadata, you can use our Timeline / Waterfall feature. Unfold the detailed values of your main document to view the response HTTP headers, including the Content-Type header, containing the encoding metadata.

To change this HTTP header, you may need the help of the person who managed the server, whereas it’s your hosting service provider or a person in charge in your organization, because the configuration of the HTTP headers is very specific to the web server in use, and you’ll need the appropriate administrative rights to be able to modify those server settings.

On Apache 2.2+, the configuration of UTF-8 as a default character set for your text/plain and text/html files involves the AddDefaultCharset directive:

AddDefaultCharset utf-8

For other types of files, you'll need the AddCharset directive;

AddCharset utf-8 .js .css …

On nginx, you’ll need to make sure that the ngx_http_charset_module is loaded, then use the charset directive.

charset utf-8;

Here too, it is possible to refine the scope so that other types of files than text/html are delivered in utf-8, using the directive charset_types:

charset_types text/html text/css application/javascript

Of course, you can also configure the Content-Type HTTP header from your server-side scripting code. For example, in PHP, you can use the header() network function. Don’t forget to define the Media Type (or MIME type) of the body of the response, in addition to the character set.

header('Content-type: text/html; charset=utf-8');

Beware: if your pages are delivered by a Content Delivery Network (CDN), you may have to configure the Content-Type header in the CDN configuration, as most of them don’t pass on the headers they find on your servers.

Additional Resources

The IANA Media Types list
The Unicode website
"Character encodings: Essential concepts", on the W3C Internationalization website
Still thinking that Character Encoding is a trivial issue? Look at "Anatomy of a Critical Security Bug", by Andrew Nacin at Loop Conf 2015.

One hosts file to block them all

Boris Schapira — Thu, 13 Sep 2018 14:35:57 +0000

As a field expert, people often ask me how to improve websites' performance. Sometimes, they also ask me how to improve the Web's performance on their own machine, for their own browsing experience. In that case, my answer is always the same: the lowest hanging fruit is most certainly the hosts file.

Keeping the dirt away

Today's web is full of dirt. Most sites are full of trackers, ads, and lots of other nasty stuff penalizing websites' loading. To avoid this, AdBlockers are blooming. They offer a quick and simple solution (most of the time, a browser extension) that blocks most of the unwanted content.

Unfortunately, as for the UX, AdBlockers don't deliver. They often increase the amount of memory and CPU cycles used by your web browser, slowing your browsing experience instead of boosting it. Some are doing better than others, and whole browsers¹ have been conceived over the idea of blocking unwanted content, and are doing an incredible job. But the web is not confined to your browser, is it?

The Web is requested from everywhere in your computer. Most mainstream applications are as crammed with trackers as your next media website. Sometimes, you can even see the ads displayed in your UI (Hello, Skype. Yes, I'm talking about you, you naughty boy).

The AdBlockers can't do anything about that. But a simple hosts file does.

Hosts… what?

The computer file hosts is an operating system file that maps hostnames to IP addresses. It is a plain text file.
"hosts (file)", on Wikipedia

Whenever your browser interacts with a website, it actually requests a server, located through its IP address, like 185.31.40.11 (IPv4) or 2a00:b6e0:1:20:2::1 (IPv6). It's pretty similar to a postal address.

Now think about accessing a webpage, like https://borisschapira.com. How does your browser know which IP address to contact? Well, the browser simply asks the Internet phone book. At least, one of them. And the phone book, called a DNS, resolves the IP address for the browser.

I don’t know about you, but I never use a phone book. Most of the time, I’ve collected the address of the people to whom I want to write in my personal address book. That’s the hosts file for you. Every time a process on your computer needs to access a resource on the Internet, it first goes through the hosts file to find out where to find it.

Now, let’s say that you don’t want this process to find the resource on the badthings.com domain. Easy peasy, throw it on the wrong track by associating the badthings.com domain to an unspecified address like 0.0.0.0.

So basically, if someone makes a list of all the domains where bad things happen, we can redirect them all to 0.0.0.0 in our hosts file, and make our own Web a much cooler place.

One project to gather them all

There is nothing new in what I am describing here. Cool people have been doing this for years, sharing their host files. Fake news websites, gaming platforms, pornographic hubs, encryption pages, fraud attempts, and scams are all patiently identified and listed in open access files.

I use Steven Black's "hosts" project, a python script, to cram them into a single 2MB hosts file containing more than 70k domains. In case you're wondering, I can and do alter the result with my own whitelist (otherwise blocked domains whose requests I don't want to prevent) and redirections (which allows me to write this article and check the result on https://borisschapira-dev.com:10443/, which actually points to my own machine).

If you're not familiar with the command line and use Windows 10, the hostsman app will help you achieve the same goal (unfortunately, as I just published the post, the website looks down. Fortunately, a portable version exists). I will not recommend modifying your host file on previous versions of Windows even if I did it, before 2015 (FR), unless you like to run ipconfig /flushdns every 30 minutes. On Linux, I've heard people talk about using dnscrypt-proxy… but I've never tried myself.

You can manage Update Sources in hostsman

Some tips from my daily life

Sometimes, I need to temporaly disable this hosts file. For example, when I need to help Dareboost clients understand the impact of third-party scripts on their pages (thus, I need to load these 3ps myself).

To enable or disable my hosts file, I use a command line function that I've develop and put in my ~/.profile file²:

function togglehost() {
    if [ -e /etc/host.bak ]
    then
        sudo mv /etc/host.bak /etc/hosts
        echo "Hosts file is active again"
    else
        sudo mv /etc/hosts /etc/host.bak
        echo "Hosts file is set aside"
    fi
}

Once this function is loaded, activating or deactivating my hosts file is very simple:

$ togglehost
Hosts file is set aside
$ togglehost
Hosts file is active again

But as I sometimes forget to put it back in place, I have set up a routine that checks every minute that the file is in place and, if it is not the case, warns me by using Jaime Piña's noti to trigger a notification. To perform this regular check, I use crontab.

* * * * * if [ ! -e /etc/hosts ]; then /usr/local/bin/noti -t "Host file" -m "does not exists"; fi

I have been using this technique for years now and, sometimes, I forget that my hosts file protects me so much. Whenever I need to use someone else's computer, or temporarily disable my hosts file, I realize the level of comfort it provides me.

I'm well aware that tweaking its own hosts file is a good but technical solution. It doesn't completely replace an AdBlocker (or I haven't aggregated enough files yet) but it's an incredible performance gain, which I highly recommend for everyday browsing.

Try it for yourself, and tell me what you think!

Summary

Hosts files are your computer internal address books that guide Web requests to the right servers. Fill your hosts file with domains pointing to nothingness, and those requests will quickly and surely fail. People are sharing their hosts file for years. Solutions now exist to concatenate them, and crowdsource a solution to the dirty Web we've to deal with everyday.

If you've never tested Brave Browser, I can only encourage you to do so, and join the 4 million people that trust it to fix the web. ↩
Actually, I put this function in my ~/.zprofile, as I use Oh My ZSH. ↩

[Dogfooding] How Dareboost has benefited from Custom Timings

Boris Schapira — Mon, 28 May 2018 14:44:34 +0000

We may be Web Performance experts, we still don’t have superpowers. We also need tools to analyze our sites and applications. So when we released our new Custom Timings feature, we naturally jumped at the chance to test it on Dareboost.com… and immediately saw the benefit.

The Dareboost web application

A few weeks ago, we have introduced a new feature in your page analysis reports and monitors: Custom Timings, tailor-made markers, to be placed in JavaScript using the User Timing API, that you can then display in Dareboost to visualize their evolution over time.

We’ve chosen to prioritize this feature within our backlog because we were deeply convinced that it would allow our customers to better understand their websites performance. In fact, using it is so simple that we immediately found a practical application to meet our own needs!

To explain this, let’s take a look under Dareboost’s hood first.

Dareboost: an AngularJS application personalized according to the current user’s rights

Any visitor consulting Dareboost website uses a real Web Application. In other words, the user’s browser loads JavaScript code that, once executed, takes over the browsing experience and emulates the behaviour of an application instead of the navigation between multiple web pages. For example, a user can switch from one screen to another without reloading the side menu.

To ensure this applicative behaviour in a web page, known as SPA (for Single Page Application), we use a JavaScript framework: AngularJS. This framework performs the customization operations, using an XHR request (XMLHttpRequest) to retrieve the user’s context.

Two shakes of a lamb’s tail

We decided to set up several Custom Timings:

When AngularJS begins its bootstrapping: angular_boostrap_start
When AngularJS is bootstrapped (and starts doing what we want him to do to present Dareboost’s interface): angular_boostrap_end
When we ask Angular to fetch the current user’s context: userinfo_xhr_start
When the context is effectively recovered: userinfo_xhr_stop
When the content is displayed in the main area: view_content_loaded

Setting up these marks is so simple that some customers ask us if these are really the only actions to take. Check it by yourself: once you have found which portion of code corresponds to the behavior you want to monitor, just add this code:

performance.mark("angular_boostrap_start");

We really had nothing more to do for Dareboost to start collecting these new data: no particular configuration, no declaration, or anything else. A few days later, we consulted our monitoring data and the data were available. We didn’t expect such results*!

Erratic timings for the `userinfo_xhr_stop` mark

* In fact, we did, because we already had experienced slowdowns several times, in a significant way. But seeing them on a plot is something else.

Elementary, my dear Watson!

What’s going on? The AngularJS booting phase, marked by the events angular_bootstrap_start and angular_bootstrap_end, is quite obvious. But, surprisingly, we find the context request in the middle. Actually, this is only fair: the context request and loading of AngularJS are asynchronous but, in reality, depend on each other. Indeed, the request must wait until AngularJS is loaded to be initiated. If we want a finer follow-up of this request, we will surely need to move this marker so that it better meets its purpose.

The Custom Timing of the main area comes next, which is reassuring in Dareboost’s ability to respond quickly to user demand, since it is mainly on this area that he looks at.

Finally, we see the Custom Timing of the context request response, which is unsteady and bad: almost two seconds for context recovery. Two seconds of latency is quite a long delay for a busy user! Analyses that refuse to start, potentially unavailable scenarios (because they did not have the item in the menu)… we had to fix it quickly.

Immediate action by the development team solved the problem

Fortunately, the team promptly identified the back-end side issues that could explain the delay. After a minor release, the situation clearly improved:

This is how Dareboost performs now

The situation has returned to a normal behaviour, with the main contents appearing simultaneously with the determination of the user context.

In a nutshell

Setting up Custom Timings takes a few seconds and does not require any special configuration in Dareboost
Custom Timings are new indicators to understand what was invisible before.
Custom Timings are particularly suitable for monitoring the performance of SPAs
The shoemaker’s children don’t always go barefoot!

DEV Community: Boris Schapira

Cumulative Layout Shift, The Layout Instability Metric

A Dedicated In-Browser API…

… Used To Penalize Jank

How To View Layout Shifts in Chrome

How To Optimize Your Cumulative Layout Shift

Images

Ads, embed, iframes, and on-load dynamically created content

How to prevent layout shifts from happening?

Web fonts

Content injected more than 500 ms after an interaction

Counter-intuitive behaviors

Continuous accumulation in Single-Page Applications (SPAs)

Scrollbars appearance penalty

Impact of the timing-function

Other strange behaviors of the metric

Conclusion

Browser Support

Resources

Self Restraint

How to Optimize Third-Party Services Performance

How does it work?

What about performance?

Delaying a resource or service loaded too soon.

Prioritizing a resource or service that is too late in the queue

The Googles Fonts case

Conclusion

Preload, Prefetch and Preconnect: Speed Up your Website with Resource Hints

The directives and how to use them

The crossorigin attribute

Consume in moderation

Performance timing: wait for the next frame (when using the User Timing API)

IN A NUTSHELL

First Contentful Paint (FCP), Start Render, First Paint. How to properly measure the beginning of page rendering?

We Love Speed 2019 on September 20 in Lille, France

An independent event in which we believe

Measuring Interactivity with TTI: Time To (consistently) Interactive

TL;DR

The quest for a new metric

What are we trying to measure?

Let’s introduce… Time To (Consistently) Interactive

Common misconception about Time To Interactive

Time to Interactive is not the time until a page is interactive

In the TTI algorithm, the "network quiet" subwindow is only a signal

Google’s TTI is not everyone’s

Time to Interactive is not easy to stabilize

There are few feedbacks on the TTI

The Long Task "50ms" definition creates a threshold effect

Interactivity measurement: is TTI enough?

TTI as a new reference metric?

A milestone more than an evaluation of a continuum

More about interactivity and the Time To Interactive:

A touch of archaeology

Lazy Loading, faster webpages, SEO friendly

Some use cases

The bare necessities

LazyLoad with JavaScript

No JavaScript? Fallback with style (and <noscript>).

Testing the implementation

Content Encoding: why and how to use the meta charset tag and the Content-Type header

How to choose the right character set?

How to advertise your character encoding… and the best way to do it.

Additional Resources

One hosts file to block them all

Keeping the dirt away

Hosts… what?

One project to gather them all

Some tips from my daily life

Summary

[Dogfooding] How Dareboost has benefited from Custom Timings

Dareboost: an AngularJS application personalized according to the current user’s rights

Two shakes of a lamb’s tail

Elementary, my dear Watson!

In a nutshell

The `crossorigin` attribute

No JavaScript? Fallback with style (and `<noscript>`).