Peakhour.IO - Learning

Interaction to Next Paint (INP)

2023-09-11T13:00:00+10:00

Google has announced that Interaction to Next Paint (INP) will replace First Input Delay (FID) as a Core Web Vital as of March 2024. Introduced as a metric in 2022, INP covers gaps in FID by measuring more of what happens after a user interacts with a page.

To help site owners prepare for its introduction as a Core Web Vital, INP is already included in the Chrome User Experience Report (CrUX). By analysing the CrUX data, website owners can see their current INP performance and make targeted optimisations ahead of the March 2024 change.

A better metric than First Input Delay

First Input Delay, as its name suggests, only measures the delay between an input, such as a keypress or mouse click, and the point where the browser begins to handle that event. It does not include the time spent processing the input. It only measures how long the browser was blocked before it could start handling it.

That leaves two issues: it only considers the FIRST event, and it does not measure how long it takes for the user to see the result of their input.

INP is designed to cover both issues. It measures the latency of ALL 'interactions' through to the visual response for that interaction. As explained by Google, an interaction like a tap on a touch screen device can consist of several input events.

"An interaction's latency consists of the single longest duration of a group of event handlers that drives the interaction, from the time the user begins the interaction to the moment the next frame is presented with visual feedback."

After measuring all interactions, the final INP score is the longest interaction observed, ignoring any outliers.

What Constitutes a Good Score

INP is measured in milliseconds (ms), with lower scores indicating better performance:

Good: < 200 ms
Needs Improvement: 200-500 ms
Poor: > 500 ms

How to ensure you have a good INP score

Minimise Main-Thread Work

Long-running JavaScript can block the main thread and increase INP times. Break these tasks into smaller parts and run them asynchronously to reduce delays.

Efficiently Use Browser APIs

APIs that trigger layout recalculations can be expensive. Use them sparingly and look for alternatives that put less pressure on the browser.

Defer Non-Essential CSS and Scripts

Postpone the loading of non-critical CSS and JavaScript. Use techniques like asynchronous loading to improve INP scores.

Monitor Third-Party Scripts

Heavy third-party scripts can degrade INP performance. Use asynchronous or deferred loading for these scripts to limit their impact.

Conclusion

Google estimates that 90% of a user's time on a page is after it has finished loading. FID focused on first impressions, with the assumption that a fast start meant the page would stay responsive. Interaction to Next Paint addresses that gap and gives a more accurate view of user experience. If you want to know your current INP score, you can use our free website speed comparison tool to view it alongside your other Web Vitals, and see how your website compares to your competitors.

Understanding HTTP Link Headers

2023-05-24T13:00:00+10:00

Sometimes the browser needs to discover a critical asset before it reaches the corresponding tag in the HTML. An HTTP Link header lets the server put that resource hint in the response headers, where the browser can see it earlier. It also works when an edge layer can change headers but should not rewrite the response body.

Here are some sample request headers sent by my browser when requesting a page on the Peakhour website:

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: en-AU,en;q=0.9
Connection: keep-alive
Cookie: _ga_NRWSVE0PSC=GS1.1.1685943893.13.0.1685943893.0.0.0
Host: www.peakhour.io
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.4.1 Safari/605.1.15

The HTTP Link header

An HTTP Link header lets a server send context about a document back to a client. It can identify related resources or the direct location of a specific asset. For page-load optimisation, Link headers can be an alternative to putting preload/preconnect/prefetch hints in the HTML.

History

HTTP Link headers were proposed as a standard in the late 1990s, around the same time the HTTP/1.1 protocol was defined. However, it wasn't until 2010 that HTTP Link headers were officially recognised by the Internet Engineering Task Force (IETF) in RFC 5988, which described their purpose and functionality.

Uses

HTTP Link headers have several uses in web development. Some common examples are:

Pagination: Say we have a blog site with hundreds of posts, and we display 10 posts per page. When a user requests a page, we can use Link headers to provide URLs for the next and previous pages. This helps navigation through the large list of posts. Here's an example of how it might look:
```
Link: </posts?page=2>; rel="next", </posts?page=4>; rel="prev"
```
Preloading: Suppose we have a heavy image or a large CSS file that we know will be required for a webpage. We can use a Link header to tell the browser to start downloading it early, improving the perceived page load speed. For instance:
```
Link: </images/big-picture.jpg>; rel=preload; as=image
```
Resource Hints: Link headers can give the browser hints about resources that might be needed in the future, so the browser can decide whether to fetch them ahead of time. For instance:
```
Link: </scripts/myscript.js>; rel=prefetch
```

Comparison to Link Tags and Why Headers Can Be Better

Now you might be wondering, "Why use Link headers when we can use HTML Link tags?" There are several reasons HTTP Link headers might be a better choice:

Faster Processing: Since HTTP Link headers are part of the HTTP response, they arrive before the HTML document. This allows browsers to start preloading or prefetching resources sooner, which can improve page load times.
Greater Flexibility: HTTP Link headers can be used in situations where HTML Link tags cannot. For instance, they can be used with file types that don't support HTML, like JSON or XML. They can also be added by a third party, e.g., an edge delivery layer such as Peakhour, without the need to parse and rewrite the HTML document.
Less Clutter: Link headers can make your HTML less cluttered, as you can avoid filling the HTML document with numerous Link tags.

Use Link headers where they solve a measured delay

Do not preload every plausible dependency. An unnecessary preload competes with resources the page actually needs. Start with a waterfall, identify a late-discovered critical resource, add the Link header at the application or edge, and measure the result again. The header is valuable when it advances a real dependency without creating extra work for the browser.

Cdn-Cache-Control

2022-02-28T13:00:00+11:00

Caching headers are easy to get wrong. Public resources may be cached in one layer, while the server configuration prevents an otherwise cacheable resource from being stored where you expect.

Controlling caching without a service like Peakhour usually means working directly with Cache-Control headers. This header has a wide range of fields and directives. Each one tells downstream clients (e.g., proxies, shared caches, and end browsers) how to handle caching for a particular resource.

Getting this right can be complicated, and it can become brittle when web server configuration also affects the response.

Enter CDN-Cache-Control

CDN-Cache-Control is a recently proposed header specified in https://datatracker.ietf.org/doc/html/draft-cdn-control-header-01

The draft RFC states:

This specification defines a convention for HTTP response header
fields that allow directives controlling caching to be targeted at
specific caches or classes of caches.  It also defines one such
header field, targeted at [Content Delivery Network](/learning/cdn/) (CDN) caches.

What does this mean in practice? Imagine a Magento application where pages should be cacheable by a shared cache but not by a browser. A Cache-Control header could look like:

Cache-Control: max-age=0, s-max-age=600

This tells browser caches not to reuse the response, while shared caches may cache it for 600 seconds.

What if the application does not want every shared cache to store the resource, because the application already sends purges to the cache when content changes?

Cache-Control does not give you that separation. The header above enables any shared cache to store the resource for the specified time. With CDN-Cache-Control, the application could instead send:

Cache-Control: max-age=0, s-max-age=60
CDN-Cache-Control: max-age=3600

This tells the browser not to cache the page, allows a shared cache to keep the page for 60s, and allows the CDN to keep it for one hour.

Targeted CDN-Cache-Control

What if you need to target a specific CDN only? Use the provider's targeted CDN-Cache-Control header.

For example, Peakhour-CDN-Cache-Control instructs Peakhour only to cache the resource. Other CDNs in the request path will not honour this header.

Header format

Examples

The following header fields instruct a CDN cache to consider the response fresh for 600 seconds, other shared caches for 120 seconds, and any remaining caches for 60 seconds:

Cache-Control: max-age=60, s-maxage=120
CDN-Cache-Control: max-age=600

These header fields instruct a CDN cache to consider the response fresh for 600 seconds, while all other caches are prevented from storing it:

Cache-Control: no-store
CDN-Cache-Control: max-age=600

Because CDN-Cache-Control is not present, this header field prevent all caches from storing the response:

Cache-Control: no-store

Whereas these prevent all caches except CDN caches from storing the response:

Cache-Control: no-store
CDN-Cache-Control: none

(note that 'none' is not a registered cache directive; it is used here to avoid sending a header field with an empty value, because such a header might not be preserved in all cases).

Cache-Status

2022-02-25T13:00:00+11:00

Diagnosing CDN caching can be complex, with multiple cache layers, Origin Shielding, and local caching. Understanding how these layers interact can mean spending weeks working through RFCs for the finer details of ETag, Cache-Control, and Last-Modified headers - before you even account for advanced controls that override them.

When you have a problem, or are trying to optimise caching, the first thing you need is visibility into how a request was handled.

This is where the new Cache-Status header helps. The new draft RFC, RFC draft-ietf-httpbis-cache-header-08, aims to:

  aide debugging by standardising the format of various non-standard debug headers
  used by major CDN providers. The semantics of these headers are often unclear and vary
  between implementations.

The draft RFC proposes a new header, Cache-Status, with a uniform format for showing how multiple caching providers interact and handle a request. The Cache-Status header forms a list. Each member of the list represents a cache that has handled the request, and the last member belongs to the cache that most recently served the user. The header is only applicable to responses directly generated by an origin server. Each member can add a parameter indicating how it handled the request.

A Cache-Status header looks like this:

  Cache-Status: OriginCache; hit; ttl=1100, "CDN Company Here"; fwd=uri-miss;

It is formatted and labelled, with each cache in the line separated in list format by a ','.

The format of the Cache-Status header is a list comprising of the following possible parameters:

hit = boolean
fwd = (bypass, method, uri-miss, vary-miss, request, stale, partial)
fwd-status = integer
ttl = integer
stored = boolean
collapsed = boolean
key = string
detail = token / string

What the parameters mean

Hit

The hit parameter signifies that a request was satisfied by the cache. It is a boolean parameter meaning that its presence indicates a cache hit.

For example:

  Cache-Status: Peakhour.IO; hit

Fwd

The Fwd parameter indicates when a response was forwarded to an origin server - and why. The Fwd parameter contains one of the following arguments:

bypass - The cache was configured to not handle this request
method - The request method's semantics require the request to be forwarded
uri-miss - The cache did not contain any responses that matched the request URI
vary-miss - The cache contained a response that matched the request URI, but could not select a response based upon this request's headers and stored Vary headers.
miss - The cache did not contain any responses that could be used to satisfy this request (to be used when an implementation cannot distinguish between uri-miss and vary-miss)
request - The cache was able to select a fresh response for the request, but the request's semantics (e.g., Cache-Control request directives) did not allow its use
stale - The cache was able to select a response for the request, but it was stale
partial - The cache was able to select a partial response for the request, but it did not contain all of the requested ranges (or the request was for the complete response)

For example:

  Cache-Status: Peakhour.IO; fwd=uri-miss

Fwd-status

The fwd-status parameter indicates the status code the next hop returned in response to the request. It is only meaningful when "fwd" is present. For example, a complete miss would look like fwd=uri-miss and the HTTP status code of the downstream response would be supplied in the fwd-status:

The following example shows that the cache did not satisfy the request and that the downstream server indicated an HTTP 304 response - HTTP Not Modified.

  Cache-Status: Peakhour.IO; fwd=uri-miss; fwd-status=304

ttl

Each cache item is associated with a lifetime, referred to as the Time To Live (TTL). A TTL is in seconds and indicates the remaining freshness of the resource. This value is calculated by the cache.

For example, a cache hit showing that the resource has a freshness of 376 seconds.

  Cache-Status: ExampleCache; hit; ttl=376

Another example shows a cache hit with negative freshness - a stale resource.

  Cache-Status: ExampleCache; hit; ttl=-412

stored

Indicates whether the received response was stored by the cache. This example shows a cache miss and the cache storing the response for the next hit.

  Cache-Status: ExampleCache; fwd=uri-miss; stored;

collapsed

Indicates whether the received response was collapsed with another request.

key

The key is the lookup index into a cache. Cache keys convey a representation of how the cache will look up the resource used for the response. The cache key is implementation-specific.

This example shows a cache hit, the cache key and secondary key, and the remaining TTL of the resource.

  cache-status: peakhour.io; hit; key="https://example.com/calendar.css"; secondary-key="encoding::gzip"; ttl=30674859

detail

Allows additional implementation-specific information not captured by other parameters.

Multiple layers of caching

The header allows multiple layers of caching. For example, a global CDN may sit in front of a local varnish server. Each cache appends its cache-status to the header, so the last item is the closest cache to the actual application and the first item is the closest cache to the accessing user.

  Cache-Status: OriginCache; hit; ttl=1100, "CDN Company Here"; hit; ttl=545

Security

There are security implications to consider with this header. Making it public gives an attacker insight into how the cache is configured, which may help them bypass a cache entirely and access an origin server directly. Cache header security is provider-specific, but could involve enabling it only when required, restricting access to specific IP addresses, or requiring a custom request header to trigger the cache-status header.

Peakhour.IO regularly sees automated scans sending other providers' headers to trigger a cache-status header response.

Conclusion

The Cache-Status header gives clear insight into how cache layers interact on a website. It provides a standardised format for showing how a cache handled a request and allows multiple caches to report their part of the request path.

Peakhour fully supports this new header, and it can be enabled/disabled and secured in the dashboard.

What is the Chrome UX Report (CrUX), and why should you care?

2021-02-26T13:00:00+11:00

A slow page can lose a customer before the application gets a chance to do its job. Google also uses Core Web Vitals within its page-experience systems. That makes performance a ranking input, not a promise that one faster page will outrank another or that a Lighthouse score will reduce advertising costs.

We've previously written about Google's Web Vitals. The practical question is where the real-world data comes from. It is not gathered by Googlebot. Google uses field data from the Chrome User Experience Report, usually shortened to CrUX, to show how eligible Chrome users actually experienced a page or origin.

That matters because a fast lab score is not the same thing as a fast customer experience. WebPageTest and Lighthouse help diagnose a controlled test run. CrUX shows the field data behind PageSpeed Insights, Search Console's Core Web Vitals report, and Peakhour's website speed comparison tool.

Introducing the Chrome UX Report (CRuX)

The CrUX report is a public data set of real-user measurements (RUM) of website performance across millions of sites. The report has been around since 2017 and is updated regularly, but the value is still often missed: it shows what real users experienced, not what a synthetic test predicted.

The data is collected from real Chrome browser users who have opted in to send browsing information back to Google. This opt-in requires that the user has:

Opted in to syncing browser history
Not set up a sync passphrase
Usage statistic reporting enabled

Despite these conditions, millions of Chrome users still report statistics back to Google. A given website still needs to be fairly busy before there are useful statistics in the report.

Gathered Metrics

The current Core Web Vitals are:

Largest Contentful Paint (LCP): how quickly the main content appears.
Interaction to Next Paint (INP): how responsive the page is to real user interactions.
Cumulative Layout Shift (CLS): how visually stable the page is while it loads.

CrUX also exposes supporting performance metrics and dimensions that help explain those headline scores. Older metrics such as First Input Delay (FID) still appear in older reports and tools, but INP is now the responsiveness metric to watch.

Dimensions

Because performance can vary widely, the metrics are divided into the following dimensions to help segment and understand the user experience.

Country
Device Type: Tablet, Phone, Desktop
Connection Speed: slow 2g, 2g, 3g, 4g, or offline

Viewing data in the report

There are several ways to see how your website performs in the report. These include:

Pagespeed insights

Google's website analysis tool provides summary CRuX data for the analysed URL and, if data is available, for the entire site.

Page Speed Insights Field Data" style="max-width: 100%;margin-bottom: 20px"/>

Google BigQuery

The most flexible option is to access it directly via BigQuery. You query it with SQL (database query language).

The downside is that you need to understand SQL and have a Google account.

Google's Search Console (formerly Webmaster Tools)

The search console now has a section 'Core Web Vitals' that shows whether URLs pass the Core Web Vitals, as well as a historical graph of performance for both mobile and desktop.

Looker Studio

Looker Studio, formerly Google Data Studio, can be used to build dashboards on top of CrUX data and other sources. It lets you visualise the performance of your website, or a competitor's website, over time.

Third party tools

Like our own website speed comparison tool. It uses the Chrome UX API to retrieve the information.

CrUX vs lab tools vs RUM

CrUX is field data. It is useful because it reflects real Chrome users, but it only reports where there is enough eligible traffic. It can also be slower to reveal the cause of a problem because it is aggregated.

Lab tools such as WebPageTest are better for diagnosis. They show waterfalls, redirects, blocked resources, caching issues, image weight, and third-party requests. Your own real user monitoring can go further again, because it can include business context that CrUX does not know: customer type, template, campaign, cache state, bot pressure, origin load, and release timing.

Put field data beside the release

The data in the Chrome UX Report is one of the clearest public views of how Google sees the performance of your website. It is also a free source of real-world user measurements that helps you understand how visitors experience your pages.

Use CrUX to see whether your site is passing Core Web Vitals, use lab tools to find the technical cause, and use traffic visibility to understand whether bots, crawlers, bursts, cache misses, or expensive requests are putting the experience under pressure. If the first question is "how do we compare?", start with the website speed comparison tool. If the question is "what is slowing us down?", start with Traffic Management.

The CDN is Dead, Long Live the CDN!

2021-02-17T13:00:00+11:00

It has long been conventional wisdom that if your website uses a third-party library, such as jQuery or Bootstrap, you should load it from the library's high-performance CDN. For example, jQuery has

code.jquery.com

from which you can include any version of jQuery on your website, e.g.:

<script src="https://code.jquery.com/jquery-3.3.1.min.js"
          integrity="sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8="
          crossorigin="anonymous"></script>

This was meant to give you two performance benefits: the browser could load jQuery from a global CDN, AND if another site the visitor had already opened included the same jQuery file in the same way, the file might already be in their browser cache. In that case the browser could reuse the cached copy and the page would load faster.

In practice, website visitors rarely see much benefit. The browser still has to open a separate connection to the third-party CDN, which can cancel out any latency advantage the CDN provides. There are also so many versions of major libraries in use that the chance of two websites using the same version, AND both loading it from the CDN in the same way, is small.

Cache Partitioning in Chrome and Firefox

Until recently, Chrome and Firefox used a shared browser cache for all websites that a user visited. This means that if you visited a website and it loaded this resource:

https://www.somesite.com/foo.js

and you then visited a second website that included the same resource, the resource would be loaded from the shared cache rather than being downloaded from the internet a second time. Cookies set by these resources would also be shared.

As of Firefox v85 and Chrome v86, the browser cache will be partitioned. This means that the same resource included on two sites will have to be downloaded from the internet twice and stored separately.

Why are they doing this?

The main reason is privacy. Shared browser caches have been used by unscrupulous operators to track users across different websites without consent. They do this by utilising cache side-channel attacks.

What Are Side Channel Attacks?

In computer systems, a program or algorithm can be correct and secure in itself, while its interaction with the computer still leaves information that an attacker can exploit. A useful analogy from the spy world is using a laser beam to measure the vibrations on a pane of glass, so you can hear a conversation inside a room that you otherwise could not hear.

Side-channel attacks can be ingenious, utilising techniques such as:

observing power consumption/electromagnetic radiation;
timing data moving in and out of memory;
timing how long a CPU takes to execute an instruction;
measuring sounds emitted by a hard drive.

For the browser cache, a simple attack starts with the user opening a malicious website. That website then requests resources (e.g., an image) from another site. By timing how long the browser takes to load that image, it can determine whether it was fetched from the browser cache or had to be downloaded over the internet. According to Google, this technique can be used to:

Detect if a user has visited a specific site.
Detect if an arbitrary string is in the user's search results by checking for 'no search result' images used by particular sites.
Track users across sites using the cache.

GitHub user terjanq has published a cache side channel attack that can gather all sorts of information from Google services. He states that a regular Google user could have the following information leaked:

search history
videos watched
the exact URLs visited
time frames of the activities
private book collection
books read / purchased / bookmarked / favourite / etc.
private emails
tokens / credit card numbers / phone numbers / etc.
contacts (including email addresses, names, phone numbers)
bookmarked websites
and more.

Perhaps it was simpler to implement cache partitioning in Chrome than to keep patching these vulnerabilities...

What you should do

Google estimates that the changes in browser caching will have minimal impact, as little as a 0.3% difference in FCP (First Contentful Paint). However, since there will no longer be any shared-cache benefit from hosting on a third-party CDN, you should:

Host all third-party libraries on your own domain to eliminate the need for the browser to establish a second connection.
Use a delivery layer such as Peakhour Edge, which transparently caches and serves your website assets close to users.

Conclusion

Some third-party resources really are shared across millions of websites. Google Fonts is the obvious example. Under the new cache partitioning implementations, these fonts will have to be downloaded for every site that uses them. That has a cost for site speed and data usage. It also has the side effect of improving Google's ability to track users, because each font request tells Google another site the user has visited.

Safari has been partitioning the HTTP cache since 2013, leaving Microsoft's Edge as the last major browser with global HTTP caches. However, future versions will be based on Chromium (the open-source version of Chrome) so should get cache partitioning by default.

Is your website obese?

2020-03-19T13:00:00+11:00

Page weight has increased steadily since the early web, as connection speeds improved and sites became more interactive and visually rich. The HTTP Archive shows over a 300% increase over the last 10 years.

MEDIAN DESKTOP
1957.8 KB
▲318.6%

MEDIAN MOBILE
1791.9 KB
▲1137.5%

Why should I care?

Smaller page weight = Faster page load

Page weight directly affects page load times. The smaller the page, the faster your site can load. The slower the connection, the more obvious the effect. Faster page loads are associated with higher conversion rates, fewer bounces, and higher engagement with your site.

Smaller page weight = Less bandwidth = Savings

Your hosting provider or CDN may charge for data transfer. Reducing page size can reduce those costs.

How big is too big?

Google says that, to meet its best practice guidelines, you should aim for a page weight of 500 KB on mobile devices and a request count of fewer than 50.

What can I do to shrink my page weight?

Start with the bytes that browsers have to download, parse, and render.

1. Optimise Images

Images are often the biggest contributors to page weight. Careful optimisation can reduce their size without a noticeable loss in quality.

Compression: Use image compression tools to reduce file sizes. For JPEGs, a quality setting of 75-85% is often a practical balance.
Use Next-Gen Formats: Formats like WebP and AVIF compress better than older formats like JPEG and PNG. Modern browsers have wide support for them.
Responsive Images: Use the <picture> element or srcset attribute to serve different image sizes for different screen resolutions. There is no reason to send a large desktop image to a mobile phone.
Lazy Loading: Load images only when they are about to enter the viewport. This does not reduce total page weight, but it improves the initial load time.

2. Minify CSS, JavaScript, and HTML

Minification removes unnecessary characters from source code without changing its functionality. That includes white space, comments, and line breaks. Many build tools, including Webpack, and CMS plugins can automate this process.

3. Enable Server-Side Compression

Enabling compression like Gzip or Brotli on your web server can reduce the size of the HTML, CSS, and JavaScript files sent to the browser. Brotli offers better compression than Gzip and is supported by all modern browsers.

4. Leverage Browser Caching

Set appropriate Cache-Control and Expires headers so the browser can store files locally. On later visits, the user's browser can load those files from its local cache instead of downloading them again, making return visits much faster.

5. Remove Unused Code

Many websites, especially those built on complex themes or frameworks, load large CSS and JavaScript files with code that is never used. Use browser developer tools, such as the Coverage tab in Chrome DevTools, to identify and remove unused code. For JavaScript builds, this process is often called "tree-shaking," and it can significantly shrink your file sizes.

6. Use a Content Delivery Network (CDN)

A CDN stores copies of your assets on servers around the world. When a user visits your site, those assets are served from the server closest to them, reducing latency. Many CDNs also provide automatic optimisation features such as image compression and minification.

Final Thoughts

Reducing page weight is ongoing work. A lighter, faster website gives users less to wait for, improves search engine rankings and conversion rates, and reduces the amount of data you have to serve. Start with images, compression, caching, and unused code; those changes usually give you the clearest wins.