4 ms·
Depending on how big your pages are and how fast they are generated preload is probably a better alternative. Instead of pushing the images just set headers fo
by kevincox 6y ago
Depending on how big your pages are and how fast they are generated preload is probably a better alternative.
Instead of pushing the images just set headers for the images above the fold:
Link: </img/1.jpg>; rel=preload; as=image
The browser will then request the images it doesn't have cached already.
The advantage to this method is that the browser can look up the images in its cache first and avoid transferring unnecessary data.
The downside is that it will take at least one round trip for the browser to request them. So if your HTML is short and quick to generate the connection might go idle before your receive these requests.
- kdunglas 6y agoActually you should use Link: </img/1.jpg>; rel=preload; as=image; nopush Or it's likely that the web server will transform this hint in a Server Push (it's supported out of the box by Apache, NGINX, CloudFlare...).
- kevincox 6y ago"should" is a strong word. If you have a very short and fast HTML page you might want to start pushing the assets just in case the user doesn't have them cached. But yet, the choice is yours. I wonder if the proxies would consider some sort of hybrid mode where they proactively fetch the link header and cache it (if it isn't already cached) but don't push it to the client. I can't find any indication that this has been implemented or considered anywhere. Of course if your edge was much closer to the user the the origin it wouldn't have much benefit. But it would still be nice.
- londons_explore 6y agoMy render target is 200 milliseconds for the first page load for the 80th percentile, so an extra round trip kills that. External resources via a preload seem to come to easily an extra 200ms, seemingly due to threading delays in Chrome more than the network latency.