README, optimizations, and more

Since my last devlog:

1. I wrote the README.
2. I optimized the theme until it earned perfect 100s in every category on Lighthouse on every page.
3. I added a light mode.
4. I added support for tables of contents.
5. I added RSS feed generation.
6. I rewrote one of the demo blog posts.
7. I added styles for HTML tables

Link to the diff between last devlog and this one

Optimization

Most of the work I did today is pretty self-explanatory from my little summary, but the optimization work probably merits elaboration.

---

So while I was writing the README, I had the idea to include the Lighthouse scores. When I checked, they were 100/100/100/92 on mobile and 92/100/100/92 on desktop.

“100s on Lighthouse in some fields” doesn’t sound nearly as nice as “100s on Lighthouse in every field”, so I decided to start optimizing. Lighthouse told me that the SEO problem was a lack of descriptions, and the desktop performance problem was excessive network requests and chained network requests.

SEO problem

I fixed the lack of descriptions by adding descriptions. Simple as that. I wrote descriptions for all of the existing pages, added a description field to the CMS config, and added a mention of it in the usage guide. The network requests and chained requests were a bit trickier to solve.

Performance problems

The cause of the excessive network requests was that, even though the homepage didn’t use the KaTeX or Nueglow styles, they were still being imported. I solved that with a per-page check that runs at build time. Each page only imports the Nueglow stylesheet if it contains code blocks, and it only imports the KaTeX stylesheet if the page contains math blocks. Here’s a link to the relevant section of code. I think that it’s a pretty clever solution because it selectively removes the unnecessary CSS requests without using client-side JS or anything like that.

I used a similar approach to solve the chained requests. What was happening is that in order to download the woff2 files, the browser first had to download the CSS files, so it took twice as long because they couldn’t be downloaded in parallel. Font preloads are the way to solve this. The only problem is that if I preload too many font files, the browser will have download font files even if they aren’t used on the page. But if I preload too few, then the network requests are still chained. My solution was to have it check which font files each page needs and selectively preload only those font files. Here’s the relevant code if you want to see my implementation. Again, this solves the problem of unnecessary requests and chained requests without adding any client-side JS.

I’m glad that Lume and Vento are such powerful tools that I can easily do programmatic optimizations like this.

Next Steps

I think that the next thing I should do is submit my theme to the official Lume theme repo. That way I can simplify the installation process down to one command.