The site design and content are great; the execution, not so much.
I only investigated because someone in the thread mentioned they had a bad experience on a smartphone; now I know why.
Each font is another HTTPS request to the server; doesn't matter if they're subsetted or not. However, the combination of all the JavaScript and the multiple CSS files creates a total blocking time [1] of 5266 ms according to WebPageTest.
The page is blocked from rendering for over 5 seconds due to all of the crap he's downloading and the way he's doing it.
I didn't count where he downloaded one character out a font by subsetting. There are actually 30 @font-face declarations for fonts, some subsetted and some not.
Where he saved on downloading fonts, he used it up (and more) on the JavaScript and the CSS.
Someone using a browser that doesn't support the latest HTTP 3.0 protocol on a fast connection isn't going to have a good experience.
Source Sans Pro is available as a variable font; instead of downloading each individual weight, he could have downloaded just a couple of files and have all of the weights.
Ironically, after all that, he didn't pick a font that supported true small caps; he's using synthetic small caps, which don't look as good. There are plenty of high-quality free fonts with true small caps. It doesn't make sense.
The experience isn't good on mobile; it's not cool to have those previews keep popping up that I didn't ask for and that icon bar is inappropriate for small screens.
He has dozens and dozens of media queries; how about let's not download the crap I don't need on mobile? If I'm on smartphone, I don't want the drop caps and the other flourishes that only make sense on desktop/laptop sized displays.
Like the fake small caps, the typography doesn't look great on a smaller, high resolution screen.
A little knowledge can be a dangerous thing; his code is full of selectors like this:
.TOC > ul ul ul ul ul ul > li::before {
counter-increment: htoc_6;
content: counter(htoc_1) "." counter(htoc_2) "." counter(htoc_3)
"." counter(htoc_4) "." counter(htoc_5) "." counter(htoc_6) "\2006 ";
}
Among other things, it's so specific, making it very fragile; it also explains why his CSS is so bloated because there are hundreds of lines just like this. As you can see from the Lighthouse report, he doesn't bother to minify his CSS or JavaScript.
Sure, for anyone on a recent device on a fast connection, it won't make a difference. But others on slower connections and older machines are going to wait noticeably longer and use more battery just to download and render his content. Hell, you could be on an iPhone 15 Pro in the middle of nowhere where all of you have access to is 3G or similar. Or on shitty coffeeshop wifi.
I left out the information from Lighthouse because I thought it was too inflammatory for HNers, but here goes:
On a scale 0-100, the performance score is a failing 44
First Contentful Paint 2.1 s
Largest Contentful Paint 2.6 s
Total Blocking Time 3,290 ms
Cumulative Layout Shift 0.461
Speed Index 3.6 s
Eliminate render-blocking resources Potential savings of 1,160 ms
Minify CSS Potential savings of 20 KiB
Minify JavaScript Potential savings of 82 KiB
Reduce unused CSS Potential savings of 52 KiB
Reduce initial server response time Root document took 680 ms
Avoid an excessive DOM size 1,555 elements
Reduce JavaScript execution time 3.9 s
Minimize main-thread work 6.8 s
Largest Contentful Paint element 2,550 ms
Avoid large layout shifts 4 layout shifts found
[1]: https://web.dev/articles/tbt