(Этот ответ не относится к Workbox, хотя Workbox упрощает использование этих стратегий, вместо того, чтобы «свернуть их вручную».)
Я бы рекомендовал использовать стратегию с кэшированием, если вы уверены, что содержимое по указанному URL-адресу не изменится. Если вы уверены в этом, то дополнительный сетевой запрос, сделанный в стратегии устаревшего подтверждения, является пустой тратой - зачем беспокоиться об этих издержках?
Сценарии, в которых вы должны иметь наибольшую уверенность в том, что содержимое URL-адреса не изменится, - это если URL-адрес содержит некоторую информацию о версиях (например, https://example.com/librbaries/v1.0.0/index.js) или хэш базового содержимого (например, https://example.com/libraries/index.abcd1234.js). ).
Иногда может иметь смысл использовать стратегию, основанную на кэше, когда ресурс может обновляться, но ваши пользователи вряд ли будут "заботиться" об обновлении и о том, как высока стоимость получения этого обновления. Например, вы можете утверждать, что использование стратегии кэширования в первую очередь для изображений, используемых в теле статьи, является разумным компромиссом, даже если URL-адреса изображений явно не имеют версий. Просмотр устаревшего изображения может быть не самым страшным, и вы не заставите своих пользователей загружать потенциально большое изображение на этапе повторной проверки.