[411111111111111]

HN, which is as far removed as you can get from modern websites takes 700-900ms from initial request to render if you're in a logged in session.

Whoever claims that sub second rendering isn't outstanding is just clueless.

[troysk]

Your location decides the latency of the request. If you are close to server you can do less than 200ms time to first byte. Getting a server near your users help.

After that you have 500ms to render your webpage. If you are lazy loading images, and most assets below the fold, thats a lot of time to get a page rendered.

You may take a look at my personal website (https://www.troysk.com/) which is hosted via Cloudflare so has CDN support and does sub second render on first load even though its image heavy.

[lelandfe]

You have less CSS than HN, and hardly any JS. This doesn't add anything to the discussion of if this is easy or hard to do – your site will always have a fast FCP, even if you weren't serving with a CDN.

Note also that the parent commenter mentioned being logged in to HN. You're serving a static page, which will always be fast. There are many aspects of HN's site that cannot be cached for logged in users, which will mean a higher TTFB.

> If you are lazy loading images

> sub second render on first load even though its image heavy

Images are not render blocking, and so won't be a part of this discussion. (Nor would I consider 1MB of mostly SVGs to be "image heavy")

Your site actually has room for improvement on performance. You could likely cut your overall page weight in half (not that it would do much, being default fast).

[troysk]

> You have less CSS than HN, and hardly any JS. This doesn't add anything to the discussion of if this is easy or hard to do – your site will always have a fast FCP, even if you weren't serving with a CDN.

Your observations reeks of incompetence. Are you seriously comparing a few bytes difference? The site loads more CSS from https://www.troysk.com/stylesheets/style.css

And hardly any JS? Can you even read code?

Many sites use static caching and then load dynamic parts asynchronously. The goal is to provide the end user a usable UI real fast. There is also Fastly and other new caching solutions if you are interested to know more.

> Your site actually has room for improvement on performance. You could likely cut your overall page weight in half (not that it would do much, being default fast).

How does it benefit? Have users reaction rates become faster than 1s on the web? This is a site not a game.

[lelandfe]

> Are you seriously comparing a few bytes difference? The site loads more CSS from https://www.troysk.com/stylesheets/style.css

Setting aside that you're wrong (your style.css is 1.7kB, HN is 2.2kB), that small difference is kind of my point. Discussions of if a quick FCP is easy or not should be based on a typical site. Tiny, static portfolio sites ain't that.

> And hardly any JS? Can you even read code?

Your site's entire JS weight is below 50kB.

> How does it benefit? Have users reaction rates become faster than 1s on the web?

Right. That's why I said, "not that it would do much, being default fast"

[troysk]

The numbers are wrong.

[lelandfe]

JS: https://i.imgur.com/C6ir5TL.png

CSS: https://i.imgur.com/sgmlnkF.png

Not sure what you're doing at this point. Are you trying to make the case that your site uses a lot of JS...? The site's entire JS package consists of LoadCSS, some ScrollMagic calls, and a Google Analytics tag.