[mbforbes]

Since this article mention's Gwern's site several times:

While I admire Gwern's work a lot, I often find his website is trying to do so much that my browser will really struggle. Especially on mobile. It's bad enough I usually avoid reading there, which is a shame.

I'm not sure exactly what causes it, but it might be a combination of page length with many layers of nested, richly formatted and embedded content.

[alwillis]

> While I admire Gwern's work a lot, I often find his website is trying to do so much that my browser will really struggle.

As a web developer, I often look at the HTML and CSS of interesting websites…

I gotta say, I've never seen anything quite like https://gwern.net.

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, like downloading 14 fonts.

He's doing everything you're not supposed to do if you care about your users or performance in general.

Every page is pretty much like this.

From cssstats.com:

Rules: 1,484

Selectors: 1,757

Declarations: 3,914

Properties: 243

Total Selectors by Type

Selectors are the part of a CSS ruleset that describes what elements in a document the rule will match.

ID: 534

Class: 1,516

Pseudo Class: 296

Pseudo Element: 382

It just goes on and on like this.

[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?

[rednafi]

Ditto. I like Gwern's content but not much the presentation. The same goes for Simon Willison's site.

I much prefer the brutalist look of Drew Devault, Fabien Sanglard, or Dan Luu's site.

[garof]

For the lazy who don't know some of these:

https://drewdevault.com

https://fabiensanglard.net

https://danluu.com

Dan's is the only one I recall visiting before. And it's memorable because of the maximally wide text width. Personally I would find Dan's site more usable, and visitable, if there was an ordinary text width. Some reasonable default that is more readable.

[emmanueloga_]

The "danluu layout" takes minimalism too far in my opinion, and getting in and out of some readability mode can be slow/annoying.

Just a lil bit of padding here and there could improve the presentation a lot, but I'm guessing the author consider this design kind of a trademark by now.

[crabmusket]

Reader mode works great on danluu.com, as does a very simple user stylesheet along the lines of https://bettermotherfuckingwebsite.com

[gnicholas]

I don't mind Drew or Fabien's layout, which have a reasonable column width. But Dan's site is unreadable for me (at least on desktop) without reader mode. What would be the reason for choosing to have full-width text on a blog?

[elevatedastalt]

Dan's website is a great example of the pendulum swinging in the other direction to malicious non-conformism. Yes, UXers have made modern web design hell, but presenting a raw unstyled html isn't respecting your user much either.

[zelphirkalt]

I think that is not so simple to solve. Limit it to some column width? Someone will complain that it only uses one third of their screen. Unlimited width? Someone will complain about whole width text. But the good thing is, that there is reader mode and evem if there wasn't, you could zoom in or resize the browser window or send to new window and resoze only that.

[gnicholas]

Yeah, most browsers do have reader mode now. I honestly don't love them because they're typically not customizable, and are sometimes too narrow for my taste.

I wouldn't mind resizing the browser window except that with tabbed systems that means you're resizing all of the tabs at the same time.

I tend to think that if you make the width something in the neighborhood of what the NYT, Medium, or other well-known sites use, people won't complain. But I could be wrong!

[zelphirkalt]

Firefox reader mode is a little bit customizable. Font size column width and so.

Cumbersome, but one can change width of a single tab by using the inspector and using the responsive design mode.

Perhaps there is room for another Firefox feature to limit width of a page. Perhaps multi-column mode, where one can for example split the page in 3 columns and each column displays, what could not be fit on the previous column. And resizable columns maybe.

[account42]

What would be the reason for choosing a browser width wider than what you can comfortably read?

[hollerith]

Huh: my browser is always maximized (the width of my monitor) as are all the other apps I regularly use -- similar to how an iPad worked before iPadOS introduced multitasking -- but then I'm scaling the UI by a factor of 200% and its not a HiDPI monitor, just a humble 1080p one, so the effective horizontal resolution of my browser's viewport is 960 pixels. At that resolution, line of text on danluu.com and in comment sections on HN are longer than I would prefer them to be, but they're not so long as to be a significant annoyance.

Back when I used an OS that didn't let me scale the UI, I'd occasionally make the browser window narrower to make the lines of text on a site more reasonable, but I definitely appreciated it when sites made it unnecessary for me to do that, by specifying body {max-width: 45em;} or something.

[reitanuki]

ooi what's wrong with Simon Willison's site?

I suspect my site would fall afoul of some of the taste around here but I didn't think Simon's was bad as far as they went.

[rednafi]

I am a regular reader of Simon Willison. The content is fantastic but on mobile, I find the layout a bit confusing.

[elevatedastalt]

I don't think Gwern's site is optimized for mobile viewing at all. It works great on a desktop and I think that's where such long form is best consumed.

[gwern]

Yeah, it used to be fast, but then you add features and have pages with a ridiculous amount of stuff in them compared to most pages (every DOM element costs you), and, well...

We plan to go back and optimize stuff once one last feature is in. (It's a novel feature I came up with I've never seen anywhere else: I call it the 'browsing history' feature. Every link you pop up will also be transcluded into a section at the end, so you can create your own bibliography as you go. This means you don't have to have FOMO about reading every popup or tab as you go, and you can rebrowse what might be interesting at the end, or even snapshot the page with a particular set of links having been browsed.)

Achmiz meant to get around to it a while ago but among other things, he got nerdsniped by studying high-dimensional geometry for modeling an extradimensional invasion in his current D&D campaign: https://blog.obormot.net/Extreme-D-D-DIY-adventures-in-hyper...