Why it occurs, and what is the impact on web performance?

Last year Google announced updates to Chrome that provide a way for developers to control how cross site cookies should work on their sites. This is a good change - as it ultimately improves end user security and privacy by limiting which third parties can read cookies that were set while visiting a different site. It also defeats cross site request forgery attacks. The implementation is fairly simple, and only requires developers to add the SameSite attribute to their cookies.

Back in 2017 the maximum validity lifetime for an HTTPS certificate was set to 825 days, a decision that was widely supported by both browsers and certificate authorities. However, since then there have been multiple unsuccessful attempts at reducing the maximum lifetime to one year. Scott Helme has written about this previously, and his blog post noted that browser vendors unanimously supported this while some certificate authorities objected to it.

According to the HTTP Archive, 84% of HTTPS certificates are using the Subject Alternate Name (SAN) extension, which allows multiple hostnames to be protected by a single certificate. The largest certificate I found in the HTTP Archive contained a whopping 1275 alt-names! During this post we’ll explore why this is a web performance problem, and how you can determine what a reasonable limit would be for your certificates.

Earlier this year the Chrome team announced plans to support lazy loading natively in the browser. The plan was to add a loading attribute in both <img> and <iframe> elements. Chrome 75 included it behind a feature flag so that developers could test it out. Last week, with the release of Chrome 76 this feature became generally available. I was surprised to see that it is already in use by more than 1000 sites. Lazy loading is an easy web performance win, so you may want to try this out on your sites.

Have you ever wondered how old web content is? One could probably assume that HTML is going to be newer than images or JavaScript, but is that really true? How does resource age vary by content type or by first or third party content? And why does this matter?

The JavaScript Console API is an incredibly useful feature that provides access to the browsers debug console from a web page. It can be accessed from any global object, and it’s common to call methods such as console.log() to print messages for debugging purposes. For example:

When we talk about cacheability of web content, often times the discussion is around content that site operators have control over (ie, first party content). But what about third party content? How much of that is cacheable? I was chatting with @yoav about this on Friday, since it could be useful to understanding the benefits of signed exchanges on accelerating third party content. Is it worth delivering cross origin resources on a site’s HTTP/2 connection, avoiding the need to establish a new connection and eliminate bandwidth contention between 3rd party resources and 1st party ones? In order to answer that we need to understand how many third party resources are delivered without credentials, and therefore can be signed. We will use the resource’s public cacheability as a proxy for that, and try to understand how common such third party resources are.

Lighthouse is an amazing tool that you can use to quickly audit a web page and learn how it stacks up on performance, accessibility, best practices, PWA support and more. You can run it from ChromeDevTools, run one via WebPageTest measurement or analyze them in bulk here! For every page measured in the HTTP Archive a lighthouse audit is run, and the results are stored in the lighthouse tables.

When we talk about web performance measurement, there is a long list of metrics to choose from. As an industry we are converging on metrics that gauge user experience – such as “Time to Interactive” and “Time to Visually Ready”. Other metrics such as onLoad and First Contentful Paint are also widely used and available in most browsers via APIs such as Navigation Timing and Paint Timing. And then there are Speed Index, Start Render, Fully Loaded time and many others, including protocol times (DNS/TCP/TLS) and backend times (TTFB). You are optimizing your sites and have all these measurements at your disposal – so what do you use to evaluate your changes?