You can push no-cache and no-store resources Use user-agent sniffing to avoid pushing resources to Safari users.
Safari's behaviour doesn't appear to be deterministic, so it isn't something you can hack around. If that isn't possible for whatever reason, it's probably safer to avoiding pushing anything to Edge users. You could use user-agent sniffing to ensure you only push resources you know it'll use. If the browser won't retrieve the item from the push cache, you'll end up being slower than if you hadn't pushed it at all.Įdge's support is poor, but at least it's consistently poor. The network panel will tell you which items have been fetched from the push cache. Unfortunately, Chrome is the only browser with devtools support. This means you only get a cache hit if the request is lucky enough to use same connection – but it's really above my brain-grade ( issue, including video).Īll browsers (except Safari when it's being weird) will use matching pushed items even if they're still in-progress of being pushed. It seems like it opens too many connections and pushed items end up being distributed between them. Safari defers to OSX's network stack, which is closed-source, but I think some of the bugs are in Safari-land. When it will/won't use the push cache seems like a flip of a coin.
The fairly scrappy test suite is on github.Įdge didn't retrieve the item from the push cache when using fetch(), XMLHttpRequest, or ( issue, including video). I also slowed the delivery of the body of the pushed resources to see if browsers would match items that were still being pushed. I gave this a spin by pushing resources and trying to collect them with: The key to it being useful is consistency and predictability. HTTP/2 push is a low-level networking feature – anything that uses the networking stack can make use of it. This is pretty much all I knew about HTTP/2 push for years, and it sounded relatively simple, but the devil is in the details… Anything can use the push cache
In theory, this means the page loads faster. You get a performance boost because you start sending the resources without waiting for the browser to ask for them. They sit in a cache until the browser asks for a resource that matches its description.
#High end stash box how to
This includes a set of request headers, so the browser knows how to match it up later. When the server responds to a request it can include additional resources. I'm just reading the HTML here, and it looks like I'm going to need a stylesh… oh it's the one you're already sending me, cool! Sure thing! Oh, but while I'm sending you that, here's a stylesheet, some images, some JavaScript, and some JSON. If that's the case, sorry! Hopefully the next few sections will help. The above is probably like those flow diagrams people use to try and explain Git or observables – they're reassuring to someone who already knows the thing, but terrifying to others.
#High end stash box series
Map of fetchingīetween your page and the destination server there's a series of caches & things that can intercept the request: Service worker HTTP cache Server Page Image cache Preload cache Page Image cache Preload cache Push cache HTTP/2 connection Push cache HTTP/2 connection This isn't an "HTTP/2 push is a douchebag" hatchet job – I think HTTP/2 push is really powerful and will improve over time, but I no longer think it's a silver bullet from a golden gun. HTTP/2 push is more complicated and low-level than I initially thought, but what really caught me off-guard is how inconsistent it is between browsers – I'd assumed it was a done deal & totally ready for production.
"HTTP/2 push will solve that" is something I've heard a lot when it comes to page load performance problems, but I didn't know much about it, so I decided to dig in.
0 kommentar(er)
