You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the offline page is served and the browser cache is disabled (or the server is configured to not cache assets) the result is a broken page:
Granted, when sites are configured properly with the right Cache-Control headers for assets, this would not be the result. Nevertheless, it is not wise to rely on servers being properly configured.
To rectify this, all core/theme/plugin resources should have a default network-first caching strategy. This would include specifically the scripts, styles, and fonts being served from the site. It would also need to include the custom logo, header image(s), and background image. It should not include other uploaded images.
The approach taken can be to cache by default the scripts and styles as shown in the Basic Site Caching plugin:
// Cache theme assets with runtime network-first caching strategy. This includes both the parent theme and child theme.add_action(
'wp_front_service_worker',
function ( \WP_Service_Worker_Scripts$scripts ) {
$theme_directory_uri_patterns = [
preg_quote( trailingslashit( get_template_directory_uri() ), '/' ),
];
if ( get_template() !== get_stylesheet() ) {
$theme_directory_uri_patterns[] = preg_quote( trailingslashit( get_stylesheet_directory_uri() ), '/' );
}
$scripts->caching_routes()->register(
'^(' . implode( '|', $theme_directory_uri_patterns ) . ').*',
array(
'strategy' => \WP_Service_Worker_Caching_Routes::STRATEGY_NETWORK_FIRST,
'cacheName' => 'theme-assets',
'plugins' => array(
'expiration' => array(
'maxEntries' => 25, // Limit the cached entries to the number of files loaded over network, e.g. JS, CSS, and PNG.
),
),
)
);
}
);
It would also then need to loop over an array of specific theme images and add them to the runtime cache directly, as exemplified in the AMP plugin:
Or rather, each URL can be registered as a pattern for runtime caching that images which are never used won't be cached.
Note that this will make most of the “integrations” obsolete, as they rely on precaching to do the same. But precaching has drawbacks because resources are downloaded which are never used.
The text was updated successfully, but these errors were encountered:
While #338 will resolve this, I wonder if it would be better to prevent caching frontend pages for users that are logged-in. If someone is logged-in, it's more likely that they're going to always want to see the latest version of the page and not fall-back to something that was stored in cache. If they are served something from cache, they could be alarmed if they see old content.
When the offline page is served and the browser cache is disabled (or the server is configured to not cache assets) the result is a broken page:
Granted, when sites are configured properly with the right
Cache-Control
headers for assets, this would not be the result. Nevertheless, it is not wise to rely on servers being properly configured.To rectify this, all core/theme/plugin resources should have a default network-first caching strategy. This would include specifically the scripts, styles, and fonts being served from the site. It would also need to include the custom logo, header image(s), and background image. It should not include other uploaded images.
The approach taken can be to cache by default the scripts and styles as shown in the Basic Site Caching plugin:
It would also then need to loop over an array of specific theme images and add them to the runtime cache directly, as exemplified in the AMP plugin:
Or rather, each URL can be registered as a pattern for runtime caching that images which are never used won't be cached.
Note that this will make most of the “integrations” obsolete, as they rely on precaching to do the same. But precaching has drawbacks because resources are downloaded which are never used.
The text was updated successfully, but these errors were encountered: