Browsers are pretty good at loading pages • Hacker News Board

Re: Browsers are pretty good at loading pages

#311

Post by repolfx » Mon, Jul 22, 2019, 6:05 PM UTC

TeMPOraL wrote: post #276

bryanrasmussen wrote: post #274

Earlier quoted context omitted.

Maybe it's a fault of Sturgeon's law - I sort of wonder if the "necessity" to have so much web output - so many applications, so much new development does not create a situation where there is a pressure to make 95% of everything crap, because you need to get a lot of developers to make things and some of those developers are going to be crap, and you need to make lots of decisions and some of those decisions are goi…

Might be, but I wouldn't discounting culture as a mechanism reinforcing it. People aren't working in isolation; they build on each other, and enshrine "best practices" that are often enough the sources of these problems. But thinking of it, Sturgeon's law may be at play. PHP used to suffer from similar reputation to JavaScript, and only started regaining its status as a proper server choice once the masses moved to g…

PHP is considered a proper server choice these days? When did that happen? It's been a long time since I encountered a new project being written in PHP.

Re: Browsers are pretty good at loading pages

#312

Post by repolfx » Mon, Jul 22, 2019, 6:13 PM UTC

csande17 wrote: post #239

giaour wrote: post #210

Earlier quoted context omitted.

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".

What happened to http prefetch or server push? Does anyone use those things?

Re: Browsers are pretty good at loading pages

#313

Post by gray_-_wolf » Mon, Jul 22, 2019, 6:33 PM UTC

manigandham wrote: post #231

bryanrasmussen wrote: post #223

Earlier quoted context omitted.

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

How can the download step be skipped then if you are using the hash of the content as a key??

Re: Browsers are pretty good at loading pages

#314

Post by bryanrasmussen » Mon, Jul 22, 2019, 7:10 PM UTC

repolfx wrote: post #311

TeMPOraL wrote: post #276

Earlier quoted context omitted.

Might be, but I wouldn't discounting culture as a mechanism reinforcing it. People aren't working in isolation; they build on each other, and enshrine "best practices" that are often enough the sources of these problems. But thinking of it, Sturgeon's law may be at play. PHP used to suffer from similar reputation to JavaScript, and only started regaining its status as a proper server choice once the masses moved to g…

PHP is considered a proper server choice these days? When did that happen? It's been a long time since I encountered a new project being written in PHP.

I don't do php but I assume any resurgence would have something to do with Laravel.

Re: Browsers are pretty good at loading pages

#315

Post by couchand » Mon, Jul 22, 2019, 7:20 PM UTC

StavrosK wrote: post #291

mikeash wrote: post #182

Earlier quoted context omitted.

Good: it detects when you’re offline and displays a fun error page. Bad: this only works on every other click. Half the time the links just silently fail....

For me, it always displays the "you're offline" page.

You just reminded me that slate.com frequently tells me I'm offline after clicking the back button.

Re: Browsers are pretty good at loading pages

#316

Post by IanCal » Mon, Jul 22, 2019, 7:40 PM UTC

nothrabannosir wrote: post #180

IanCal wrote: post #43

Earlier quoted context omitted.

There's definitely parts that are awkward though. I can't see the context of your comment in my reply as it's on a completely different page for example. HN has never really been a great UI though, it used to be a massive set of nested tables that didn't render properly on a mobile, it has some tiny fonts and hard to click buttons, and has unliked comments just less accessible by lowering contrast. It's good enough t…

Yet even this crucible of anti design is more usable than many a designer blessed SPA. Thus is the power of server side rendering.

It's better than many server side rendered pages, the things that work have nothing to do with where the rendering happens.

Re: Browsers are pretty good at loading pages

#317

Post by lnl » Mon, Jul 22, 2019, 8:03 PM UTC

bzbarsky wrote: post #310

lnl wrote: post #308

Earlier quoted context omitted.

As another lazy loading hater, I think that's a good thing. If a website wants to use lazy loading, it should be handled by the browser, rather than using a custom JavaScript code that the webpage requests. There being one universal method means that there is only one setting that I need to disable to avoid lazy loading. Currently I use a userscript based on heuristics to load all lazy-loading images, but it often do…

The NoScript point is a good one. I don't necessarily expect browsers that implement it to have a user-visible way to disable lazy loading, though, so you may be out of luck there. You _might_ be able to create userscripts that force non-lazy loading on all potentially-lazy elements by using the opt-out frob browsers would add for websites.

I would hope that Firefox would have an about:config setting to disable it, but with the direction they are going, removing customizability left and right, who knows. Normally I would have also expected addons to disable this browser-side lazy loading, but since Firefox 57 they are more like glorified userscripts, so they probably wouldn't be able to.

On Chromium side, maybe Vivaldi and the like could provide the option to disable it, if it is not too difficult of a change on Chromium. But for sure, I would be very surprised if Chrome offered that option, so not much of an improvement for Chrome users, or maybe even a deterioration if sites start to adopt it even more, now that it is supported natively.

Re: Browsers are pretty good at loading pages

#318

Post by TeMPOraL » Mon, Jul 22, 2019, 8:29 PM UTC

kilburn wrote: post #292

TeMPOraL wrote: post #252

Earlier quoted context omitted.

It's the same meta-problem, though: modern webdev practices involving adding gimmicks for no good reason that introduce extra complexity and resource use, and then adding even more complexity and resource use trying to fix all the expected behavior and features of browsers that the initial gimmick broke... and doing it poorly.

I hate all these gimmicks you are talking about (slow to load fonts, unnecessary videos, fucked up scrolling, spinners everywhere, etc.). That being said I challenge the assertion that they are used for no good reason. - Custom fonts are used because they help shape a brand. Properly used, the choice of fonts communicates a lot (at a subconscious level) about the company or person behind it. - Unnecessary videos unfo…

I agree; I cheated by purposefully using both meanings of "good". The reasons you mention I consider bad in ethical sense, and I believe the world would be better off if sites didn't do it.

Re: Browsers are pretty good at loading pages

#319

Post by AOsborn » Mon, Jul 22, 2019, 10:34 PM UTC

TeMPOraL wrote: post #102

frereubu wrote: post #98

Earlier quoted context omitted.

I hate infinite scroll with a passion. I've often been quite a way down someone's interesting Twitter feed and lost my place somehow, then just given up and gone somewhere else in frustration rather than trying to scroll down a few hundred tweets, waiting each however-many tweets for the next batch to load, just to get back to where I was.

Also the slowdown. Didn't matter whether I had 8, 12 or (currently) 32 GB of RAM; couple minutes scrolling down a Twitter or Facebook feed and the whole page slows down so noticeably that I simply give up. Also: something breaks, you press F5, and now the feed is gone, or is in a completely different place than it was before refresh. Infinite scroll should be labeled as dark pattern. Its only benefit is to the compan…

Funny. I agree with you that infinite scroll brings a bunch of UX issues.

But a dark pattern? Definitely not. I have had multiple projects this year where the feedback from UX workshops has overwhelmingly been to use infinite scroll. This is feedback from real users, customers, and clients.

We need to be careful to align the website UX to the correct target users. Are you building something for a very technical market or power users, such as software engineers? Sure, ensure you don't interfere with the experience.

However, if you're targetting business or social users, you need to base your decisions on their priorities. This means the optimal path for their primary use cases. This means optimizing for the 98% of the times the user just scrolls down the feed, not the 2% of the time they scroll a bit and refresh.

Re: Browsers are pretty good at loading pages

#320

Post by ComputerGuru » Mon, Jul 22, 2019, 11:56 PM UTC

kilburn wrote: post #292

TeMPOraL wrote: post #252

Earlier quoted context omitted.

It's the same meta-problem, though: modern webdev practices involving adding gimmicks for no good reason that introduce extra complexity and resource use, and then adding even more complexity and resource use trying to fix all the expected behavior and features of browsers that the initial gimmick broke... and doing it poorly.

I hate all these gimmicks you are talking about (slow to load fonts, unnecessary videos, fucked up scrolling, spinners everywhere, etc.). That being said I challenge the assertion that they are used for no good reason. - Custom fonts are used because they help shape a brand. Properly used, the choice of fonts communicates a lot (at a subconscious level) about the company or person behind it. - Unnecessary videos unfo…

This idea that users need to see all text on your website in a particular font face (which is usually just a poorly packaged riff off of a famous font with minor changes that will largely go unnoticed by the unwashed masses) in order to market your product is absolute BS. Aside from a very few iconic font associations (e.g. IBM), there's no actual evidence that it actually works.

I fully support using a custom font for your visual assets - that's what SVG with text exported as curves/outlines was created for. But why should I use your horribly hinted, terribly rendered, absolutely illegible webfont (and have to download it to boot) just to read the copy on your website? Why should anyone?

Look at Apple. Despite what I'm sure their design team tells them, even they don't have an iconic font. They've bounced around between Helvetica, Myriad, Lucida, and a half-dozen other sans serif fonts that share certain design traits (which people do identify and associate in general), yet each time they introduce a new font they update their website to trigger your browser to download the webfont to render the page. It's a pointless exercise in the name of job security.

Companies have had websites going back 30 years. Web fonts have existed for a long time. This trend of each company having to pay tens of thousands to commission an unrecognizable, undistinguishable typeface that all text on their website must appear in is a brand new phenomenon, and there's zero proof it does anything besides (poorly) accomplish what someone thought was a good idea.