> The site design and content are great; the execution, not so much.
As I mentioned, I think it would be helpful to link an example (even just one) of a website you think is executed correctly and does similar things but much better.
> 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 don't think that is what total blocking time means... You can see that just loading the page, or looking at the Pagespeed strips. To quote your own reference: "The Total Blocking Time (TBT) metric measures the total amount of time after First Contentful Paint (FCP) where the main thread was blocked for long enough to prevent input responsiveness." It is not blocked 'from rendering for over 5 seconds'. I would agree that not rendering for 5 seconds would be a bad thing. But it is not what that number means, because it is defined as after first rendering, and about something else entirely (user input).
> 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.
Uh, no? There are reasons that user-agent sniffing is highly deprecated. Because if you snoop the user-agent (I'm not sure how else you propose that that crap not be downloaded), that is crack and aids, and extremely bad and fragile: even if you somehow mapped all user-agents to date to their full sets of undocumented unstandardized media-query equivalents, it will break with the next user-agent or browser decision to spoof user-agents for privacy etc and stop exactly this sort of snooping... It also means that you've broken responsiveness: if the user resizes the page, now everything breaks because they don't have the newly-matching media-queries.
This also underrates the difficulty of getting mobile/smartphone right. We have had problem after problem with iPads and iPhones, and that's with using media-queries which are supposedly supported & standardized; some sort of server snooping would be even worse. (Leaving aside the issue that it would be hard to implement this to begin with on a static website.)
> 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.
Huh? We do use a high-quality free font with true smallcaps, Source Serif Pro and Sans. That in fact was a major reason we picked the Source family: because Frank did true smallcaps for it.
I am also not sure we actually need the new variable fonts for Sans, since we don't use much Sans.
> Like the fake small caps, the typography doesn't look great on a smaller, high resolution screen.
How so? I'm wondering if you broke the site with a plugin or something, if you think we are using 'fake smallcaps' and that it looks bad on high resolution screens...
> The experience isn't good on mobile; it's not cool to have those previews keep popping up that I didn't ask for
Obviously, I very strongly disagree that the previews are useless for reading my site, and I'm puzzled by the idea that there are people who are tapping away at links on smartphones and want them to open up the full link when smartphones barely even support tabbed browsing, but are frustrated by seeing excerpts or summaries instead and getting access to cleaned compressed archived snapshots etc.
However, for those who dislike them, they can be disabled by a single tap of the only icon attached to a preview (besides the 'X' to close it), the struck-eye icon, which is widely understood to indicate hiding/disabling things.
> and that icon bar is inappropriate for small screens.
I'm not sure what you mean by 'icon bar'. If you mean the theme toggle in the right-hand corner, which provides controls like 'disable previews', then it is not inappropriate; we started with a smaller toggle bar, but I and other users found that anything smaller is hard to interact with because the tap targets are too small.
> 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.
Sometimes you need to be specific. You don't establish that that CSS is unnecessary to achieve the goal. (This is where a comparable site would be especially helpful in critique.)
> As you can see from the Lighthouse report, he doesn't bother to minify his CSS or JavaScript.
Whatever Pagespeed or Lighthouse might say, we haven't found minification to be a big benefit when we turn it on. And we have found it to make debugging harder and also sometimes break the site. (Cloudflare choked on, IIRC, inlined SVG at one point, completely breaking the site. That was fun to figure out.)