4 ms·
I apologize if someone already mentioned this, but there's a way to eliminate the penalty to the user without changing HTTP at all. Browsers can simply check al
by eloff 11y ago
I apologize if someone already mentioned this, but there's a way to eliminate the penalty to the user without changing HTTP at all. Browsers can simply check all the non-expired resources after all the rest. Now the latency is the same, but we still do the checks, just after everything else and we're already rendering the page. Only if one of those resources did actually change then we re-render the page.
The immutable solution is cleaner, and doesn't load the server as much, but it's not backward compatible and requires the people who run the server to know what they're doing. Maybe the two solutions could be combined?
The biggest potential drawback I see is that maybe most resources, including the html don't expire, so every page will be rendered and re-rendered. Giving little benefit and making the rendering choppier. Some of that maybe could be mitigated by starting the rendering in the background and not displaying it until a certain percentage of requests return, or special casing the "page" itself as opposed to page resources.
- mediumdeviation 11y agoWhat you're suggesting won't work. The problem is that a lot of pages require their resources to be loaded in a specific order. The C in CSS stands for cascading, and means that rules that are loaded later override earlier ones (if selector specificity match). The same goes for JS since later scripts might depend on the framework or libraries loaded in earlier, unless the script has the async attribute. And then there are the content which are loaded by the CSS and JS themselves, which in most modern web apps make up the majority of the content.
- eloff 11y agoNonsense. You have the css and javascripts. You just aren't certain that they're the most recent version. So you go ahead and render the page using either the version you have, or requesting it from the server, still doing everything in order. Then you validate your assumptions in the background about the stale versions you used still being the most current. If your assumptions are right (and mostly they will be) nothing happens. If they're wrong, you re-render the page, again all in order.
- deleted 11y ago[deleted]
- jasonkester 11y agoSense. It makes a difference if you run an old javascript file before loading its new replacement and running that. As in, Original script: <script> location.href="http://google.com"; </script> New script <script> // oops! forgot to remove this // location.href="http://google.com"; </script> You'll want to make sure you have the right version in place before you try to run either of them.
- eloff 11y agoYou have a point. What about CSS? At first I think it would just render funny, but some javascript actually interacts with the CSS, e.g. jQuery selectors based on style classes or something. So it has the same problem really. Images would be safe. Or an alternate plan, start rendering, but do not run the javascript until the resource checks for css+js files return. It would slow things down some more, but not as much as waiting for everything.
- jasonkester 11y agoBefore: body { background:blue; } After: body {} It would play out similar to the Flash of Unstyled Content issue, but substituting "unpredictably wacky" for "unstyled".