Broken link to https://hpbn.co/chrome-networking

[billmei]

Steps to reproduce:

1. On this page: https://hpbn.co/primer-on-web-performance/#browser-optimization

2. Scroll down to where it says

For a deep dive into how these and other networking optimizations are implemented in Google Chrome, see High Performance Networking in Google Chrome

3. Click on the link High Performance Networking in Google Chrome

4. You'll see that the link returns a 404

[golonzovsky]

Possible target is https://www.igvita.com/posa/high-performance-networking-in-google-chrome/.
Maybe it is intended to be moved under hpbn.co

[igrigorik]

Thanks for reporting this. I started digging into it but haven't resolved the root issue.. The redirects themselves work fine, the issue is the serviceworker code provided by sw-precache. Stay tuned.

[jeffposnick]

Can you try removing navigateFallback from your sw-precache configuration?

navigateFallback is useful mainly for SPA-style apps, where you might have a lot of URLs that don't actually correspond to real HTML documents, but you still want to allow users to navigate to them.

I guess it could also be used to serve an offline 404 page, which I believe is your intention, but it will also serve the 404 page whenever there's a navigation request made for a HTML document that's not in the list of files that sw-precache manages. It doesn't look like there's a chrome_networking.html in your sw-precache assets list (since it's a redirect to another site).

(In our newer set of SW libraries, we're being a bit more explicit about the use case by exposing the same functionality in a NavigationRoute class.)

[igrigorik]

@jeffposnick thanks for the tip! Removed navigateFallback from config... same issue. =/

In generated SW file I see..

230     var navigateFallback = '';
231     if (!shouldRespond &&
232         navigateFallback &&
233         (event.request.mode === 'navigate') &&
234         isPathWhitelisted([], event.request.url)) {
235       url = new URL(navigateFallback, self.location).toString();
236       shouldRespond = urlsToCacheKeys.has(url);
237     }

[jeffposnick]

I'm not seeing an update to your service-worker.js file deployed to your site. It's possible that CloudFlare's caching is getting in the way:

https://hpbn.co/service-worker.js

The way that the browser cache interacts with the a service worker JavaScript file is weird; there's more info at https://stackoverflow.com/questions/38843970/service-worker-javascript-update-frequency-every-24-hours/38854905#38854905 but I'd recommend just exempting your service-worker.js file from browser (and proxy server) caching entirely.

[igrigorik]

</facepalm>

@jeffposnick you, sir, are awesome. Indeed that was the issue and the redirects seems to work now. Thanks for helping track this down.

@kortaggio @golonzovsky you may need to hard-reload to refresh the SW. Please reopen if the issue persists, or if you find any other gotchas.