Zach Leatherman

Trying out a Two-state Dark Mode Toggle

2026-09-11T05:00:00Z

Lea Verou sparked some lovely discussions about dark/light mode toggles by asking a simple question: do these form controls need three options for two user-facing states?

You have Dark mode (1). You have Light mode (2). You have System mode (inheriting your operating system preference) which is ultimately Dark (1) or Light mode (2). Typically the form controls have three options:

System (auto)
Light (saved on device as an override)
Dark (saved on device as an override)

In Lea’s proposal, you’d have:

System (auto)
Opposite of System (saved on device as an override)

Toggling back to system/auto should always clear any saved override preference.

I’ve added a little toggle to the footer of my own site (noting when the system preference matches the current selection with (auto)) and it looks like:

Dark (auto) [Toggle] Light for users with a Dark system preference.
Dark [Toggle] Light (auto) for users with a Light system preference.

I’m enjoying it so far!

I should also note that Bramus did write a criticism of the approach, noting a special case for users that have their system preference switch automatically (which I do personally use). I do think the simpler control and the simpler interaction (every toggle has a noticeable visual effect on the page) is worth the tradeoff there (personally). The strongest counterargument is that one of the three options on the tri-state toggle has no visual effect at all.

Related: Lea’s reactions follow-up post: The best dark mode toggle is probably none.

I was tired of building 474 separate pages for Open Graph Images

2026-09-09T05:00:00Z

Prior blog post (if you want the full context): If I work really hard on my Open Graph Images, People will share my Blog Posts (2021 Aug)

Here’s the gist:

Open Graph images are those little pictures that show up when your site is shared on social media. […] Each individual blog post (on my website) has a dedicated Open Graph image page.

These Open Graph pages had the URL shape /web/:title/opengraph/ and there were 474 of them.

This was great from a purist’s perspective (in that the Open Graph pages were built similarly to how I build other websites) but my perspective has changed a bit. I don’t think that server rendering a static page for each of the 474 blog posts is necessary! 🫣

Now I use one /opengraph/ page that client renders (the horror!) the appropriate metadata for the Open Graph image. Client rendering here is an appropriate tradeoff for build time because this page is still going through a Chromium-based screenshot service and the ultimate deliverable is a static image. This page isn’t intended to be consumed by human beings (unless they really want to, I dunno, I’m not your dad).

Note that the caching mechanism hasn’t changed: it still lives in the screenshot service and the image content isn’t being regenerated from scratch (with my old static pages method or this new client rendered method).

I now use this approach on a few places and it’s made implementing Open Graph support on websites much easier to build and manage:

zachleat.com (this is the web site you’re on now)
build.awesome.me
speedlify.dev

Importantly, there is no freeform mechanism on these pages to modify the content of the images via URL parameter. There is no ?text=… to control the title text, it’s keyed off of the local page URL and that alone. I don’t want y’all to put whatever text you want next to my picture on my website (you have to do that on your website 😘).

Use Speedlify2 to Continuously Measure Website Performance

2026-08-26T05:00:00Z

speedlify.dev, now running Speedlify2.

The year is 2020. Inspired by a lack of budget for a web performance monitoring tool, the original Speedlify project (Speedlify Classic) was shipped to continuously measure site performance. It ran Lighthouse against a predetermined list of sites and ranked their performance against each other. Over time, I started to add a few more things to Speedlify.

A <speedlify-score> Web Component was added to show scores on your web site.
The Eleventy Leaderboards were migrated to use Speedlify, running 31 unique contests and testing 1208 unique websites.

As the Leaderboards grew, the work involved in maintaining them scaled similarly. Due to infrastructure build time constraints (a 15 minute build limit) and limitations in how Speedlify executed its measurement step (all sites would run serially and a compare step ran when all measurements had been taken), the Leaderboards needed to run on my own hardware.

Over six years, it’s pretty natural that some folks would let their websites and domains lapse. A few sites moved away to use other tools. All of which culminated in manual work to publish Leaderboard scores. You could probably see this reflected in how often the Leaderboards were published 🫣 — though in retrospect 31 runs in six years (~2 month cadence on adverage) isn’t bad!

Better and more Automated

Regardless, I’m delighted to show off some huge updates and improvements have been made to the brand new Speedlify2. Changes which will ultimately save me a bunch of time and effort!

Speedlify2 is now measuring 1565 sites continuously without requiring any manual work.
Each category has its own cadence configuration, and the Built Awesome category is currently configured to visit sites once per week to measure and test.
Everything is static and self contained, deployable via GitHub Actions to GitHub Pages. You can easily deploy your own Speedlify2. (Run the reset script to start from scratch)
Measurements happen in small chunks in parallel on GitHub Actions. The measurement step is now decoupled from ranking. When the site builds, it pulls from the newest measurements for all steps and ranks them. This is far more robust!
Sites that move away from Build Awesome (11ty) are now automatically put into an unranked Emeritus category. I went ahead and backfilled the 92 websites that have moved away since we started the showcase in 2018. Emeritus sites can show up on the Perfect Scores ranking on the home page (though at time of writing only 3 of the 92 of them do).
Instead of the classic 4-circle Lighthouse design, this adds additional circles for Core Web Vitals (field data alongside lab data) and now explicitly shows the output of a more detailed and rigorous Axe CLI run. Lighthouse does use Axe internally but doesn’t report everything (Speedlify2 does).
Adds a new <speedlify2-score> component.
The production service has backwards API compatibility with any legacy <speedlify-score> components using the old speedlify.dev instance as their data source (and all sites measured there are measured on the new speedlify.dev).
Categories are no longer mutually exclusive. URLs can exist in multiple categories and the home page shows all of the perfect scoring sites across all categories. To avoid extra testing traffic, single measurements are re-used across categories.
Adds a new randomly selected Perfect Site of the Day.

It might be interesting to look at the report of Speedlify measuring Speedlify, which includes measurements before the production domain was moved from Speedlify (classic) to Speedlify2. We can see how the migration went!

No-JavaScript Comparisons

Speedlify2 also shows screenshots for No-JavaScript and JavaScript-enabled, reporting the visual percentage difference between the two. This does not feeding into rankings (as it isn’t a foolproof measure) but it does have utility!

Specifically, it can reveal sites that exclusively use client side rendering (solidjs.com at ∆ 77.4%):

It can reveal sites that may have bugs in their dark/light mode switcher (nuxt.com at ∆ 99.8%):

It can reveal sites that use an announcement bar that causes the entire page to layout shift (svelte.dev at ∆ 36.2%):

Highlighting Good Sites

The Built Awesome Leaderboards are intended to be a very rigorous and competitive leaderboard. The sites that score well here are very fast.

But (similarly to the Eleventy Leaderboards before them) we don’t highlight bad scores. The (exhaustively long) list is exclusive to sites with all green circles. With an exception for unknown Core Web Vitals, which requires a level of minimum production traffic in Chrome browsers to show data.

Sites with yellow or red circles are shown in an overflow list (randomly ordered) with no scores visible. You can navigate through to check your site’s page individually and review the report to learn how you can improve for the next run.

The other top level categories (Web Hosts, Site Generators, Website Builders, Package Managers et al) are for corporate accountability and do show poorly scoring sites. This is a separate tact we want to avoid for personal or individual websites. We can and should hold professional and paid websites to a higher standard!

Am I neglecting my open source projects?

2026-08-10T05:00:00Z

I have a lot of open source projects (of varying sizes and shapes).

At time of writing, I’m currently maintaining ×78 npm packages. Of those, 22 are super lightweight zero-dependency custom elements a.k.a. 🚾 Web Components (love the future compatibility I get with very little maintenance required). In addition, I also have a few active websites and starter/template projects that are open source too.

I usually rotate maintenance on these and needed a way to quickly scan my little ecosystem of packages to know which ones needed love. Thus, a new little dashboard has appeared on my web site that I’m calling:

Is this still being maintained??

The name pays homage to those ~~helpful~~ passive aggressive comments folks sometimes leave on issue trackers (mirroring a fair question that perhaps I should be asking myself).

Each project is given a Neglect score that represents how much love it needs. It factors popularity (via npm downloads and GitHub stars) and need (GitHub issues and pull requests, npm audits), and recency (npm publish and GitHub commit dates). It shows how many production dependencies (including transitive ones) that a project uses. It even has a little sparkline to give a little data visualization to how frequently packages are published.

A broader look

The aggregate statistics there were genuinely surprising to me. 67 million downloads in the last year (though this is heavily influenced by dependencies I maintain in Build Awesome/11ty, which are counted separately).

Over 1.1k published versions, 4.7k closed issues, and 2.2k pull requests merged! (not all by me, of course)

Currently my most neglected package is the Eleventy Vue plugin (which owns 31 of my 42 total npm audits) and I’m actively deciding whether to revive it or retire it 🫣.

All of my 77 other packages only have 11 total npm audit reports! I’m feeling extremely proud of that, which feels related to the work I’ve been doing to lock down publishing workflows and reduce dependencies. Though that number may change over time, I now have an easy centralized place to check it. This report also makes it very obvious the relationship between dependency count and audit reports. Keep reducing those dependencies, y’all!

The other result of monitoring this report is that I have archived a bunch of old projects that I don’t want to track, which has a nice cleansing feeling to it.

Back Build Awesome Pro and make it easier to build for the web!

2026-04-29T05:00:00Z

The Build Awesome (11ty) Kickstarter (Final_FINAL_v2) is live! We’re trying to make it easier for anyone to build, publish, and maintain web sites!

Update: the Kickstarter campaign has concluded but late pledging (and late pricing) is still available.

Go directly to the Kickstarter.
Read more on the Blog.

Collaborative Editing as Progressive Enhancement

2026-04-22T05:00:00Z

We’re ramping up again to launch the Build Awesome (11ty) Kickstarter Final_FINAL_v2 on April 28, 2026 and in this post I make the case for a new web site builder can layer itself on top of your existing projects as a progressive enhancement. Infrastructure as progressive enhancement!

Launching April 28.

State of the Browser (2026) It’s 10PM: Do You Know Where Your JavaScript Is?

2026-04-16T05:00:00Z

This talk was given at State of the Browser (2026). Check out the event talk page (which includes a talk transcript, too).

We’ll talk about best practices to either reduce (or increase!) the JavaScript footprint on your web site to a sweet and very practical spot for best results. It’s far more common to have too much JavaScript on your web site, but can you go too far? Is zero JavaScript a worthwhile goal? Let’s talk about it!

Video

Watch on YouTube: State of the Browser (2026) It’s 10PM: Do You Know Where Your JavaScript Is?

Slides

The year is 1964. Only 5 years before the Apollo 11 moon landing and the midpoint between the very first release of Internet Explorer (1995) and the current year 2026. https://unsplash.com/photos/a-tv-sitting-on-the-ground-in-front-of-a-brick-building-SnewvLPyeAQ

The location? Los Angeles, CA (USA).

Local nightly news anchors for KHJ channel 9 decided to broadcast a PSA or Public Service Announcement (also known as a Public Information Film or PIF) warning to all parents in the area: It’s 10PM. Do you know where your children are?

What kind of parents existed in 1964? What kind of kids? Why did they need this reminder? And today, I bring the developers creating the next generation of JavaScript heavy applications the same call to action: it’s 10PM — do you know where your JavaScript are?

Today we’re starting a rumor that Americans say that “JavaScript” is plural, just like we do with Math, which JavaScript is also coincidentally kinda bad at.

And to do that, we’ll take a trip to the local optometrist and create a little component that lets us compare two separate images, a before and an after image. https://optician-sans.com/

Here’s what a component like this might look like. This one is a <wa-comparison> custom element from the Web Awesome component library. Today we’re going to walk through 14 different eras of web development as though they were DEFCON levels on a Cold War threat readiness system, and we’ll create 14 different image comparison components to show how far we’ve come and what might come next.

Let’s hop into our mandalorian time machine and travel back to the year 1991.

The year is 1991, a short 35 years backwards in time, but only 22 years after humanity bravely landed on the moon. One can only assume that dinosaurs had very recently gone extinct. We find a young, spry London-born 36 year old Tim Berners-Lee publishing the very first draft of…

HTML. How might one create an image comparison component in HTML? Call it out if you know it:

That’s right, ASCII art. Unfortunately <pre> was not available to preserve whitespace.

Here are the originals. Which one could we use? Call it out if you know it https://www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/Tags.html

If you said plaintext, sure!

but <plaintext> vacuums up the rest of the document (and doesn’t expect a closing tag), as stated to improve parsing performance. A thousand HTML sanitizer scripts just held this breath, because just like an unclosed <style> element, this behavior will still vacuum everything

Let’s swap to <listing>, which is a better fit. I think we’ve exhausted this one. Let’s move on.

The year is 1992. Some dude (we needn’t immortalize who) introduced the

`<img>` element, the very first mechanism for displaying images inline in HTML. First available in the Mosaic browser, this first offers us the barest bones featureless image comparison component was first possible. Leaving the viewer to crane their neck left and right to compare images, disgustingly manually.

Trojan Room Coffee pot at the University of Cambridge by Quentin Stafford-Fraser and Paul Jardetzky Originally created in 1991, put on the web after <img> was introduced; XBM format https://en.wikipedia.org/wiki/X_BitMap though GIF was available at the time (maybe JPEG, though that timeline is much closer) This may not be the first image, a title likely given to a July 1992 image of a Cern-based musical group. https://www.cl.cam.ac.uk/coffee/coffee.html https://www.webdesignmuseum.org/web-design-history

Can anyone guess what happened in 1995?

https://www.youtube.com/watch?v=5NShEY1ScSY

For this one, I think it’s prudent that we pay homage to the MM_swapImage script. If you aren’t familiar with this one, it was introduced in Macromedia Dreamweaver to swap image sources when a user interacts with them.

Let’s start to document our dependencies.

Cons: not seen by the HTML preload scanner but guess what: we didn’t have a preload scanner then The mm_ scripts did include JavaScript preloading. I know this is a trivial example but it’s important to internalize this concept and how it can represents layout shift.

Anyway, let’s not spend too much time on this one it’s very outdated and not used any more.

https://www.w3.org/TR/CSS1/ Håkon Wium Lie and Bert Bos who as far as I can tell is unrelated to Wes Bos CSS1 was in 96 but we’re going CSS2 in 98 so that we can use position and overflow

Introduced in a SXSW talk in 2003. Photo via https://www.linkedin.com/in/schampeo/ Slides: https://web.archive.org/web/20141108064903/http://hesketh.com/publications/inclusive_web_design_for_the_future/ Webmonkey article https://hesketh.com/publications/progressive_enhancement_and_the_future_of_web_design.html

How it loads is just as important as what is loading. This ties into (not just) Progressive Enhancement, but Browser Support, Performance, FOUC, Layout Shift, et al

The link element blocks rendering, waiting for the stylesheet. A script like this in 2003 was blocking, though now we can use modules or asynchronous/defer to better control that behavior. External requests creates a network dependency! In the wild wild west of the world wild web, no network request can be guaranteed to complete so we must think about what happens when resources don’t load or aren‘t supported by the viewer’s browser

And even though progressive jpeg was available, I didn’t use it here for dramatic effect and the image content chunks in, line by line, reminiscent of my childhood.

We should also think about what happens if the network requests complete but are delayed! Just off the cuff and absolutely in no way pun intended, maybe we could call it the extermporal dead zone

SUSPEND REALITY and time warp in a service worker

Have you heard of 56k Fridays? I’m not saying you use this to add a simulated network delay to folks with more CPU cores, but here is a script to do that

May 2008 https://web.archive.org/web/20081216035512/http://googleajaxsearchapi.blogspot.com/2008/05/speed-up-access-to-your-favorite.html

Google Hosted Libraries popularized this in the jQuery community https://developers.google.com/speed/libraries

Though instead of performance savings, there are now performance costs with this approach — though the biggest cost for me is relying on an external third party for your site’s runtime

PRIVACY Separate cache for each origin https://andydavies.me/blog/2018/09/06/safari-caching-and-3rd-party-resources/ https://addyosmani.com/blog/double-keyed-caching/ https://developer.chrome.com/blog/http-cache-partitioning

https://fossa.com/blog/polyfill-supply-chain-attack-details-fixes/

https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Subresource_Integrity the failure mode here is pretty unfriendly.

November 2008

Cheap server rendering without an application server, popularized via the default option for GitHub Pages

Real OG’s might recognize

lol image map

The PE profile here seems better but the user experience is definitely worse!

though IE9 was first in 2011

https://www.w3.org/TR/2001/WD-css3-mediaqueries-20010404/Overview.html

implemented using @media and css background-image https://alistapart.com/article/responsive-web-design/

Islands architecture popularized by the Astro about ten years after RWD is also in this same league https://scottjehl.com/posts/responsive-video/ 2023!

Were CRT televisions 16:9? I don’t remember.

You might imagine doing the same with a navigation menu viewable at large viewport sizes but not at small ones.

Not just on the client! Servers can make choices like this too: to conserve resources using static assets instead of dynamic pages, to use low-tech features like image dithering to reduce serving costs. https://solar.lowtechmagazine.com/

This wasn’t a particularly good time for folks that cared how the web was delivered or rendered. But it was a very popular time for web development!

Import your styles, and they get bundled up globally

2 network resources on the critical rendering path, including a hefty library This is like strapping your baby into the

https://www.reddit.com/r/mildlyinteresting/comments/133ze96/today_in_minnesota_an_empty_flatbed_with_a_single/

Styled Components 2016–2026 Emotion 2017

I get it—why not? the JS dependency is already there! It makes sense if you’re already bought in to CSR. 51kb to 61 kb

Turns out JavaScript isn’t good at this, especially against CSS and especially when dealing with frequent rerenders.

https://styled-components.com/

https://speakerdeck.com/vjeux/react-css-in-js?slide=28

https://unsplash.com/photos/brown-and-black-brick-wall-KREQ7J7nsNw A mea culpa moment for CSR

Notably here when I’m talking about SSR, I’m using the component definition of SSR, not the application version (which means rendering dynamic HTML on-request). The reason it’s murky is because people are making money from the confusion 😘 https://www.zachleat.com/web/ssr-overloaded/

https://github.com/vercel/next.js/tree/1.0.1 used Glamor for first-party CSS

next@1 (2016) 328 KB react@19 (2026) 191 KB next@16 (2026) hello world grown by 30% to 455.3 KB

as we all know, systems typically get less complex over time so this is fine.

almost 400 KB of JavaScript between your finger and your eye split across 6 external requests (EACH is required for interactivity), remember the goal is to poke the eye as fast as you can

Tailwind 1.0 was released in 2019

I could probably write a whole talk about the introduction of this compared with zero runtime CSS in JS tools. Linaria 1.0 was available in 2019 too. I do have opinions, primarily that CSS seems to be shipping wildly fast in a way that abstractions are having trouble keeping up. But the biggest takeaway here is that all of these tools helped move CSS out of the client JS bundle.

Even React pivoted away from this in 2021. https://github.com/reactwg/react-18/discussions/110

January 2020, Custom Elements v1 cross-browser available when Edge swapped to Chromium

https://webawesome.com/docs/components/comparison/

Smaller JavaScript cost than a jQuery (87 KB)

Flash of Unstyled Content

Vite released April 2020

You don’t have to gamble with these slots

The first party, accessible JavaScript-enhanced experience is the ideal case. But here we provide an interactive middle ground when something in your environment has gone wrong.

This one is using a range input. You could use the :target pseudo selector here as well to make the dead zone interactive again. You could also imagine how this same logic could be applied to a tabs component, notable for making sacrifices in unstyled render or missing interactivity. Web components offer this unique styling and markup enhancement out of the box, and I think that’s great.

AMA about Build Awesome, an Open Town Hall at the 11ty Meetup

2026-03-12T05:00:00Z

Here I field any and all community questions about the Eleventy rebrand to Build Awesome.

Watch on YouTube or below:

Watch on YouTube: AMA about Build Awesome, an Open Town Hall at the 11ty Meetup

Eleventy is now Build Awesome

2026-03-06T06:00:00Z

The Eleventy project is taking up the Awesome banner. To support the project, please sign up to get notified when our Kickstarter campaign launches!

Speaking at: State of the Browser (2026)

2026-02-28T06:00:00Z

This is an event post. Also check out my individual talk page.

Update: As the talk has already been given, you can find the talk content published on my web site.