Tag: Performance

The 95th percentile of RUM data is a great place to assess the slowest experiences. In this case, we see that the streaming Service Worker confers a 40% and 51% improvement in FCP and LCP, respectively, over no Service Worker at all. Compared to the “standard” Service Worker, we see a reduction in FCP and LCP by 19% and 43%, respectively.

What a fantastic article from Jess Peck on Cumulative Layout Shift. It’s approachable to folks new to the metric, detailed and in-depth and wildly entertaining (more entertaining than a post this informative has any right to be).

An in-depth, well researched guide to measuring Core Web Vitals from Barry (par for the course for him).

A smart little list of optimizations for loading images efficiently. Using the bytes if the image as a hash for automatic cache busting if the image changes is particularly clever.

Alex posted a follow-up to a prior post on avoiding scrollbar jumping when using content-visibility.

It’s clever stuff—the combination of ResizeObservers and IntersectionObservers helping to avoid the shifting around that would occur otherwise.

This doesn’t do much though to eliminate the reservations I have about content-visibility. In theory, it’s a great addition, but the fact that it seems to need so much supporting scaffolding to make it usable for a relatively simple use-case makes me feel like it may be missing a few other pieces of native plumbing before it’s really ready for primetime.

Sad, but true words:

For a few months, those who will buy M1 machines will enjoy great responsiveness and blazing start-up time. Some once bloated applications will again behave like most tools should. But soon these metrics will start to degrade. Responsiveness and start-up time will progressively revert to what they used to be and old “non-M1” machines will become even slower than they used to.

For every cycle a hardware engineer saves, a software engineer will add two instructions.

Super clever stuff from Andy about how he’s using Cloudflare Workers and WebPageTest to test performance optimizations. I’ve done a little of this, but there’s a bunch here I haven’t played with. Going to have to change that for sure!

I’ve been super keen on getting some sort of way to measure when the accessibility tree is ready ever since first chatting about it with Marcy Sutton 5 years ago or so. Scott has a great post here about why it’s important. He’s also filed issues on WebPageTest and Lighthouse to get something added. Hopefully we’ll see something soon!

The folks at Chrome, talking about the business impact of hitting their Core Web Vitals thresholds:

We analyzed millions of page impressions to understand how these metrics and thresholds affect users. We found that when a site meets the above thresholds, users are 24% less likely to abandon page loads (by leaving the page before it finishes loading).

We also looked specifically at news and shopping sites, sites whose businesses depend on traffic and task completion, and found similar numbers: 22% less abandonment for news sites and 24% less abandonment for shopping sites.

Super interesting insight into how the folks over at Google came up with their new Core Web Vitals—including everything from how they figured out what “good” or “poor” looked like, how they chose which percentiles to look at, and more.

We recognize, of course, that “Always accessible” is not a novel approach. Here in California accessibility is a guiding principle in the state’s digital strategy. And our work is just one part of the state’s larger commitment to ensuring that information and services are accessible.

What is novel is how our team is broadening the definition of accessibility for state government to include performance as a core component. Performance as accessibility.

Our goal is to make COVID19.CA.gov fast and easy to use on any kind of hardware or with any level of bandwidth. 

Netflix talks about the security and performance implications of rolling out TLS 1.3. Seeing a 8.2% improvement in play delay at the 95% percentile—not too shabby!

Detailed post about how v8 used Pointer Compression to reduce heap size by up to 43%, resulting in less CPU usage and less time on garbage collection.

It’s…dense. I’m going to likely have to re-read this several times to really understand all the details. Lots of interesting bits here.

Some staggering stats from Fastly showing how traffic and download speed have changed during the COVID-19 pandemic.

Performance has quite literally never been more important.

Visits to news sites went up as much as 60%. And people are spending more time playing online games.

A similar pattern is emerging in the U.S. Cloudflare says Internet traffic jumped 20% on Friday, after President Trump declared the pandemic a national emergency. In hard-hit Seattle, Internet use was up 40% last week compared to January.

Latest data put out by the telecom regulator pegs the average monthly wireless data usage per user at 10.37 GB, which analysts say could rise by around 15% in the next two quarters if people continue to work from their homes over a prolonged period.

Was going to build this myself, but turns out I don’t have to!

A handy suite of tests (from Mark Nottingham) to see how different browsers respond to various caching headers.

A rather clever way of looking at performance data by breaking it down into histogram “regions”.

Fantastic post detailing Shopify’s work optimizing their admin pages. There are some good pointers around profiling and optimizing React, as well as a lot of thoughtful insights on designing in-between states.

Remy building on someone else’s (smart!) post about lazy-loading YouTube embeds.

Gosh I miss when this “someone blogs and then someone else iterates on that on their own blog” thing was more common.

Surma argues, compellingly, for why web workers need to take a more prominent role in JS-based applications. It’s not just about the raw performance benefits, but the inclusivity that good performance brings.

Unless a globally launched framework labels itself as exclusively targeting the users of the Wealthy Western Web, its has a responsibility to help developers target every phone on The Widening Performance Gap™️ spectrum.

For government, GOV.UK is often the only place a user can get information. If the website were to perform badly, we become a single point of failure.

Great rundown of why performance is so important to GOV.UK and how the context of their visitors can vary dramatically, even within the same city.

In this post, we’ll look at the new loading attribute which brings native <img> and <iframe> lazy-loading to the web!

Exciting to finally see this ship! Folks have been asking for a standards-based way to support lazy-loading images for years.

Gives me hope that maybe, someday, we’ll have element queries.

I always like seeing how other folks handle performance audits. Here, Jake walks through 10 F1 sites, auditing them primarily with WebpageTest and a smattering of Chrome Dev Tools.

Handy little reference from Addy Osmani showing how Chrome handles JavaScript scheduling.

I’ve being using preload with clients over the last few years but I have never been completely satisfied with the results. I’ve also seen some things I hadn’t quite expected in page load waterfalls so decided to dig deeper.

Excellent work digging deeper into preload by Mr. Davies.

Ten years ago the network was the main bottleneck. Today, the main bottleneck is JavaScript.

A very approachable explanation from Sarah about what Hooks are and the problems they solve for Vue.

Pat has been doing some intense research around HTTP/2 prioritization which lead to this magnificent post discussing how each browser handles priorities (not well, for the most part) and also provides a handy test page for checking how CDN’s and servers are doing.

Andy has already taken that page and started tracking how CDN’s are doing (again, not well for most of them).

While ever you build under the assumption that things will always work smoothly, you’re leaving yourself completely ill-equipped to handle the scenario that they don’t.

I rather like Scott’s term for what happens when you use client-side JavaScript for A/B testing.

This pattern leads to such a unique effect on page load that at last week’s Perf.Now() Conference, I coined a new somewhat tongue-in-cheek performance metric called “Second Meaningful Content,” which occurs long after the handy First Meaningful Content (or Paint) metric, which would otherwise mark the time at which a page starts to appear usable.

Lovely performance “postmortem” from Eli Fitch about how MapBox got their first-meaningful-paint to drop from 4.7s to 1.9 seconds.

Some good insights into technical optimizations, but as always, the cultural aspects are the most difficult–and the most important.

Nurturing cultural awareness and enthusiasm for building fast, snappy, responsive, tactile products is arguably the most effective performance improvement you can make, but can be the most challenging, and requires the most ongoing attention.

I like Harry’s categorization for performance testing:

I try to distill the types of testing that we do into three distinct categories: Proactive, Reactive, and Passive.

I’ve been using “Active” and “Passive” myself and found that it really helps companies better understand why having both synthetic and RUM monitoring in place is important. I really like the way Harry breaks that “Active” category out further based on whether the tests are run proactively or reactively.

Removing the Base64 encoded font has reduced the total page weight by 16% (75 KB) per request (assuming no caching). This may not sound like a huge difference, but GOV.UK receives approximately 48 million visitors per month, so this adds up to mobile users saving approximately 800 GB per month, cumulatively. This is especially important to users on older mobile devices and expensive data plans.

You can take Paul out of dev-rel, but you can’t take the dev-rel out of Paul. Or something.

Really enjoying Paul’s videos. They’re entertaining, really high quality and super useful.

Clever stuff from Nolan about trying to measure the complete cost of a component—not just the JS execution.

This was a really fascinating post about trying to make a web site—from design down to the hardware that powers it—as energy efficient as possible. This is certainly at the extreme end of optimization, which is what made it so interesting.

They do admit that since the server is powered via solar, it’s possible they may have some downtime. I bet they could provide themselves with another layer of protection with a small service worker.

What a fantastic deep-dive! Antin walks through how Google Photos built a performant photo grid in great detail. There’s a lot of careful thinking in here and some clever solutions.

What a great overview of how NerdWallet made their site significantly faster (6s faster time to visually complete as measured on a 3G network) in the last 6 months or so.

Surma talks about the different ways of forcing an element to be on its own element, and—most interestingly—the side-effects of each.

As per his usual, good advice from Zach about loading fonts: this time, advising not to pair font-display: optional with preload.

Mr. Calvano with a really good explanation of HTTP Caching. Particularly interesting to me was the bit about the heuristic cache limits of different browsers—something I had never really dug into.

In the Chromium source as well as the Webkit source, we can see that the lifetimes.freshness variable is set to 10% of the time since the object was last modified (provided that a Last-Modified header was returned). The 10% since last modified heuristic is the same as the suggestion from the RFC. When we look at the Firefox source code, we can see that the same calculation is used, however Firefox uses the std:min() C++ function to select the less of the 10% calculation or 1 week.

An incredibly detailed walkthrough of optimizing the heck out of some JavaScript. Some really impressive gains here and lots of great, low-level information.

The folks at Mozilla have been super busy making some fantastic improvements to Firefox. Among other things, their performance profiling tools have gotten pretty darn slick. Greg Tatum made a playlist of a bunch of short videos demonstrating how to use perf.html and the Gecko Profiler to inspect the performance of a site or application.

As usual, Ethan makes a lot of sense in this post about how the way we build is impacted by the environment in which we build:

In our little industry, we often work on decent hardware, on reliable networks. But according to Pew Research, thirty percent of Americans don’t have broadband at home. One in ten American adults are smartphone-only internet users, while 13% of American adults don’t use the internet at all.

Meanwhile, we make mobile-friendly websites with widescreen devices, using broadband to design experiences for slow, unstable networks. In a lot of ways, we’re outliers among the people we’re designing for.

Una recently added a “Save Offline” button to her blog posts that gives users control over whether an article will be saved offline or not. There was some recent discussion prompted by Nicholas Hoizey about how much data is too much to save offline. Giving users control (whether on an individual post basis or in bulk) seems like one way to deal with that question.

The smart folks at Google are now using a technology called RAISR to shave up to 75% off the file size of the images they display. It uses machine learning to enable it to be much more intelligent about the upsampling methods applied to images. Clever stuff!

Pretty impressive investigation and creative work done by the GitHub folks to make their diff pages, some of the slowest on the site, three times faster.

I love companies that are as invested in giving back to the community as they are at doing quality web-work. The Guardian is certainly one of them, and their latest post is a great example. They walk through several errors and mistakes they made on their site this year, why those mistakes were made, and how they fixed them.

Great introduction to the various different types of browser caches by Yoav Weiss, told as a tale about Questy’s Journey. The illustrations by Yoav’s daughter, Yaara, are also wonderful.

Sarah has written a really useful post about the different roles animation can play. Naturally, I was really happy to see her talking about the impact on perceived performance:

Animation also aids in perceived performance. Viget conducted a study where they measured user engagement with a standard loading GIF versus a custom animation. Customers were willing to wait almost twice as long for the custom loader, even though it wasn’t anything very fancy or crazy. Just by showing their users that they cared about them, they stuck around, and the bounce rates dropped.

In most cases, I’d argue, it would be even better to provide some sort of feedback to the user about what is happening in the background, but the same general idea applies: taking the time to design for when processes take too long is important.

Vitaly published a lengthy checklist of performance optimizations, which I was more than happy to review. There are PDF and Apple Pages versions available of the list if that’s your cup of tea.