Or just put in some effort to make things actually more efficient and don’t waste resources on the user’s machine.

ashwinsundar 5 days ago | parent | next [-]

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

▲

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

“Just” is doing a lot of heavy lifting there. There’s a lot that has to go on between the backend and frontend to make modern websites with all their dynamic moving pieces, tons of video/imagery, and heavy marketing/analytics scripts run on a single thread (yes I’m aware things can load/run on other threads but the main thread is the bottleneck). Browsers are just guessing how it will all come together on every page load using heuristics to orchestrate downloading and running all the resources. Often those heuristics are wrong, but they’re the best you can get when you have such an open ended thing as the web and all the legacy it carries with it

There’s an entire field called web performance engineering, with web performance engineers as a title at many tech companies, because shaving milliseconds here and there is both very difficult but easily pays those salaries at scale

▲

giantrobot 5 days ago | parent [-]

> There’s a lot that has to go on between the backend and frontend to make modern websites with all their dynamic moving pieces, tons of video/imagery, and heavy marketing/analytics scripts run on a single thread

So there's a lot going on...with absolutely terrible sites that do everything they can to be user-hostile? The poor dears! We may need to break out the electron microscope to image the teeny tiny violin I will play for them.

All of that crap is not only unnecessary it's pretty much all under the category of anti-features. It's hard to read shit moving around a page or having a video playing underneath. Giant images and autoplaying video are a waste of my resources on the client side. They drain my battery and eat into my data caps.

The easiest web performance engineering anyone can do is fire any and all marketers, managers, or executives that ask for autoplaying videos and bouncing fade-in star wipe animations as a user scrolls a page.

▲

jameslk 5 days ago | parent [-]

> The easiest web performance engineering anyone can do is fire any and all marketers, managers, or executives

Your solution to web performance issues is to fire people?

	▲	giantrobot 5 days ago \| parent [-]
		When they're the cause of the web performance problems it isn't the worst idea. The individual IC trying to get a site to load in a reasonable amount of time isn't pushing for yet another tracking framework loaded from yet another CDN or just a few more auto-playing videos in a pop-over window that can only be dismissed with a sub-pixel button.

▲

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

You can't avoid sending the user photos in a news article, for example. So the best you can do is start fetching/rendering the page 200ms early.

▲

cs02rm0 5 days ago | parent | prev [-]

Theres only so much efficiency you can squeeze out though if, say, you're using AWS Lambda. I can see this helping mitigate those cold start times.