[chrismorgan]

Original article title: “Why I Created Banner Blog”. But I honestly don’t think it explains why. You establish the problem, but don’t remark on a couple of existing alternatives that might satisfy your requirements, and more importantly, you don’t explain why you’re making it a platform, rather than just something for yourself. Because honestly, if you want to blog, running a platform for everyone and their dog… well, that’s something completely different, and something which will take away from your blogging opportunities.

Current HN title: “Why Blogging Platforms Suck”. This would honestly be a completely different article, and one I’d generally agree with (which is why I will always insist on controlling my own site stack). Yet you appear determined to get into running a blogging platform, and I would be curious why.

Some more remarks:

• Well done on inlining the stylesheets. Having zero subresources has a way bigger effect on page load time than people tend to expect. (Want bonus marks? Strip unused styles from the sheet, and inline custom properties where possible (currently always)! You can save hundreds of bytes! Hundreds, I say!)

• You’re not compressing responses, but generally might as well; though thanks to TCP slow start stuff, it’s unlikely to make any meaningful difference at this scale. (You can get it down from just under 11KB to about 3.5KB.)

• The JSON-LD block is all wrong. It claims it’s a http://schema.org/website (which I believe must be spelled http://schema.org/WebSite to be interpreted correctly; aside: uh oh, the JSON-LD spec uses lowercase schema.org slugs in examples, sigh) but it should be an Article, and then has a nonsense `about` field that puts the title as the @type. Which is something I’ve seen once before, on Bear Blog. Are your tech stacks similar and it’s the same library doing it, or did you copy it, or is it sheer coincidence that you did the same wrong thing? (Aside: I don’t really get why people bother with JSON-LD—does it actually help anything? In theory it’s neat, sure, but in practice does anything actually use it and wouldn’t use the traditional meta tags if it weren’t there?)

• `body { width: 100% }` needs removing. It means that the page always overflows horizontally. If you removed the default 8px margin, it’d merely become unnecessary rather than harmful. `body { min-height: 100vh }` is also not what you want, though the situations that expose the problems are likely to be rare; but the normal trick for getting what you’re going for (… if you even decide it’s worth it) involves setting a minimum height of 100% on html and body.

• <link href="/favicon.ico" rel="shortcut icon" type="image/x-icon">: type="image/x-icon" is superfluous since it’s the only icon, `shortcut ` is superfluous (that’s a matter of ancient history), … and in fact the entire tag is superfluous given it’s the only icon and the URL is /favicon.ico.

• Your font size is significantly too large on large screens. It’s extremely too large on small screens. I recommend not exceeding 1.25rem (typically 20px) as a :root font-size, and sticking to 1rem (typically 16px) on smaller viewports.

• Please don’t use a base font-weight of 300. On some very common configurations (generally involving Windows and low-DPI screens), it can be fairly difficult to read. Body text should always use weight 400. (From this and the scrolling things, I’m getting the sense you use macOS.)

• `font-family: Roboto;` means that most of your viewers will get the default font, which defaults to a serif like Times. Honestly, I recommend sticking with it. Serifs are generally cooler. But if you actually care for what you specified, then make sure a generic family is included.

[hobofan]

> I don’t really get why people bother with JSON-LD—does it actually help anything?

It helps with Google SEO which makes sense, as schema.org is essentially stewarded by Google.

> In theory it’s neat, sure, but in practice does anything actually use it and wouldn’t use the traditional meta tags if it weren’t there?

Yeah, for basic things like the website metadata it's redundant with meta tags. It becomes more useful when it comes to more rich types like e.g. a recipe.

[chrismorgan]

Yeah, if you’re actually using it as an alternative to microdata, maybe there’s value. But the only times I think I ever see it it’s just WebSite or Article, at which point I’m dubious if there’s any value. In smaller providers like this they seldom include all of the fields that they reasonably should, too, e.g. datePublished.

(Oh yeah, that’s another point I missed in my comment: the <time> needs to be <time datetime="2023-12-01">. Also, 12/01/23 in the text, ugh, yucky USA middle-endian date format, and with a two-digit year at that.)

[cryptos]

> Well done on inlining the stylesheets. Having zero subresources has a way bigger effect on page load time than people tend to expect.

Is that still true with HTTP/2 (or newer)?

[chrismorgan]

HTTP/2 helps with parallel resource loading, but that’s not the problem in this case—subresources like we’re talking about here are largely going to be loaded serially because that’s how things are. HTTP/2 Server Push might have helped some of the problem, but it’s more or less died because the way it was designed had serious problems and fixing them was going to take more effort than it was worth.

But when I say “having zero subresources”, I actively mean having zero subresources. The bit that really startles people is how much faster a page with inlined scripts and styles is (up to a point, but that point is typically over a hundred kilobytes of each) than a page with subresources present in a warm cache where the browser doesn’t even need to revalidate. Letting the browser just tear through it all rather than having to mess around with caches has, as I say, a bigger effect than people normally expect.