Ограничения на размер кэша в разных браузерах

Библиотека Sw-precache обеспечивает автоматическое создание сервис-воркеров для предзагрузки ресурсов и их кэширования, что значительно ускоряет работу веб-приложений в оффлайн-режиме. Однако эффективность использования кэша напрямую зависит от ограничений, накладываемых различными браузерами на размер локального хранилища.

Общие принципы ограничения кэша

Современные браузеры используют IndexedDB или Cache Storage API для хранения ресурсов, закэшированных сервис-воркером. Основные факторы, влияющие на лимиты кэша:

  • Общий размер доступного хранилища. Обычно выражается в мегабайтах и определяется процентом от свободного места на устройстве.
  • Тип устройства. На мобильных устройствах лимиты значительно ниже, чем на десктопах.
  • Приоритет приложений. Некоторые браузеры уменьшают выделенный размер для «фоново» установленных веб-приложений.
  • Политики очистки. При нехватке свободного места браузер может автоматически удалять старые кэшированные данные.

Лимиты кэша по браузерам

Chrome и Chromium-based браузеры
  • Лимит для Cache Storage API составляет приблизительно 6% от свободного места на диске, но не более 1 ГБ на одно веб-приложение.
  • При превышении лимита браузер вызывает ошибку QuotaExceededError.
  • При использовании service worker с sw-precache рекомендуется разбивать большие файлы на части или использовать стратегию lazy caching, чтобы избежать резкого превышения лимита.
Firefox
  • Для Cache API Firefox использует IndexedDB под капотом, лимит определяется как 50% свободного пространства на диске, но максимальная выделенная квота редко превышает 2 ГБ.
  • Если размер кэша достигает лимита, новые ресурсы не кэшируются, но старые остаются, что требует периодической очистки устаревших файлов через sw-precache конфигурацию navigateFallbackWhitelist или стратегию очистки старых версий.
Safari
  • На iOS Safari лимит для Cache API крайне ограничен: примерно 50 МБ на одно приложение.
  • На macOS Safari допускает более крупные кэши, но лимиты зависят от общего свободного места и политики браузера.
  • При превышении лимита Safari просто прекращает запись новых ресурсов, не выдавая предупреждений пользователю. Это делает контроль размеров кэша критически важным при использовании sw-precache.
Edge
  • Старые версии Edge Legacy имели лимит около 250 МБ, в новых Edge (Chromium-based) применяется аналогичная политика, как у Chrome, с лимитом около 1 ГБ.
  • Особенность Chromium-Edge — агрессивная очистка кэша при нехватке места, что требует дополнительного мониторинга через события service worker.

Стратегии управления кэшем в sw-precache

  1. Использование maximumFileSizeToCacheInBytes Позволяет ограничить размер отдельных файлов для кэширования, предотвращая превышение лимита браузера.

    swPrecache.write('service-worker.js', {
  staticFileGlobs: ['dist/**/*.{js,css,html,png,jpg}'],
  maximumFileSizeToCacheInBytes: 5 * 1024 * 1024 // 5 МБ
});

  2. Разделение ресурсов на несколько кэшей Для больших приложений можно создавать отдельные кэши для JavaScript, CSS, изображений. Это помогает контролировать нагрузку на общий лимит и облегчает очистку устаревших ресурсов.

  3. Очистка устаревших версий кэша Использование событий activate и self.caches.keys() позволяет удалять старые кэши, освобождая место для новых ресурсов.

    self.addEventListener('activate', event => {
  const cacheWhitelist = ['my-app-cache-v2'];
  event.waitUntil(
    caches.keys().then(cacheNames =>
      Promise.all(
        cacheNames.map(cacheName => {
          if (!cacheWhitelist.includes(cacheName)) {
            return caches.delete(cacheName);
          }
        })
      )
    )
  );
});

  4. Ленивая загрузка ресурсов (runtime caching) Вместо кэширования всех ресурсов сразу, можно загружать их по мере необходимости. Sw-precache поддерживает стратегию runtimeCaching, которая снижает вероятность превышения лимита.

Мониторинг и тестирование кэша

  • Проверка фактического размера кэша выполняется через DevTools → Application → Cache Storage.
  • Для аналитики рекомендуется логировать события install и activate, отслеживая успешность кэширования.
  • Тестирование на мобильных устройствах критично, поскольку ограничения там более жесткие.

Практические рекомендации

  • Не кэшировать большие медиафайлы без разделения.
  • Регулярно обновлять версии кэша, чтобы старые ресурсы автоматически удалялись.
  • Настраивать maximumFileSizeToCacheInBytes с учетом самого жесткого лимита среди целевых браузеров.
  • Использовать ленивое кэширование для редко используемых ресурсов.
  • Планировать стратегию fallback для ресурсов, которые могут не попасть в кэш из-за превышения лимита.

Эти подходы позволяют поддерживать надежную работу сервис-воркера в условиях ограничений на кэш разных браузеров, обеспечивая баланс между оффлайн-доступом и эффективным использованием хранилища.

Оглавление