- From: <bizzbyster@gmail.com>
- Date: Wed, 13 Aug 2014 13:57:12 -0400
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Yoav Weiss <yoav@yoav.ws>, Ilya Grigorik <igrigorik@google.com>, public-web-perf <public-web-perf@w3.org>
>> Wouldn't we be able to get most of the benefits of what you're suggesting by >> <link rel=prerender>ing the common subresources of these target pages? >> Also, if you split the common HTML parts of these pages into HTML imports, >> you can prerender them as well. > > Not really. You wouldn't have any JS libraries executed, and it's hard > to meaningfully process a CSS file without a DOM to apply it to. Maybe the better answer is “it depends”. If you are operating over a high latency network, then most of the benefit is in fetching resources early over the network. Peter On Aug 13, 2014, at 12:59 PM, Jonas Sicking <jonas@sicking.cc> wrote: > On Wed, Aug 13, 2014 at 1:05 AM, Yoav Weiss <yoav@yoav.ws> wrote: >> >> >> >> On Tue, Aug 12, 2014 at 1:33 PM, Jonas Sicking <jonas@sicking.cc> wrote: >>> >>> On Tue, Jul 8, 2014 at 10:35 AM, Ilya Grigorik <igrigorik@google.com> >>> wrote: >>>> First run at the spec based on previous discussions [1] and feedback: >>>> https://igrigorik.github.io/resource-hints/ >>> >>> Hi Ilya, >>> >>> I haven't read through the spec yet, so apologies if this is something >>> that's already addressed. I'll try to find time to look through the >>> spec in a not too distant future since I'm very interested in seeing >>> the web gain this capability in a cross-browser way. >>> >>> In the meantime, I'd like to mention a use-case we've come across as >>> we've looked at prerendering in Firefox and FirefoxOS. >>> >>> The way that prerender has traditionally been used is to enable a >>> webpage to load and render a URL that the page thinks it's likely that >>> the user is going to navigate to next. >>> >>> This fits well for situations like the google search results page, or >>> a multi-page news article, where there's a good chance that the page >>> can guess where the user is going next. >>> >>> However for something like a bugzilla search results page, there's >>> both problems and opportunities to improve. Consider the page at >>> >>> https://bugzilla.mozilla.org/buglist.cgi?quicksearch=preload >>> >>> This is a page containing a large list links to "bug pages". Each "bug >>> page" looks very similar, but has a different URL and contains >>> information about a different bug. It's going to be very hard to guess >>> which link the user is going to click, and even if we developed some >>> good heuristics about which link is most likely to be clicked, many >>> times that guess will be wrong. >>> >>> However, in almost all cases the user will click one of the links to a >>> bug page. And all bug pages share a lot of common UI elements. I.e. >>> each bug page has the same header and footer, and uses the same >>> stylesheets, JS and images. >>> >>> It would be great if we could here enable prerendering of the common >>> parts of the various bug pages. So that only the bug specific data >>> needs to be loaded and inserted into a prerendered page when the user >>> clicks the link for a bug. >>> >>> This can actually be accomplished fairly easily. Two options for how >>> to solve this are: >>> >>> 1. Enable a page which contains a <link rel=prerender> to open a >>> postMessage based communication channel with the prerendered page. >>> Also define that if the prerendered page uses replaceState to change >>> it's URL, the prerendered page is used if the user navigates to a URL >>> which matches the new URL, rather than the URL appearing in the <link >>> rel=prerender> >>> 2. Enable a prerendered page to declare a URL pattern which it >>> "captures". So that if the user navigates from the original page to >>> any URL which matches the URL pattern, the prerendered page is used. >>> >>> I like the first solution better since it's more flexible. And it >>> allows things like enabling the search results page to tell the bug >>> page to start loading data for the relevant bug as soon as the user >>> hovers a link, before the link is clicked. >> >> >> Hi Jonas, >> >> Wouldn't we be able to get most of the benefits of what you're suggesting by >> <link rel=prerender>ing the common subresources of these target pages? >> Also, if you split the common HTML parts of these pages into HTML imports, >> you can prerender them as well. > > Not really. You wouldn't have any JS libraries executed, and it's hard > to meaningfully process a CSS file without a DOM to apply it to. > > / Jonas >
Received on Wednesday, 13 August 2014 17:57:49 UTC