Zach Leatherman

“AI, make the website good”

2026-09-21T05:00:00Z

Millions of Large-Language-Model-generated words have been spilled on craftsmanship in this gilded-age of software development. We now have agents to plan how code will be written, agents to write code, agents to review code, agents to orchestrate and dispatch tasks to other more (or less) capable subagents (these heavily subsidized tokens aren’t going to pay for themselves).

I’ve been in this game long enough to recognize self-congratulatory tooling improvements for what they are: automated simplicity (aka can-kicking complexity) from software companies claiming to be at the bleeding edge of technique and application.

I’m always left wondering (suspecting the answer with hopeful optimism that my hunch is wrong this time): do these workflow improvements actually improve how people (technical or otherwise) experience software? Certainly we have more software. But is it better?

Front-end web developers have lived through about fifteen years of the single-page-application-era smokescreen, sold as though improvements to developer experience would cause the reanimated corpse of Ronald Reagan himself to ask you for commit access to ship trickle-down improvements to user experience.

Are we repeating the same playbook (on a more accelerated pace)? Certainly we’ve seen numerous recent anecdotal examples of software becoming less reliable over time (GitHub is the most recent scapegoat I’ve seen, but on my read they seem to be a second-order victim more than anything) (seems like a great time to be in the Monitoring/Status Page business).

With these seismic changes, I will continue to make the argument that craft defined as caring about the quality of output (independent of the tools used to generate the output) is more important than ever. Caring about what you ship will always have real-world value to ~~visitors/consumers/users~~ real people.

Prefers-reduced-motion respecting web performance filmstrips from the AI category on Speedlify, a category boasting a failing median Core Web Vitals score with 12 out of 13 sites failing Lighthouse performance and Axe accessibility checks.

Icon Fall Web Component

2026-09-16T05:00:00Z

I’ve been doing some spring/fall cleaning and found an unpublished follow-up component to <snow-fall> (a web component to “snow” on your website — which also happens to work with emoji too). Originally it was created as an easter egg for Blog Awesome (click on the Font Awesome flag in the very bottom of the footer) but others have wanted to use it for more things!

Presenting: <icon-fall>:

It’s in use on this page (if you are on my web site and not in a feed reader). You can also install it with npm install @zachleat/icon-fall.

It has options for count (attribute, number of icons) and a comma separated list of colors (via --icon-fall-colors custom property).

Table of Contents Web Component

2026-09-15T05:00:00Z

…and another one.

This little (zero CSS) web component has two modes: progressively enhance a hierarchy of server rendered <ol> or <ul> elements (or conveniently client render them for you if they don’t exist) to highlight which are currently visible in the viewport.

I pulled this code out of the table-of-contents.webc component from the WebC Tugboat starter project for standalone use.

Demo
- And a demo in the sidebar of this blog post on my website.
- And a server rendered demo on Blog Awesome, e.g. Font Awesome 7.3 Is Here!
Source code
@zachleat/table-of-contents on npm

You can configure a selector attribute to control the scope of the headings search. My site uses main :is(h2, h3) but the default is main :is(h2, h3, h4, h5, h6).

Again, all styles for this component are application styles. There is no component CSS on this one.

Installation

npm install @zachleat/table-of-contents

Some sample headings

Heading 3a

Heading 4 (via 3a)

Heading 3b

Heading 4 (via 3b)

Heading 3c

Solar Eclipse Toggle Web Component (two state dark/light mode toggle)

2026-09-14T05:00:00Z

In Trying out a Two-state Dark Mode Toggle I summarized the Two-state Dark and Light mode Toggle discussion as I experimented with a toggle in my personal website footer.

After launch, Curtis Wilcox left some good feedback to improve the accessibility of the component.

I decided to fold this into a reusable component so that I can benefit from this work on future websites (and you can use it too, I guess!). It’s called @zachleat/solar-eclipse-toggle and you can find it on GitHub or on npm now.

Demo
…or in the footer of this website.
…also in the footer on Speedlify.

My favorite parts about the component are that it shows an inert button pre-JS, incurs no CLS, is still functional when the (separate) CSS doesn’t load successfully ([hidden] for the win), and all strings are inserted from light DOM for good internationalization.

Hope it’s useful to others!

Installation

npm install @zachleat/solar-eclipse-toggle

Trying out a Two-state Dark Mode Toggle

2026-09-11T05:00:00Z

Update

I made some updates and released it as a web component: details in Solar Eclipse Toggle, a Dark/Light mode Toggle Web Component.

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~~
~~Dark [Toggle] Light (auto)~~
Use light theme (shown) and Use dark theme (auto) for users with a Dark system preference.
Use dark theme (shown) and Use light theme (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.