Published

Inexactly benchmarking Eleventy vs Astro build times

The Eames Institute team is checking out some frameworks and static site generators for a project, and I wanted to see how Eleventy and Astro compare in terms of build time.

Zach Leatherman’s 2022 article “Which generator builds Markdown the fastest?” is probably the most thorough resource I’ve come across along these lines, and I’d recommend checking that out if you want to do some serious comparisons.

But I was curious about a “real world” test in 2024, so I decided to do some inexact benchmarking using a Markdown export of this blog. A caveat up front: I’m much more familiar with Eleventy than I am with Astro, which will likely be apparent when I get to the incremental build tests later in this post.

For Eleventy I used eleventy-netlify-boilerplate with zero modifications, and for Astro I used the blog template as described in their docs with some small modifications along the lines of this wordpress-to-astro repo to get categories and tags working. I didn’t want to use wordpress-to-astro directly since it was last updated two years ago, but it is a good reference point.

My blog has 770 posts which were exported to 770 Markdown files. With a paginated feed, categories, and tags, the total number of built pages is around 2550.*

Based on an average taken from 10 builds, Astro took 10.07 seconds and Eleventy took 4.29 seconds to build.

Incremental builds can speed things up significantly since the only built content is that which is relevant to the modified files.

Eleventy has supported incremental builds since December 2022 (I believe!), but it doesn’t yet support it on a CI server. There is an open issue for it which looks like it has traction.

To test incremental builds, I added and removed the same single tag on the same post 10 times.** Based on an average taken from 10 incremental builds, Eleventy took 2.17 seconds skipping 777 files. I would have expected it to skip more, but this might have to do with not being able to incrementally build paginated data.

I wanted to test the same content change in Astro… but it isn’t clear to me that there is an apples-to-apples comparison. Astro introduced an experimental Incremental Content Caching feature in v4.0 (not sure if this is supported on CI servers). When I added experimental.contentCollectionCache to the config, there was no difference between basic build times when I made a content change. I’m not sure if this is because having all of my content in Markdown makes the caching a mute point, or if it’s something else. If anyone has further context on how best to test Incremental Content Caching in Astro, would love to know.

For what it’s worth, running astro dev is extremely quick, just 125ms before it’s ready.

I’d be curious to do a similar benchmark using WordPress’s REST API but am not sure I’ll have the time… Will update here if I do.


* I give a rough number because the Eleventy boilerplate and Astro template generate a few additional pages, but the page total difference is in the single digits so I didn’t waste time evening them up perfectly.

** For my own future reference in case I do further tests: Add and remove the tag hello from this post.

Published

Gemma’s site in AIGA Eye On Design

Read “There’s More Than One Way to Share Your Design Work: Four fresh takes on the portfolio” on AIGA Eye On Design.

They spoke to Carly Ayres, Prem Krishnamurthy, David Reinfurt, and Gemma Copeland about their approaches to an online portfolio / website. Gemma spoke a bit about how we designed and built her site together, it was a lot of fun. See her site gemmacope.land, or take a look at the GitHub repo. BIG thanks to Howard Melnyczuk for fixing a bug I totally missed. 🤦🏻‍♀️ 🙏

Published

Sass + Eleventy, remember to opt out of using .gitignore

I’m working on an Eleventy site at the moment, the first Eleventy site I’ve done that’s been complex enough CSS-wise to warrant using Sass. I’ve turned to Phil Hawksworth’s Sass + Eleventy technique for the job. It’s a great, simple way of using Sass with Eleventy with a little bit of preprocessing courtesy of Gulp.

Hit a wall at one point though, it was smooth sailing and then my CSS updates just stopped working.

Turns out I had added /_includes/main.css (the compiled styles) to my .gitignore file since I prefer not to commit compiled files, but I forgot that Eleventy uses the .gitignore file + the .eleventyignore file to decide what not to compile. So Eleventy was just ignoring it. 🤦🏻‍♀️

I did this .gitignore change as an end-of-day commit, tidying things up before closing my laptop. When I picked the project back up days later, it took me longer than I’d like to admit to figure out what was going on!

To sort it, I just had to opt out of using .gitignore by adding eleventyConfig.setUseGitIgnore(false); to the .eleventy.js config file, and then adding the necessary files listed in .gitignore to .eleventyignore. Then I re-ran gulp watch & npx eleventy --serve, and all was well.

Separate but related to static site generators: Check out Astro. Would be curious to see a detailed comparison of Eleventy vs Astro since Eleventy is currently top-of-the-list for me in terms of static site generators.

Published

Thoughts on LAMP vs JAMstack content management systems

Chris Coyier recently published a CSS-Tricks post titled “WordPress and Jamstack”. It’s a great rundown of the pros and cons, and I’m in agreement on the whole.

The most important point for my own use cases is from the section titled “CMS and End User UX”.

Sometimes, we developers are building sites just for us (I do more than my fair share of that), but I’d say developers are mostly building sites for other people. So the most important question is: am I building something that is empowering for the people I’m building it for?

I really enjoy working on JAMstack (JavaScript, APIs, Markup) sites, the dev environment can be spectacular. It’s wonderful to not worry about deployment, HTTPS, caching. BUT. I haven’t yet found a JAMstack content management system (CMS) that I love, so it’s not something I feel super comfortable reaching for in the majority of my client work.

Read more

Published

Tom Hackshaw’s site

I had a lovely convo with NZ-based web worker Tom Hackshaw during a digital coffee a little while back, ended up sending him a link to Portfolio Starter once Sam and I finally wrapped it up. I had the good fortune of coming back across him recently when I accidentally sent an email to him instead of another Tom (oops! shows how mistakes can be good tho). Saw that he’s using Portfolio Starter, which is sweet! Better yet, he’s got an excellent blog going and a very commendable accessibility policy (I still need to get round to that…). Check his site out at the link below, or follow him on RSS.

tom.so

Published

Use Portfolio Starter to create a personal site with projects, pages, and posts

Screenshot of Portfolio Starter

This tutorial will teach you how to set up a personal website using Portfolio Starter, a starter kit for portfolio-driven websites made by Sam Baldwin and me. Check out the demo site to get a feel for how it looks, and visit the GitHub repo for more on how it works.

The tutorial is geared towards people that have little-to-no coding experience and are unfamiliar with things like GitHub, Eleventy, and Netlify. By the end of the tutorial you should understand terms like “repository” and “static site”; you’ll be able to edit your projects, pages, and posts; and your website will be hosted for free. Though basic experience with code such as HTML or CSS may be useful, it isn’t necessary for this tutorial since we’ll be using the hosting user interfaces to set this all up.

Let’s get started