Prefetch a list of URLs

By prefetched do you mean “precached“?

Yes, sorry, there is the rel=prefetch thing I was looking into, so I posted that way.

You can see documentation for this in the wiki under Route Caching API. In particular, here’s how you would precache an image:

<?php
add_action( 'wp_front_service_worker', function( \WP_Service_Worker_Scripts $scripts ) {
	$scripts->precaching_routes()->register(
		'https://example.com/wp-content/themes/my-theme/my-theme-image.png',
		array(
			'revision' => get_bloginfo( 'version' ),
		)
	);
} );

You can duplicate that register call as, any times as you need.

Thanks, that seems to work, but this theme, even if add all the pages, there is a ton of javascript, css and the likes, which won’t precache.
I’ve seen some mentions of preloading all the navigation links with a filter or an action, any suggestion on that?

Really I don’t recommend using the precache in general and to instead rely on the runtime cache. In this way, you’ll only cache what you actually use. Consider the case of an image on a page: when precaching, you’d have to precache all of the sizes of the image because you don’t know which size the client will render. Nevertheless, with runtime cache only the actual image size that the client fetches will get cached. The one downside of precache is that it currently requires navigating to a second page after first installing the service worker to then cause them to be cached. However, there is a way around this. Namely, upon activation of the service worker, it is possible to send a list of the resources loaded on the page to then be added to the runtime cache.

But isn’t that link an example of using serviceWorker.js, which shouldn’t be done if using your plugin?
This is a really small site, and there shouldn’t be more than 12 pages in a precache list.

@westonruter, What I meant is whether using that Workbox example from your last post here is a discouraged practice in that it will interfere with your and/or other PWA plugins and themes?

• This reply was modified 1 year, 7 months ago by vaniivan.

I don’t mean to use that code verbatim but rather to use the approach with the PWA plugin. I’ll see if I can put together an example.

Here’s an extension plugin that adds initially-downloaded resources to the runtime cache upon service worker activation: https://gist.github.com/westonruter/3beda9d304c02712cbb0f01ba06aa5b2

Note you have to have “offline browsing” enabled in the Reading settings of the WordPress admin.

Note that it does not include the initially-visited page to the list of URLs that are added to the runtime cache. To support that, the plugin would have to be modified. I’ve opened an enhancement issue for that: https://github.com/GoogleChromeLabs/pwa-wp/issues/937

Thanks, but this does not solve caching all the pages in navigation menu on this site? The list of URL-s won’t make the Workbox automatically fetch the related resources for those pages? I’d like for the client of this shuttle transfer company to have access to the company contact data, as soon as he adds the page to the home screen of this phone.
I know it’s easier to give the visit card, but if it’s possible, I’d like to cover this route too.
I was thinking about adding a hidden iframe, though that seems more like an oil spill.

• This reply was modified 1 year, 7 months ago by vaniivan.

For caching other pages in your navigation along with all resources they depend on, there isn’t a way to do that cleanly without resorting to an iframe. This is because the browser actually has to render the page to discover the dependent assets. You could adapt my plugin to listen for the activated event and then loop over each navigation link one-by-one, putting the URL into an iframe, and then once it loads, destroy the iframe and load up the next URL.

• This reply was modified 1 year, 7 months ago by Weston Ruter.