On Tue, Aug 12, 2014 at 4:18 PM, Karl Dubost <kdub...@mozilla.com> wrote: > Jonas, > thanks for the explanations so far. It helps a lot to understand and sorry > for the naive questions. There is still something I do not get: > > Le 13 août 2014 à 07:17, Jonas Sicking <jo...@sicking.cc> a écrit : >> It would be much more practically doable for calendar instead to >> prerender a blank search result page, and then once the user commits >> the search tell that prerendered page what the search parameters are >> such that the page can load and render the appropriate search data. > > Here you seem to talk about partial rendering. > I thought pre-render features were here to enable to show instantly a page > when the user decides to follow a link. Aka the page is just ready to be > shown.
The goal of prerender is to improve performance when navigating to a new page. Right now it does so really well if the initial page is able to correctly guess which URL the user will navigate to. But it does so really poorly (i.e. not at all) if it guesses even slightly wrong. Of course it's great if we can get the new page to render immediately. But just because we can't get the new page to render immediately doesn't mean that we don't care about loading the new page as fast as possible anyway. > Here in your explanation you seem to say that the DOM is partially built but > the painting is not done or at least has to be redone before displaying the > page. Do we lose part of the benefits by doing that? Or maybe a more > appropriate question is what is the gain in between a prefetch and a > prerender in this case? I'm not talking about doing some form of partial parsing or partial rendering. I'm talking about doing a full rendering of a "template page". I.e. a normal webpage which the website can then use JavaScript to mutate into the page that the user wanted to navigate to. So for example when viewing a bugzilla search result, bugzilla could request to prerender the URL "http://bugzilla.mozilla.org/show_bug.cgi?justLoadTemplate=1";. When this URL is loaded, bugzilla would return a page which contains the same markup, the same CSS and the same JS as normal bug pages. But which lacks any bug-specific data. The browser would load this URL, just like any other. It would parse all the markup, load all the CSS, JS and images that the page needs, it would run any JS just like normal, and it would apply CSS just like any other page. When the user then clicks a link on the bugzilla search result page, the search result page would use a click event listener and send a message to the prerendered page letting it know that the user just clicked the link for bug 123456. The prerendered page would then use replaceState to change its URL to http://bugzilla.mozilla.org/show_bug.cgi?id=123456. It would also fire off an XHR request to fetch a JSON formatted description of all data about bug 123456. Including bug title, bug dependencies, list of attachment names and types and all bug comments. Since the prerendered page's URL now match the URL of the page that the user wanted to navigate to, the UA would decide to display the prerendered page rather than load a new page. This would immediately display the "template page" that was initially loaded. If the template page still hasn't finished its XHR request (which is likely given that switching to the prerendered page can be made very quick), that means that the user will now see a page without the bug data. However this still looks like progress to the user, and very quick progress. And the XHR request will very likely finish loading much faster than it would have taken to load+process all the resources that we currently load when the user clicks a bug link in the search results. I hope that makes it more clear. So very little of this is handled by the UA. I.e. no magic partial parsing, and no magic understanding of what parts of the template page is headers vs. which parts will be filled in later. > Another thought: > There is something very similar in between prefetch, prerender and the old > next/prev values. That could revive those. > <link rel='next' href=''/> > <link rel='prev' href=''/> That could be, but I don't see how these could help in the scenarios I've described in this thread? / Jonas _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
