Those aren’t mutually exclusive goals. You can serve efficient pages AND enable pre-fetch/pre-render. Let’s strive for sub-50ms load times

▲

tonyhart7 5 days ago | parent | next [-]

Yeah but it "fake" sub 50ms load when you load it at the front before it shows

▲

dlivingston 5 days ago | parent | next [-]

I guess you could call it fake or cheating, but ahead-of-time preparation of resources and state is used all the time. Speculative execution [0], DNS prefetching [1], shader pre-compilation, ... .

[0]: https://en.wikipedia.org/wiki/Speculative_execution

[1]: https://www.chromium.org/developers/design-documents/dns-pre...

	▲	tonyhart7 5 days ago \| parent [-]
		also dns not changing every second where you website need it Yeah but you not only "count" it only when it shows tho???? I'am not saying its not "valid" but when you count it only when you shows it, are we really not missing a part why we need "cache" in the first place?

▲

dietr1ch 5 days ago | parent | prev [-]

Every layer underneath tries really hard to cheat and keep things usable/fast.

This includes libraries, kernels, CPUs, devices, drivers and controllers. The higher level at which you cheat, the higher the benefits.

▲

dietr1ch 5 days ago | parent | prev | next [-]

Idk, if you are starting from prerender/prefetch `where href_matches "/*"` maybe you are wasting resources like you are swinging at a piñata in a different room.

This approach will just force the pre-loader/renderer/fetcher to be cautious and just prepare a couple of items (in document order unless you randomise or figure out a ranking metric) and have low hit ratios.

I think existing preloading/rendering on hover works really well on desktop, but I'm not aware of an equivalent for mobile. Maybe you can just preload visible links as there's fewer of them? But tradeoffs on mobile are beyond just latency, so it might not be worth it.

▲

jmull 5 days ago | parent | prev [-]

Not mutually exclusive, but they compete for resources.

Prefetch/prerender use server resources, which costs money. Moderate eagerness isn’t bad, but also has a small window of effect (e.g. very slow pages will still be almost as slow, unless all your users languidly hover their mouse over each link for a while).

Creating efficient pages takes time from a competent developer, which costs money upfront, but saves server resources over time.

I don’t have anything against prefetch/render, but it’s a small thing compared to efficient pages (at which point you usually don’t need it).

	▲	ashwinsundar 5 days ago \| parent [-]
		> Creating efficient pages takes time from a competent developer, which costs money upfront, but saves server resources over time. Not trying to be a contrarian just for the sake of it, but I don't think this has to be true. Choice of technology or framework also influences how easy it is to create an efficient page, and that's a free choice one can make* * Unless you are being forced to make framework/language/tech decisions by someone else, in which case carry on with this claim. But please don't suggest it's a universal claim