Links on Performance IV

Publikováno: 3.9.2021

#Article #performance

HTTP Caching is a Superpower — Hugh Haworth covers how the Cache-Control header is an awfully potent ingredient in web performance. I mis-read the title at first and was waiting to read about HTML caching. Hugh covers it a bit

…

The post Links on Performance IV appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

Celý článek

HTTP Caching is a Superpower — Hugh Haworth covers how the Cache-Control header is an awfully potent ingredient in web performance. I mis-read the title at first and was waiting to read about HTML caching. Hugh covers it a bit (like how you’d need to be careful doing so on something like a forum, where the content on pages changes rapidly), but I find it something that’s generally under-talked-about. As in, generally, people just don’t cache HTML at all, because it changes the most and it’s risky being the parent of most other cache. I only do it now because Cloudflare handles it.
Why it’s okay for web components to use frameworks — I admit it rubs me the wrong way to think of web components as needing a framework at all, let alone being OK with a hogepodge of random frameworks. But Nolan Lawson digs into the nuance here. A couple of kilobytes that might be lazy loaded/code-split out is not that big of a deal, especially since the frameworks might be optimized for runtime performance.
web-vitals-element — An npm packages from Stefan Judis that boots up a <web-vitals> web component showing your CLS, FID, LCP, and BVD (demo). Sorta weird it won’t build on Skypack.
Top 10 performance pitfalls — I probably wouldn’t have guessed any of the things Jake and Surma cover in this top 10 list. My guess is that the low hanging fruit of performance either becomes a bunch of non-issues through technological improvements, or it is generally handled by site owners and hosts and, thus, a new set of problems become the top offenders.
How to Eliminate Render-Blocking Resources: a Deep Dive — Sia Karamalegos: Render-blocking resources are files that ‘press pause’ on the critical rendering path. They interrupt one or more of the steps. You should be super aware of anything that is render-blocking and only render-block on purpose (like critical CSS) rather than letting it happen by accident.
How we reduced Next.js page size by 3.5x and achieved a 98 Lighthouse score — Colin Armstrong covers how dynamically loading assets, reducing the size of assets, and using responsive images goes along way. Fortunately, the tooling to diagnose performance problems and the tools for solving them are largely build into Next.js. The bit about PurgeCSS and Tailwind seems extra pertinant here. I think if you aren’t using PurgeCSS to remove unused Tailwind selectors (or the JIT compiler to only create the selectors you need), you’re basically doing Tailwind wrong. Shipping 350KB of CSS instead of the 10KB you need is not OK.
Improving responsiveness in text inputs — Nolan Lawson covers how to prevent blocking the input event with “expensive” main thread work, using requestIdleCallback to batch UI updates.
Vector? Raster? Why Not Both! — Zach gets the best possible file size by splitting a graphic into two parts: An SVG (vector) for the things SVG does well, and a super-optimized raster graphic (ideally AVIF) for the things it does well, then plopping them on top of one another.