On Mon, Aug 11, 2014 at 5:16 PM, Karl Dubost <kdub...@mozilla.com> wrote: > Jonas, > > Le 12 août 2014 à 08:33, Jonas Sicking <jo...@sicking.cc> a écrit : >> However in some cases we can do better than that by loading a template >> page that can be used for multiple of the search results. > > This I'm not sure to understand how that would be working. Let's say be any > page on the Web. How do you know in advance the template for the page? I > might have missed something.
I think we are indeed talking past each other. The goal of the prerendering API is to enable a webpage to include something like <link rel=prerender url="http://somewebsite.com/page.html";> This would tell the UA to load the above URL, as well as any resources that is required to render the resulting page, and construct the DOM and layout datastructures which are needed to display the page. All of this is done in the hope that if the user navigates to http://somewebsite.com/page.html, the UA can detect that a prerendering has already been created and then display that page *really* quickly. This feature is useful in many scenarios. It's useful for the google search page because they can use the above markup to point to whatever search result they think the user is going to navigate to. It's useful in a news article to point to the next page of the article. It's useful for reddit because it can preload whatever link they think the user is likely to click. However, as the feature stands today, it can't be used by for example the bugzilla search page. After a user visits the bugzilla search page, they almost always visit the search results page. However the exact URL of the search results page vary greatly since it depends on the search parameters that were entered. So the search page couldn't add a <link rel=prerender> in order to prerender anything, since it would have no idea what URL to stick in there. This despite the fact that whichever search result page URL is loaded, there are a lot of common parts. There's a common header and footer, the same CSS files and JS files need to be loaded. The same styles are applied to largely the same set of elements. Wouldn't it be great if those pieces could be preloaded and prerendered, such that the only thing that had to be loaded and rendered once the user pressed the "search" button was the actual search results. In this case the prerendered search results page acts as a "template page" for any search result page that ends up being loaded. Of course, if the user ends up not doing a search at all, then we'll have to drop that prerendered page and instead do a new load from scratch. Just like with any mispredicted <link rel=prerender>. Similarly, the bugzilla search result page can't currently take advantage of the prerender feature. Even though it's very likely that the user is going to click a link to a bug, and even though all bug pages share large parts of their resources and layout, there is no way for the bugzilla search result page to load and prerender those common parts. Wouldn't it be great if the search result page could ask a generic bug page to be loaded, such that if the user clicks a bug link, we could just load the data that's specific to the clicked bug and insert that data into the generic bug page. I.e. the generic bug page would act as a template page for any bug page. Of course, if the user doesn't find any of the search results interesting, and goes somewhere different than a bug page, then the prerendering was for naught and we will have to do a new load from scratch. I think the solution to these problems consist of two parts: 1. Make it possible for a page that contains a <link rel=prerender> to initiate a postMessage-based conversation with the prerendered page. 2. Define that the prerendered page is used if the navigation destination URL matches the prerendered page's URL (which can be modified using replaceState), rather than if the URL in the <link rel=prerender>. Redirects might make this a bit more complicated. This way we can even do such things as tell the prerendered page to start loading search results, using an XHR request, even before the user has actually clicked "search". And update those search results any time the user modifies any search parameters. If the user ends up modifying the search parameters those results can simply be thrown away without ever getting used, while still allowing the prerendered search results template page to be used no matter which search ends up being the final one. Similarly the bugzilla serach results page could ask the prerendered bug page to start preloading the relevant bug data as soon as a bug link is hovered. Again, if the user ends up clicking something else, the data can be thrown out and the correct data can be loaded. All of this would be driven by webpage logic. The only part the platform would provide is the prerendering feature and the two additions listed above. / Jonas _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
