5 ms·

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

• alwillis 2y ago
  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 https://web.dev/articles/tbt
  • gwern 2y ago
    > 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.)