Understanding Eleventy write performance

[j9t]

I have an Eleventy site that deals with a great number of Markdown files (~4,000, largely front matter though) and where I observe a what I find unusual decrease in write performance:

[11ty] Benchmark  19177ms  15% 63866× (Configuration) "slugify" Nunjucks Filter
[11ty] Copied 45 files / Wrote 444 files in 131.32 seconds (295.8ms each, v2.0.1)

On another Eleventy site, average write performance is significantly faster, even though the respective files contain a lot more content:

[11ty] Benchmark    923ms  40%   119× (Configuration) "htmlmin" Transform
[11ty] Copied 74 files / Wrote 119 files in 1.86 seconds (15.6ms each, v2.0.1)

How can I understand better what’s slowing performance down by such a big factor (20×)?

Are there any performance best practices and perhaps low-hanging fruits I may miss?

[j9t]

Could investigate a little more. Some data points for anyone interested in this topic, too:

• Debug mode helps 🙃
• It seems that for said site, the great number of tags (~400) contributes a lot of build time for the tags page alone (20–30 seconds!?)
• On a first test, it seems that --ignore-initial is of limited but some use—test-driving

[pdehaan]

Yeah, that's pretty much where I start. Turn on as much debugging info as I can to see if it's a specific filter or shortcode that can be optimized or refactored. But the more tags/collections/data 11ty needs to manage, the more memory and resources everything takes (since I believe global collections data are passed around to every template).

But like you're seeing above, there seems to be considerable time (19s, or 14.5% build time?) spent in the slugify filter alone since that filter is getting called almost 64k times. Not always an easy solution (apart from refactoring the problematic pages). Since it looks like slugify is getting called 64k in 444 written files (146.1×/file, although that's probably heavily weighted towards a few archive pages).

[j9t]

Thanks Peter!

I took that to review the slugify filter. I use it exclusively for tags—which are already set up to be URL-safe. (Duh.)

Testing slugify removal seems to shave off nearly 50% time, without changes to the output (no surprise given that the tags already have the correct format).

This seems to be a great performance improvement!