Zach Leatherman

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 clensing 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?

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.

An Official* Logo for HTML

2026-02-19T06:00:00Z

*Not official.

I was working on my slide deck for the upcoming State of the Browser conference and ran into what I would classify as a recurring issue: HTML needs a logo. There isn’t a broadly accepted official logo for (version-independent) HTML. There is a logo for HTML 5, but that versioned marketing term has long fallen out of regular use (and was introduced 18 years ago).

This is a community solved problem in both the CSS and JavaScript spaces!

CSS: , relevant discussion on CSS-Next.
JS: , relevant discussion on voodootikigod/logo.js.
HTML 5: , more info on w3.org.

I wish the classic orange badge hadn’t included a version number, but alas.

Anyway, I very quickly threw my hat into the ring and immediately recognized a much better option from Sam Stephenson sls.name that I’ll be considering canon moving forward (and hopefully this blog post puts some weight behind it for others too).

Here’s what it looks like rendered in your web browser:

HTML

I love the nod to the classic unvisited link color and the heavy outset border that doubles as angle brackets with the right head tilt.

If you’re interested in the source code, the HTML-only (copy-paste friendly) source code is included below (and also on Codepen):

<a href="https://indieweb.social/@sstephenson/116098428280403793" style="all:initial;cursor:pointer;font-size:2rem;width:4em;height:4em;color:blue;text-decoration:underline;display:flex;align-items:center;justify-content:center;background:#ccc;border:.5em outset #aaa;font-weight:900;">HTML</a>

How Eleventy Survived: Funding, Growth, and Open Source Reality

2026-02-03T06:00:00Z

Eleventy started as a side project. Now it’s a critical infrastructure for thousands of websites.

TL;DR: Open source isn’t broken. But the way we fund it often is. Let’s talk about what actually works.

In this episode, we sit down with Zach Leatherman, creator of Eleventy (11ty), to talk honestly about what happens after open source succeeds. From nap-time coding and nights-and-weekends maintenance to venture capital pressure, burnout risk, and the reality of funding long-lived developer tools, this conversation digs into the cultural and financial tradeoffs behind modern open source.

We cover sustainability, community expectations, funding models that don’t rely on hockey-stick growth, and why “free forever” only works if the people behind the project can stay whole humans.

Listen in: How Eleventy Survived: Funding, Growth, and Open Source Reality

Also on: