3 ms·

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 1y ago
Yeah but it "fake" sub 50ms load when you load it at the front before it shows
- dlivingston 1y ago
  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 https://en.wikipedia.org/wiki/Speculative_execution [1]: https://www.chromium.org/developers/design-documents/dns-prefetching/ https://www.chromium.org/developers/design-documents/dns-pre...
  - tonyhart7 1y ago
    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 1y ago
  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.
jmull 1y ago
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 1y ago
  > 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
dietr1ch 1y ago
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.

tonyhart7 1y ago

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

dlivingston 1y ago
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 https://en.wikipedia.org/wiki/Speculative_execution [1]: https://www.chromium.org/developers/design-documents/dns-prefetching/ https://www.chromium.org/developers/design-documents/dns-pre...
- tonyhart7 1y ago
  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 1y ago
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.

jmull 1y ago

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 1y ago
> 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

dietr1ch 1y ago

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.