Articles Tagged performance

Scott Jehl argues that performance metrics such as First Contentful Paint and Largest Contentful Paint don’t really capture the full picture of everyone’s experience with websites:

These metrics are often touted as measures of usability or meaning, but they are not necessarily meaningful for everyone. In particular, users relying on assistive technology (such as a screenreader) may not perceive steps in the page loading process until after the DOM is complete, or even later depending on how JavaScript may block

Here’s a fantastic case study where Ivan Akulov looks at the rather popular writing app Notion and how the team might improve the performance in a variety of ways; through code splitting, removing unused vendor code, module concatenation, and deferring JavaScript execution. Not so long ago, we made a list for getting started with web performance but this article goes so much further into the app side of things: making sure that users are loading only the JavaScript that they … Read article “Analyzing Notion app performance”

Instant.Page does one special thing to make sites faster: it preloads the next page when it’s pretty sure you’re going to click a link (either by hovering over 65ms or mousedown on desktop, or touchstart on mobile), so when you do complete the click (probably a few hundred milliseconds later), it loads that much faster.

It’s one thing to understand that approach, buy into it, integrate it, and consider it a perf win. I have it installed here!

It’s another … Read article “A/B Testing Instant.Page With Netlify and Speedcurve”

Harry Roberts:

The numbers so far show that the difference between no compression and Gzip are vast, whereas the difference between Gzip and Brotli are far more modest. This suggests that while the nothing to Gzip gains will be noticeable, the upgrade from Gzip to Brotli might perhaps be less impressive.