12 comments

[ 3.2 ms ] story [ 37.9 ms ] thread
> Rather than eagerly loading the react-scroll dependency for this, they load it on interaction with the button, saving ~7KB:

My apologies for being negative but isn't it crazy it takes 7KB to scroll to the top of the page?

Eh, you can always do `scrollTo(0, 0)` if you just want the scroll-to-top functionality at the expense of everything else.
But if you want a good user experience, you should really use `scrollTo({ top: 0, left: 0, behavior: 'smooth' })`

Smooth scrolling in 42B (minified, not gzipped) rather than 7KB, and supported by 85% of users' browsers (source for that number: https://caniuse.com/mdn-api_scrolltooptions)

Yeah, that's a good option if you're ok with not-100% browser compatibility.
Modern browsers support `scrollTo(options)` that allows you to do it with a single line. For slightly older browsers, such as later IE releases, you need to try-catch that and use `scrollTo(x, y)`. And for older browsers still, not-the-latest IE, Opera mobile, that's the rest of the 7KB — polyfills, hacks, wrappers and more. Shortly, for browsers that don't have an animation API nor a proper scrolling API. It may be disproportionate, but for sites that want to target readers all around the world, on all devices, it can be a sensible tradeoff.
In this case better solution would be to use this single line (which works for >80% of clients) with try-catch in core and maybe load polyfills from exception handler via "bloat dispatcher".
It's not just browser support right it's however they wrapped it up to make it more compatible with react
Funny how we keep coming back full circle. A common optimization trick back in the day was to use pjax/turbolinks to achieve exactly this pattern. You could even go one step further and start loading on mouseover, rather than on click, giving you upwards of a one second head start.
Good advice. But really why do you need 500k extra javascript to play a video?
Please don't - too many times have I loaded a number of tabs containing medium posts before stepping on a flight with no wifi and only then discovering that images a page down are not visible.

It's fine to not load everything immediately, but load the page and then start loading all the resources, but don't wait until I scroll to the right place!

I'm in two minds about this.

In favour: TTI and similar metrics are really important, not just for SEO but because Google and friends base these metrics off actual user behaviour: if your page takes to long to load, users will go elsewhere. Lazy-loading for features that are rarely used (and you've actually done the analytics to justify this) can be a valid trade-off.

Against: this behaviour in some form has made it even into Microsoft Word. Click the "select font" dropdown and it can freeze for a couple of seconds to create the list, especially if you have a big document open. The same, if you're unlucky, for the styles dropdown, the "insert special character" button because it insists on showing you the most-recently-used ones in a menu it has to build on click (as well as in the dialog box), and a few other places.

I expect better than this from a desktop application, especially as I remember these things being almost instant back around WinXP days. Sure it didn't come with Bing integration, but I can live without that.

And web sites and applications should aim to emulate the responsiveness that we used to have on the desktop.

Back then we used to have index.js, chat.js, checkout.js, and so on.. even your grandma’s website had free “code splitting” and “dynamic imports”!