csswizardry

Off-topic, but Meoweler is a goldmine—thank you!

Noticed that https://wozniak.ca/blog/2024/01/02/1/index.html (on the HN hompeage as I write this) was serving a 451 response, which I’ve never seen before.

> No mentioning of semantic tags.

Yes, because it’s an article about attributes…

As a Brit, ‘jaywalking’ is so alien to me. I once jaywalked in front of a police car who stopped and waved/signalled me across the road! Whenever I’m overseas, crossing anywhere when the road is clear is second nature to me and I have to remind myself not to. Conversely, you can always spot a foreigner in the UK: they’re the ones waiting for the signal at a deserted crossing at 2am.

Fixed link: https://twitter.com/x

Thanks! The plan is to update the post as new facts, figures, and information become available.

I’m very late to the party, but I wrote about this back in early 2016! https://csswizardry.com/2016/02/mixins-better-for-performanc...

A lot of things aren’t necessary.

Thank you!

> …and faster response times across the globe, right?

Unfortunately not. There is no benefit to leaving your critical files on anyone else’s infrastructure: https://csswizardry.com/2019/05/self-host-your-static-assets...

As someone who’s at the frustrating intersection of fascinated and clueless, what are the implications of a blood sugar spike and are they bad? Is the problem the absolute amount of blood sugar or is it the sudden change in blood sugar levels? And what is the general takeaway or advice from this study?

A lot of questions there, but I would be really grateful for any insights. It’s something I know I should know plenty more about.

About to release this fix now.

> I don’t believe it’s technically correct to characterise stylesheets as render-blocking…

But they are. There’s absolutely no question about that. A browser will only render in the absence of a stylesheet if a) there’s programmatic intervention from the developers (e.g. timeouts) or b) if the server ultimately responded with a TCP timeout because of an outage. In the latter case, rendering is blocked for 20s on Win and 80s on *nix. CSS is render-blocking. There are no two ways about it. You can verify either slowdowns or outages by using https://slowfil.es or a blackhole server respectively.

> If you control your layout with JavaScript, things like orientation changes can take a short time to update after the viewport has altered. It’s not ideal, but it’s not awful either.

In this scenario you’re CPU-bound and not network-bound. Dispatching render-blocking requests on a high-latency connection JIT is far worse than front-loading your CSS asynchronously with minimal priority.

> I disagree with your second claim. I assert (without statistics) that the chance that a print stylesheet will be needed are more than a million to one against

I agree that print stylesheets are very very very rarely needed. My point—which I stated already—is that to accommodate individual media types increases complexity in the browser for zero gains.

It actually wasn’t a deliberate inclusion—I didn’t give it any thought, largely because it makes no difference and isn’t relevant to the topic of the article. Hopefully readers feel empowered enough to delete their own forward-slashes.

Stylesheets are different story to images. Stylesheets (that match a media type) are render-blocking whereas images are not. Lowering the priority of a non-matching stylesheet but still downloading it is a better option than JIT loading one.

You can detect print very, very easily. I helped the NHS track print-users using this: https://csswizardry.com/2018/03/measuring-the-hard-to-measur...

Note that we can’t use `background-image: url();` here as browsers will not print background styles by default, so we’d likely miss the majority of cases.

Fonts have versions, too; adding them all to the browser would be nigh on impossible.

OP here: Important point is that it’s the file’s onload event and not the window’s onload event that we’re listening for.

> The whole thing is a dubious technique anyway because it depends on JavaScript—if JavaScript is disabled…

I address this twice in the article, which presumably you didn’t read.

> P.S. Why the trailing slash on the tag? It’s completely useless…

Are you just looking for things to be unhappy about?

OP here: Simply because the only mechanism a browser needs is ‘a currently-matching media type’ or ‘not a currently-matching media type’. There is no need to add further checks for a specific media type; that would lead to added and potentially infinite complexity as new media types are added.

I know how browsers work, but thanks.

The tool you linked does not solve the same problem, as the problems isn’t file types but URIs. Google is able to provide the tiniest possibly font files by hinting them for the specific browser/platform requesting them. We never consistently or predictably know the resultant URI of a Google Fonts-hosted font file. Here is a Tweet to the same effect from two days ago. Believe me, I’ve researched this :(

https://twitter.com/csswizardry/status/1265716520346320903

OP here. Cross-domain caching is a myth[1] so reusing font files won’t work. In fact, it’s literally impossible in Safari[2] and soon to be made impossible in Chrome[3].

1. https://csswizardry.com/2019/05/self-host-your-static-assets... 2. https://andydavies.me/blog/2018/09/06/safari-caching-and-3rd... 3. https://bugs.chromium.org/p/chromium/issues/detail?id=910708

I did say right there in the article:

> On this site, in which performance is the only name of the game, I forgo web fonts entirely, opting instead to make use of the visitor’s system font. This is fast, incredibly well suited to the device in question, and has almost zero engineering overhead.

So… well read, I guess?

Thanks for the feedback!

Thanks! Though GTMetrix hasn’t been considered a reliable or relevant tool for a while now, unfortunately.

OP here. Inlining CSS won’t work as the request is UA-sniffed.

OP here. My beef wasn’t and isn’t with the ads or monetisation: it’s with the engineering decision to bury the product’s primary content in a 1.2MB JS application. The image itself just needs to be an `IMG` element in a server rendered page—ads, tracking, comments, upvotes, etc. can and should be all loaded as secondary content.

My beef is with a ‘mobile-optimised’ image hosting platform taking over 40s to display an image on mobile.

My pals cracked this one back in June! https://parall.ax/blog/view/3301/boris-johnson-the-unlikely-...

I’m a proud Loiner.