[gwern]

I don't think any of the numbers you quote are really that meaningful. Like you are quoting IDs - what is the cost of an ID? If all the IDs were stripped, would that even make a measurable difference? Really now.

Similarly for those other numbers about selectors or classes. How much of a performance burden are those, really? Not the numbers punched out by some cargo cult calculator tool - what is the actual impact?

(I would try to compare cssstats.com's numbers for Gwern.net to sites we can all agree are "very user hostile and wasteful of the user's resources", like Medium.com or Substack... except it breaks and won't even report numbers.)

> It's an impressive looking site IMHO; but pretty much everything he's done is very user hostile and wasteful of the user's resources,

That seems like an extreme take. 'Pretty much everything'? There's no feature you like or find useful? It's all a waste? Your non-wasteful user-friendly version of gwern.net just throws out everything like the dropcaps, the code folding, the popups, the transclusions, the sidenotes, the backlinks, the link-icons...?

If that's not what you mean, can you point to a website which comes anywhere near Gwern.net in terms of supporting reading long, complex, heavily hyperlinked & annotated documents, and clearly outperforms it browser-wise?

> like downloading 14 fonts.

I'm not sure what page you are looking at, but what are these '14 fonts', exactly? It sounds like you're counting every font file without looking at them at all, and you are including, eg, the dropcaps which are subset to 1 letter per font file and so are efficiently only ~1-10kb each, or the link-icon font file, which is like 5kb compressed and saves requesting a bunch of SVG icon files, or the Quivira fallback (to avoid box Unicode garbage) which shouldn't be used in most pages but if it is, that's fine, because it's all of 3.5kb. Surely any performance woes do not come from downloading 5kb to draw a fancy 'A' at the beginning of the article, and is worth it for such a signature bit of visual style...

Even the regular font files are subsetted to save space. (I wouldn't be surprised if there are a lot of websites with just '1 font' which weigh more than those '14'.) So the font files do not seem like they are 'wasteful' to me.

[alwillis]

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

[gwern]

> 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.)

[alwillis]

> Whatever Pagespeed or Lighthouse might say, we haven't found minification to be a big benefit when we turn it on.

Minify CSS Potential savings of 20 KiB Minify JavaScript Potential savings of 82 KiB

The benefit is less data going over the wire. I get it--100 KiB doesn't sound like much these days, especially given the page weight of almost 800 KiB. But it's still an extra 100 KiB that doesn't need to be transferred and it adds up over time.

If you minimized your code and did a few more optimizations, you're talking about a more significant amount of data you could be saving your viewers.

> Sometimes you need to be specific. You don't establish that that CSS is unnecessary to achieve the goal.

That selector and the many others like it is a sign of poor CSS architecture. If your design results in you having to be that specific, it means you're doing something wrong.

It's a classic case of fighting the cascade instead of having it work for you. If there was an architecture (like ITCSS or OOCSS for example) [1], you wouldn't need to write such a deeply nested selector in the first place and the dozens more just like it.

Creating reusable components in CSS would reduce the amount of code dramatically and make it much easier to maintain.

[1]: https://www.xfive.co/blog/itcss-scalable-maintainable-css-ar...

[2]: https://www.slideshare.net/slideshow/our-best-practices-are-...

[3]: https://csshell.dev/posts/overspecified-specificity/

[gwern]

> The benefit is less data going over the wire. I get it--100 KiB doesn't sound like much these days, especially given the page weight of almost 800 KiB. But it's still an extra 100 KiB that doesn't need to be transferred and it adds up over time.

How much does that save, after the Brotli compression, and how much does it contribute to your supposed TTB? And why would it affect the page performance once loaded? And how does your alternate of CSS grids change that? If it is responsive, it is still going to have to define a bunch of CSS to explain what the layout is and how it changes.

> If your design results in you having to be that specific, it means you're doing something wrong.

Does it really? You keep making these assertions like 'you're using fake smallcaps' and then not backing them or explaining them, or giving any examples whatsoever of a site doing it right.

[alwillis]

> Uh, no? There are reasons that user-agent sniffing is highly deprecated.

I never mentioned user-agent sniffing nor would I ever recommend this outdated technique.

Using media queries for responsive design became a thing in 2010 with Ethan Marcotte's seminal article "Responsive Web Design" [1].

In the intervening 14 years, we have much better ways of adapting to different screen sizes. In fact, using CSS Grid for layout as it was intended results in responsive layouts without media queries and breakpoints.

Watch Jen Simmons' videos on intrinsic design [2] for the full run-down.

[1]: https://alistapart.com/article/responsive-web-design/

[2]: https://www.youtube.com/playlist?list=PLbSquHt1VCf34IngL-rsj...

[gwern]

This seems to be a bait-and-switch argument. I can't see how any grid feature can handle all of the media-query things you highlighted as wasteful bloat like "the drop caps and the other flourishes". How does that handle dropcaps, sidenotes & margin-notes, popups vs popovers, utility classes like disabling on mobile vs desktop, the different styling of the header, plus all of the small adjusts like fonts or line-heights or justification...?

Nothing in your first link addresses that, and this grid approach sounds limited to just moving a few blocks around to be a rectangle instead of a square or something. (Like, I am looking at random moments in these 5 hours of videos, and it all seems to be like that, like "What do CSS features like CSS Grid, Flexbox, Multicolumn, Flow layout and Writing Modes mean for our design medium"? Well, for Gwern.net - they mean little. Most of the media queries have nothing to do with putting something into various kinds of grids...)

How is this is a general replacement for media-queries - as opposed to a minor technique good for rearranging some carousels or some columns?

Again, I think you would benefit from being specific. How, exactly, does CSS Grid free us from media queries and breakpoints for the things we use media queries & breakpoints for, like dropcaps or switching between popups & popovers? And what is an example of a site which uses just CSS Grid for all this and avoids downloading all that crap as you desire?