Browsers are pretty good at loading pages • Hacker News Board

Re: Browsers are pretty good at loading pages

#231

Post by manigandham » Mon, Jul 22, 2019, 5:34 AM UTC

bryanrasmussen wrote: post #223

manigandham wrote: post #206

Earlier quoted context omitted.

JS is cached in its compiled state in modern browsers. There is no download or parsing step for repeated loads.

without a unique key in the js name/path, or any server action to enable it? If so I would like to read about this particular development - can you point me to an article on how they're doing it?

Yes, Chrome uses V8 which has Isolates (also used by some FaaS platforms like Cloudflare Workers), and adds more optimizations on top like disk-based caching to share across processes. The script is keyed from a hash of its contents.

https://v8.dev/blog/code-caching-for-devs

Re: Browsers are pretty good at loading pages

#232

Post by spullara » Mon, Jul 22, 2019, 5:40 AM UTC

tiborsaas wrote: post #49

jakobegger wrote: post #3

I don't get client side navigation. It's a worse experience in every way. It's slow, often doesn't support things like command-click, it usually breaks the back button, and even if it doesn't it breaks the restoration of the scroll position. The only thing worse is a custom scroll UI. Why do people try to reinvent the most basic features of a webbrowser? And if they do, why do they always only do a half-assed job at…

Because it's faster. If you don't have to download all the content again, force the browser to re-render everything, then by design you just get the new content from the server faster, if you have to download anything at all. The idea exists since the introduction of AJAX. Furthermore, you don't lose state, which makes things much more simple. Imagine a simple image gallery. You just update the tag, update the URL wi…

Try a blog not built on client side tech: https://www.lukew.com - the page loads are insanely fast, just click around.

Re: Browsers are pretty good at loading pages

#233

Post by onion2k » Mon, Jul 22, 2019, 5:41 AM UTC

TeMPOraL wrote: post #101

tiborsaas wrote: post #49

Earlier quoted context omitted.

Because it's faster. If you don't have to download all the content again, force the browser to re-render everything, then by design you just get the new content from the server faster, if you have to download anything at all. The idea exists since the introduction of AJAX. Furthermore, you don't lose state, which makes things much more simple. Imagine a simple image gallery. You just update the tag, update the URL wi…

> Because it's faster. The whole point of the article is that it's not true. It's not the only article that disproves it, and honestly, it's not difficult to notice it. Just go to any blog running off a static site generator; loading times of pure HTML webpages on good connection are so fast they whole thing outruns client-side page switches even if the page is already in memory.

... loading times of pure HTML webpages on good connection are so fast they whole thing outruns client-side page switches even if the page is already in memory.

Unfortunately for us front end engineers we can't rely on the user having any internet connection let alone a good one. Most of the push behind static site generators is to get as much of the code necessary to display all the website in to your browser as fast as possible, so it's there no matter what happens later. In cases where the user has a fast, robust connection that may well be slower than loading each page on demand, but in cases where the user's connection is slow and flaky (eg on a train) static sites generators do work better.

Perhaps the next generation of websites will take your connection in to account better. It depends on whether browsers and users will be willing to give up that information though. As far as I'm concerned I will use everything I can to improve the user experience on the sites I build.

Re: Browsers are pretty good at loading pages

#234

Post by LoSboccacc » Mon, Jul 22, 2019, 5:43 AM UTC

this is the first time I see mentions of react being difficult to optimize and I'd like to know more, is there any in depth quality article about it anybody knows on top of the usual light blogs a search finds?

Re: Browsers are pretty good at loading pages

#235

Post by weego » Mon, Jul 22, 2019, 5:48 AM UTC

ComputerGuru wrote: post #208

StavrosK wrote: post #109

Earlier quoted context omitted.

Case in point, navigation on my site is pretty fast (to me, at least) and doesn't use much JS at all: https://www.stavros.io (I promise I'll reply to your email soon)

Yeah, but you force me to stare at blank spaces while your webfont downloads [0]. I guess I should be thankful you’re not using that font for the body text, too (most sites do!). [0]: https://imgur.com/a/FAX6BDW

That's conflating two different issues

Re: Browsers are pretty good at loading pages

#236

Post by cottsak » Mon, Jul 22, 2019, 5:49 AM UTC

amelius wrote: post #124

jakobegger wrote: post #3

I don't get client side navigation. It's a worse experience in every way. It's slow, often doesn't support things like command-click, it usually breaks the back button, and even if it doesn't it breaks the restoration of the scroll position. The only thing worse is a custom scroll UI. Why do people try to reinvent the most basic features of a webbrowser? And if they do, why do they always only do a half-assed job at…

Curious, how would you implement Facebook's infinite scroll with only static pages?

Don't ask me how to solve a problem that doesn't need to be solved in the first place! :p #deletefacebook

Re: Browsers are pretty good at loading pages

#237

Post by fyfy18 » Mon, Jul 22, 2019, 5:50 AM UTC

manigandham wrote: post #201

tiborsaas wrote: post #49

Earlier quoted context omitted.

Because it's faster. If you don't have to download all the content again, force the browser to re-render everything, then by design you just get the new content from the server faster, if you have to download anything at all. The idea exists since the introduction of AJAX. Furthermore, you don't lose state, which makes things much more simple. Imagine a simple image gallery. You just update the tag, update the URL wi…

HN is very fast. Stackoverflow is very fast. Lots of other well engineered sites are very fast. As the article shows, browsers are well optimized and really don't download all the content again. In most cases it's just the HTML, which is streamed and rendered as it comes in. All the assets are cached, and scripts are even stored in compiled state to skip reparsing. Some sites might be slow at generating that HTML but…

This is what I don't really get. It seems like some people are under the impression that generating and parsing HTML is slow or takes a lot of resources. In almost all cases it's going to be faster and less resource intensive than generating JSON - especially if you are just using a templating language to interpolate some values. I agree that JSON could lead to less data being transferred over the wire, but that assumes your client already has cached the megabytes of JavaScript needed for you SPA. For something like a news site it doesn't make sense.

On the client parsing is fast, but the slow part is the browser laying out the page and fetching new resources - but that is going to be slow anyway, even if you do client side rendering. To make that fast you need do something more intelligent than just rendering a different React component, as well as prefetching resources in the background. But how many SPAs actually bother trying to do that?

I agree that SPAs have their place, and they have a lot of advantages over what we had before, but I just don't understand how it has seemingly become the default for any kind of web development - with such disregard for performance.

Re: Browsers are pretty good at loading pages

#238

Post by cottsak » Mon, Jul 22, 2019, 5:51 AM UTC

MattyRad wrote: post #225

cottsak wrote: post #211

Earlier quoted context omitted.

There's such an "ego load" associated with this investment too. I find that even when a developer comes to realise that the SPA mess is largely unjustified, they're rarely willing to admit or change anything.

Agreed. It's very much a sunk cost/escalation of commitment fallacy. https://en.m.wikipedia.org/wiki/Escalation_of_commitment Also bad is that junior engineers see shoddy client side code and internalize it. As an example, one junior engineer asked me how he was supposed to iterate over an array server side when I told him he didn't need to use Vue on a page. Server-side rendering fixtures had been completely forgott…

That must be humbling. Props for identifying it and adjusting course tho.

Re: Browsers are pretty good at loading pages

#239

Post by csande17 » Mon, Jul 22, 2019, 5:53 AM UTC

giaour wrote: post #210

pmontra wrote: post #97

Earlier quoted context omitted.

Media galleries (carousels) were client side things at least since the original xhr implementation in IE5. Maybe well before that if changing the src of a img let the browser load the new one from the server. I can't remember. But sites were small and even loading all the page again was not that bad. By the way, Rails Tutbolinks [1] are a way to get the same result with the server rendering only the html body and the…

IIRC, Turbolinks work by loading pages in the background in response to a mouseover event - by the time a click has registered, the remote content has already been downloaded and just needs to be injected into the page. The speed-up comes from anticipating clicks, not from JavaScript tomfoolery.

I think you're thinking of https://instant.page/ , which is pretty much as simple as "when link is moused over, tell browser to load the page in the background".

Re: Browsers are pretty good at loading pages

#240

Post by klez » Mon, Jul 22, 2019, 6:01 AM UTC

nojvek wrote: post #214

This may get downvoted to oblivion due to the HN bias against js. The correct answer is it all depends. Certain things are faster to do in JS. Certain things are faster as a page load. One has to profile and see what makes sense. There is a reason Atlassian is dog slow and trello runs circles around in terms of UI performance. The immediate Once you have a substantial amount of JS, and you’re an app site, which a lot…

> This may get downvoted to oblivion due to the HN bias against js.

Now, come on. Very few people in here would say that js had no place in the web. A lot of people are against js when alternatives exist. Trello is an application, so js makes sense there. A blog article that doesn't even display when js does not load, that's where people have a problem.