Hacker News new | ask | show | jobs
by adorable 3165 days ago
Some of those optimizations become irrelevant (or downright bad) with http2. Inlining CSS ans JS is no longer best practice when you can do a server push of those and avoid sending the extra bytes once the files have been cached by the browser.

Some optimizations can backfire. Adding async to the external JS is a great tip.. unless you have dependencies between your different scripts (i.e. you need one to be loaded before the other one gets executed)

4 comments

Relevant to http2 push but slightly off topic, I love how I can add a single line of code to my Django project (to include a middleware library I wrote) to have automatic http2 push. The middleware will parse the static media on the page and push them to the client, it's much faster with no effort.

The library is at https://github.com/skorokithakis/django-cloudflare-push if anyone wants to use it. It's slightly misnamed, as it supports any server that uses the Link header for push, not just CloudFlare.

Doesn‘t that mean I‘ll get all assets pushed to my client every time I visit any page of your site, regardless of the file‘s cache status?

That does not seem to be a good tradeoff, especially on mobile.

No, the browser cancels the download if it has the assets before they download.
That should take approximately as long as a client<->server ping, right? So shouldn't it be irrelevant for JS/CSS that loads within that time (say, 50Mbps & 15ms ping --> everything below 93KB gzipped?)
Yes, you'd download some things you don't need to. Last I heard, they're working on an extension so the browser can tell the server what media it has when it requests the initial page so they won't get sent at all.
You could use a cookie which contains the revision and then the server could selectively push things which have changed since then.
Unfortunately it doesn't. There is no mechanism right now for the browser to cancel the pushed resources. H2 Push's Cache Digest will introduce this ability, but it's still being designed.
Are you sure? SO seems to disagree:

https://stackoverflow.com/questions/29352282/does-the-browse...

And this feature shows as merged into ff56:

https://bugzilla.mozilla.org/show_bug.cgi?id=1367551

Cache digests are about the client telling the server what items it has cached so push doesn't even start, not about canceling pushes.

You might better be working on caching so that the resources are loaded only the first time. Otherwise you need some way to know whether the user has the resources cached or not (a cookie maybe?).
Definitely both true. I hadn't looked into enabling http2 on this site, I'll check it out.
Asynchronous JS scripts are a great choice. But you better makes this choice on early stage, because changing scripts from sync to async on a large legacy website can require a lot of time, there will be many bugs etc. You cannot just add "async" attribute.
That's something that really astounds me with this async thing.

Why on earth when they introduced it they didn't add a way to tell the browser the order of execution ? Or may be it exists and I haven't heard about it ?

There is a way: ES6 modules. If you can account for the order of execution (with modules or custom loaders) async is, in almost all cases, the best way to load your scripts. Defer (or body-end) scripts also specify the execution order, but only in a strictly linear fashion which usually has a performance hit.
But there is, it's called defer?!
You also need to hide JS controls before the scripts are loaded or you will get "dead" buttons that are visible but don't react to clicks.