Investigate alternatives to reloadOnInstall

[jeffposnick]

Using <platinum-sw-register reload-on-install> can be useful for informal integrations, as an alternative to generating a list of resources to precache. It means that as soon as the service worker is installed, the page will be reloaded, allowing a <platinum-sw-cache> element to perform runtime caching of all the resources needed on the page.

However, this forced reload can be jarring, especially since it happens at an indeterminate time (there's no guarantee about what's going to be displayed on the controlled page when the service worker finishes installing).

@slightlyoff suggested an alternative approach, in which the an instance of the controlled page is silently loaded in an <iframe> following the service worker installation, to trigger the same runtime caching.

@wibblymat has suggested trying to determine what's already been loaded on a page. I forget the exact method he proposed used, but he can probably clarify here. Poking around a bit, performance.getEntriesByType('resource').map(r => r.name) might be a good start.

[ebidel]

/sub

[jeffposnick]

I've played around with both approaches:

You can use performance.getEntriesByType('resource').map(r => r.name) to get the list of URLs, and then use postMessage() to tell the service worker to cache them or use window.caches directly. This feels like a cleaner approach.

Unfortunately, performance.getEntriesByType('resource') will only return an entry for a top-level HTML import, and if that top-level HTML import in turn imports other HTML files, those don't recorded anywhere. This normally wouldn't be a deal breaker (who uses nested HTML imports???) except that this is Polymer (we use nested HTML imports!!!). This strikes me as something that might be a bug in the Performance Timeline API, and I'll follow up on that out of band.

The alternative of adding a hidden <iframe> to the page appears to meet the requirements. It feels like as much of a hack as reloading the page, but it has the tangible benefit of not causing the interface to flicker.

Here's the code I tested with:

var iframe = document.createElement('iframe');
iframe.src = window.location;
iframe.hidden = true;
iframe.onload = function() {
  document.body.removeChild(this);
};
document.body.appendChild(iframe);

I'm going to hold off on submitting a PR just yet while I explore this further, but thanks for the suggestion, @slightlyoff!

[TalAter]

So you're basically calling and rendering the current page twice? Can't this cause many complications (besides the performance hit)?

For example:

• If I have Analytics on my page, each page view would count as two.
• If I have an AdWords conversion code to count how many people see my landing page, wouldn't I see two conversions?
• Won't optimizely now count iframe page views that never end up with any interactions, dropping my conversion rate by half immediately?

[wibblymat]

performance.getEntriesByType('resource') is exactly what I had in mind - I didn't realise it was limited in that way :(

[ebidel]

Here's the relevant Chromium bug: https://code.google.com/p/chromium/issues/detail?id=505279

@TalAter makes a good point about unwanted side effects with the iframe trick. <iframe>s are also slow on mobile and the Blink team has even talked about clocking down their FPS if they're hidden. We should probably avoid going that route and wait for the above bug to be fixed. I gave it a bump.