CSS Wizardry

https://csswizardry.com/

Web Performance Optimisation, Engineering, and Consultancy

フィード

記事のアイキャッチ画像
Correctly Configure (Pre) Connections
CSS Wizardry
A trivial performance optimisation to help speed up third-party or other-originrequests is to preconnect them: hint that the browser should preemptively opena full connection (DNS, TCP, TLS) to the origin in question,for example:<link rel=preconnect href=https://fonts.googleapis.com>In the right circumstances, this simple, single line of HTML can make pageshundreds of millisecondsfaster!But time and again, I see developers misconfiguring even this most basic offeatures. Because, as is often the case, there’s much more to this ‘basicfeature’ than meets the eye. Let’s dive in…Learn by ExampleAt the time of writing, the BBC News homepage (inthe UK, at least) has these four preconnects defined early in the <head>:<link rel=preconnect href=//static.bbc.co.uk crossorigin><link rel=preconnect href=//m.files.bbci.co.uk crossorigin><link rel=preconnect href=//nav.files.bbci.co.uk crossorigin><link rel=preconnect href=//ichef.bbci.co.uk crossorigin>Readers on narrow screens should know that each
5ヶ月前
記事のアイキャッチ画像
The Three Cs: 🤝 Concatenate, 🗜️ Compress, 🗳️ Cache
CSS Wizardry
I began writing this article in early July 2023 but began to feel a littleunderwhelmed by it and so left it unfinished. However, afterrecent and reneweddiscussions around therelevance and usefulness of build steps, I decided to dust it off and get itfinished.Let’s go!When serving and storing files on the web, there are a number of differentthings we need to take into consideration in order to balance ergonomics,performance, and effectiveness. In this post, I’m going to break these processesdown into each of:🤝 Concatenating our files on the server: Are we going to send manysmaller files, or are we going to send one monolithic file? The former makesfor a simpler build step, but is it faster?🗜️ Compressing them over the network: Which compression algorithm, ifany, will we use? What is the availability, configurability, and efficacy ofeach?🗳️ Caching them at the other end: How long should we cache files ona user’s device? And do any of our previous decisions dictate our options?🤝 Conca...
7ヶ月前
記事のアイキャッチ画像
What Is the Maximum max-age?
CSS Wizardry
If you wanted to cache a file ‘forever’, you’d probably use a Cache-Controlheader like this:Cache-Control: max-age=31536000This instructs any cache that it may store and reuse a response for one year (60seconds × 60 minutes × 24 hours × 365 days = 31,536,000 seconds). But whyone year? Why not 10 years? Why not max-age=forever? Why not max-age=∞?!I wondered the same. Let’s find out together.Like spoilers? See the answer. It’s 2147483648 seconds, or 68 years. To find out why, read on!max-agemax-age is a Cache-Control directive that instructs a cache that it maystore and reuse a response for n seconds from the point at which itentered the cache in question. Once that time has elapsed, the cache shouldeither revalidate the file with the origin server, or do whatever anyadditional directives may have instructed it todo. But why might we want to havea max-age that equates to forever?immutableIf we’re confident that we can cache a file for a year, we must be also quiteconfident that it never
7ヶ月前
記事のアイキャッチ画像
How to Clear Cache and Cookies on a Customer’s Device
CSS Wizardry
If you work in customer support for any kind of tech firm, you’re probably alltoo used to talking people through the intricate, tedious steps of clearingtheir cache and clearing their cookies. Well, there’s an easier way!Getting Someone to Clear Their Own CacheTrying to talk a non-technical customer through the steps of clearing their owncache is not an easy task—not at all! From identifying their operating system,platform, and browser, to trying to guide them—invisibly!—through differentscreens, menus, and dropdowns is a big ask.Thankfully, any company that has folk in customer support can make use of a newweb platform feature to make the entire process a breeze: Clear-Site-Data.Clear-Site-DataA relatively new HTTPheader,available in most modern browsers, allows developers to declaratively clear dataassociated with a given origin1 via one simple response header:Clear-Site-Data.Clear-Site-Data: "cache", "cookies"Any response carrying this header will clear the caches2 associated with t
8ヶ月前
記事のアイキャッチ画像
The Ultimate Low-Quality Image Placeholder Technique
CSS Wizardry
At the time of writing,99.9% of pages on theweb include at least one image. The median image-weight per page landed at881KB in 2022,which is more than HTML, CSS, JS, and fonts combined! And while images do notblock rendering (unless you do somethingsilly), it’simportant to consider how we offer a reasonably pleasant experience while usersare waiting for images to load. One solution to that problem is Low-QualityImage Placeholders.Low-Quality Image PlaceholdersLow-Quality Image Placeholders are nothing new. GuyPodjarny is responsible, I think, for coiningthe term over a decadeago! Andbefore that, we even had the lowsrc attribute for <img> elements:<img lowsrc=lo-res.jpg src=hi-res.jpg alt>I wish we’d never deprecatedlowsrc—itwould have saved us so much hassle in the long run.The technique is simple: as images are typically heavier and slower resources,and they don’t block rendering, we should attempt to give users something tolook at while they wait for the image to arrive. The solution
8ヶ月前
記事のアイキャッチ画像
Core Web Vitals for Search Engine Optimisation: What Do We Need to Know?
CSS Wizardry
UpdatesStay updated by following this article’s Twitterthread. I will postamendments and updates there.26 July, 2023: iOS (and Other) Traffic Doesn’t CountCore Web VitalsGoogle’s Core Web Vitals initiative was launched in May of2020and, since then, its role in Search has morphed and evolved as roll-outs havebeen made and feedback has been received.However, to this day, messaging from Google can seem somewhat unclear and, inplaces, even contradictory. In this post, I am going to distil everything thatyou actually need to know using fully referenced and cited Google sources.Don’t have time to read 5,500+ words? Need to get this message across toyour entire company? Hire me to deliver thistalk internally.If you’re happy just to trust me, then this is all you need to know right now:Google takes URL-level Core Web Vitals data from CrUX intoaccount when deciding where to rank you in a search results page. They do notuse Lighthouse or PageSpeed Insights scores. That said, it is just one of ma
10ヶ月前
記事のアイキャッチ画像
The HTTP/1-liness of HTTP/2
CSS Wizardry
This article started life as a Twitterthread, but I felt it needed a more permanent spot. You should follow me on Twitter if you don’talready.I’ve been asked a few times—mostly in workshops—why HTTP/2 (H/2)waterfalls often still look like HTTP/1.x (H/1). Why are things are done insequence rather than in parallel?Let’s unpack it!Fair warning, I am going to oversimplify some terms and concepts. My goalis to illustrate a point rather than explain the protocol in detail.One of the promises of H/2 was infinite parallel requests (up from thehistorical six concurrent connections in H/1). So why does this H/2-enabled sitehave such a staggered waterfall? This doesn’t look like H/2 at all!This doesn’t look very parallelised!Things get a little clearer if we add Chrome’s queueing time to the graph. Allof these files were discovered at the same time, but their requests weredispatched in sequence.The white bars show how long the browser queued the request for. Allfiles were discovered around 3.25s,
10ヶ月前
記事のアイキャッチ画像
In Defence of DOM­Content­Loaded
CSS Wizardry
Honestly, I started writing this article for no real reason, and somewhatwithout context, in December 2022—over half a year ago! But, I left it in_drafts/ until today, when a genuinely compelling scenario came up that givesreal opportunity for explanation. It no longer feels liketrivia-for-the-sake-of-it thanks to a recent client project.I never thought I’d write an article in defence of DOMContentLoaded, but hereit is…For many, many years now, performance engineers have been making a concertedeffort to move away from technical metrics such as Load, and toward moreuser-facing, UX metrics such as SpeedIndexor Largest ContentfulPaint.However, as an internal benchmark, there are compelling reasons why some of youmay actually want to keep tracking these ‘outdated’ metrics…Measure the User ExperienceThe problem with using diagnostic metrics like Load or DOMContentLoaded tomeasure site-speed is that it has no bearing on how a user might actuallyexperience your site. Sure, if you have Load ti
1年前
記事のアイキャッチ画像
Site-Speed Topography Remapped
CSS Wizardry
N.B. This is an update to my 2020article Site-SpeedTopography. You will need to catch up with that piece before this onemakes sense.Around two and a half years ago, I debuted my Site-SpeedTopographytechnique for getting broad view of an entire site’s performance from justa handful of key URLs and some readily available metrics.In that time, I have continued to make extensive use of the methodology(alongside additional processes and workflows), and even other performancemonitoring tools have incorporated it into their own products. Also in thattime, I have adapted and updated the tools and technique itself…Get the new spreadsheet!What Is Site-Speed Topography?Firstly, let’s recap the methodology itself.The idea is that by taking a handful of representative page- or template-typesfrom an entire website, we can quickly build the overall landscape—ortopography—of the site by comparing and contrasting numerical andmilestone timings.Realistically, you need to read the originalpost before thi
1年前
記事のアイキャッチ画像
Why Not document.write()?
CSS Wizardry
If you’ve ever run a Lighthouse test before, there’s a high chance you’ve seenthe audit Avoiddocument.write():For users on slow connections, external scripts dynamicallyinjected via document.write() can delay page load by tens ofseconds.You may have also seen that there’s very little explanation as to whydocument.write() is so harmful. Well, the short answer is:From a purely performance-facing point of view, document.write() itselfisn’t that special or unique. In fact, all it does is surfaces potentialbehaviours already present in any synchronous script—the only main difference isthat document.write() guarantees that these negative behaviours will manifestthemselves, whereas other synchronous scripts can make use of alternateoptimisations to sidestep them.N.B. This audit and, accordingly, this article, only deals withscript injection using document.write()—not its usage in general. The MDNentry fordocument.write()does a good job of discouraging its use.What Makes Scripts Slow?There are
1年前