• Get a DevTools performance trace for a page load
• Get a DevTools trace with screenshots
• Get a DevTools trace and extract filmstrip screenshots
• Get a DevTools trace for a user interaction
• Get Runtime performance metrics
• Generate a Lighthouse report
• Extract Lighthouse performance metrics
• Emulate a slow network
• Emulate a slow network and CPU
• Test your site renders with JavaScript disabled
• Get Navigation Timing API metrics
• Measure First Paint and First Contentful Paint
• Measure Largest Contentful Paint w/PerformanceObserver
• Measure Cumulative Layout Shift w/PerformanceObserver
• Measure SPA metrics with Next.js
• Get DevTools-specific metrics: Frames Per Second
• Measure memory leaks
• Override requests with Request Interception
• Block third-party domains
• Code Coverage for JavaScript and CSS

We have seen that there can be many reasons for users to opt-in to save-data, and that the performance delivered to devices doesn’t (yet) vary much based on the hint. A lack of awareness from both developers and web users mean that a potentially valuable web platform feature is under utilized.

So you have to be really careful when using this metric, the LCP is not always tracking the element you think

And for what? Again - there is a swath of use cases which would be hard without React and which aren’t complicated enough to push beyond React’s limits. But there are also a lot of problems for which I can’t see any concrete benefit to using React. Those are things like blogs, shopping-cart-websites, mostly-CRUD-and-forms-websites. For these things, all of the fancy optimizations are optimizations to get you closer to the performance you would’ve gotten if you just hadn’t used so much technology.

The issue with most slow JAMstack sites is that they load a loooot of JavaScript. Remember that any added JavaScript has to be sent to the browser, which will also need more computation for it. It quickly impacts performance.

Web Performance and Web Performance Optimization are still valid and descriptive terms for our industry, but we might benefit from a change to our language when working with others. The language we use could be critical to the success of making the web a faster and more accessible place.

It would seem that, realistically, the benefits of Brotli over Gzip are slight.
[…]
if you’re faced with the prospect of weeks of engineering, test, and deployment efforts to get Brotli live, don’t panic too much—just make sure you have Gzip on everything that you can compress (that includes your .ico and .ttf files, if you have any).

You know, faster websites mean happier users. It’s absolutely in no doubt. And I just don’t get it, to be honest. I don’t get how people can be working on the web claiming to be doing user centered design and yet, at the same time, ignoring this huge factor.

Good frameworks should provide a better starting point on the essentials (security, accessibility, performance) or have built-in constraints that make it harder to ship something that violates those.

That doesn’t appear to be happening with performance (nor with accessibility, apparently).

Today, we'll look at measuring React component render performance with the React Profiler API, measuring interactions with React's new experimental Interaction Tracing API and measuring custom metrics using the User Timing API.

I'm pretty happy to have cut the size of images on my blog by ~50%. In addition to the benefits to user experience at a critical time, I'm also expecting that this'll save me some money in terms of bandwidth.

One of the advantages of this API is that you don't have to use a library for this kind of job anymore. The majority of browsers are providing a lot of support for some of the newest and awesome APIs, and this has been improving the experience for users in general, allowing developers to use some native browser APIs and reducing their final code bundle.

I love improvements that just work without any effort required of website owners. […] The less friction we can add to introduce these improvements, the more likely they will be adopted, and there’s no better friction than none at all! Fixing the impact of layout shifts on users for responsive images seems to be one such improvement and the web is all the better for it.

Variable fonts reduce the overall combined file size and automatically reduce the number of network requests by simply being a variable font.
Even if you consider the slightly larger file sizes, when combined with improved font compression formats like WOFF2, font subsetting and font loading techniques like font-display: swap; we end up in a situation where we can still get smaller overall font file sizes as well as a significant increase in stylistic opportunity.

To make sure our apps are as reliable and accessible as possible, especially in an increasingly globalized marketplace, we need to support constrained devices—they're how most users are accessing the web globally. OMT offers a promising way to increase performance on such devices without adversely affecting users of high-end devices.

And there you have it, a way to change the font-display settings of a page when using WebPageTest. No need to manually update the code to see what effect the property has on a pages perceived performance.

In this post, I’ll discuss what I did at ALDO to measure the revenue impact of web performance without having to spend time making performance improvements.
[…]
Back in October, rendering performance was something we had never focused on. Nobody was really talking about it, so there must be nothing there. It was only after we started measuring that we saw the potential.

A lot of performance issues stem from them simply not being very noticeable to those of us doing the building. Changing that wherever we can is one of the best ways to make sure that all that low-hanging fruit doesn’t go overlooked.

The prefers-reduced-data media feature is used to detect if the user has a preference for being served alternate content that uses less data for the page to be rendered.