{"id":73405,"date":"2025-07-25T15:51:29","date_gmt":"2025-07-25T10:21:29","guid":{"rendered":"https:\/\/www.tothenew.com\/blog\/?p=73405"},"modified":"2025-07-30T13:20:39","modified_gmt":"2025-07-30T07:50:39","slug":"understanding-service-worker-caching","status":"publish","type":"post","link":"https:\/\/www.tothenew.com\/blog\/understanding-service-worker-caching\/","title":{"rendered":"Understanding service worker caching"},"content":{"rendered":"

Introduction<\/h2>\n

We often hear about service workers in the context of caching techniques, their importance in PWAs, and overall optimization. They enable us to create offline experiences within websites or applications, perform background sync activities, and create push notifications, among other features.<\/p>\n

\"Understanding

Understanding Service Worker Caching<\/p><\/div>\n

Let us understand what service worker is and how to implement it in websites or applications.<\/p>\n

What is a Service Worker?<\/h3>\n

According to the official definition, Service Worker is as a proxy server that sits between browser and the network layer. It intercepts network requests, can take action based on network availability, updating assets according to the requirement.<\/p>\n

A service worker is basically a JavaScript code that runs on a separate thread in the background, without disturbing the main thread. It captures network requests, can do some operation, and provide caching and offline functionality. It acts as a middleman between the browser and the server.<\/p>\n

Key features<\/h3>\n
    \n
  • To prevent man-in-the-middle attacks, Service workers run only on HTTPS protocol and not HTTP.<\/li>\n
  • They are event-driven workers, based on an event-based architecture.<\/li>\n
  • A service worker does not have access to the DOM or Web APIs.<\/li>\n
  • It is registered against a specific origin and path.<\/li>\n
  • Not every browser supports service workers, so compatibility must be checked.<\/li>\n<\/ul>\n

    How Does Service Worker Caching Work?<\/h3>\n
      \n
    • The service worker intercepts requests made by the page.<\/li>\n
    • It checks the cache for the requested asset.<\/li>\n
    • If the asset is available, it is served to the page from the cache, without making a network call.<\/li>\n
    • If the asset is not available, a network call is made to fetch it.<\/li>\n
    • Once the asset is fetched, it is saved in the cache and served to the page.<\/li>\n<\/ul>\n
      \"Service

      Service Worker Workflow<\/p><\/div>\n

      How to implement a Service Worker?<\/h3>\n

      To start with, we are fetching three resources from the network: a script file, css file, and an image file. These resources will be cached as a backup and can be used when there is a network failure or API response errors.<\/p>\n

      At the time of registering the service worker, several events are triggered in a sequence. The first event is “install”, followed by “activate” and other events like fetch. These are used to implement caching .<\/p>\n

      Step 1: Register the sw.js file<\/strong><\/p>\n

      First, create a one file for service worker logic. We will name this sw.js. Now, from script.js file, we will register the sw.js fle. In the sw.js file, we will listen to the key events to implement caching. We need to check whether service workers are supported in the browser. If supported, we register the sw.js file from our script.js file.<\/p>\n

      \"Register

      Register Service Worker<\/p><\/div>\n

      \"Service

      Service Worker Registered<\/p><\/div>\n

      Step 2: Include the files path to cache with a unique cache name<\/strong><\/p>\n

      A unique name is given to the cache and the list of URLs we want to cache are added to the cache. During the install event, a new cache with unique name is opened and all the required URLs are added one by one.<\/p>\n

      \"Install

      Install Service Worker<\/p><\/div>\n

      Step 3: Listen to the Fetch event<\/strong><\/p>\n

      We add an event listener for the fetch event to listen to all network calls. There are two common approaches to handling the fetch event:<\/p>\n

        \n
      • Network First, Cache Fallback:<\/strong> When a resource is requested, it is initially fetch from the network. After the resource is fetched, the cache is updated with the new resource, and the information is served to the page. The cache acts as a backup if the network fails during the request or there are some API response error from the back end.<\/li>\n
      • Cache First, Network Fallback:<\/strong> In this approach, we first check if the cache has the resource for the request. If found, we respond using the cached version. If not, we make a network call and respond with the fetched resource.<\/li>\n<\/ul>\n
        \"Fetch

        Fetch Network Request<\/p><\/div>\n

        Step 4: Clean up old caches<\/strong><\/p>\n

        In cache memory, it’s possible to store several versions of cached information. Clearing outdated caches that are unnecessary is essential. This cleanup usually occurs during the activate event.<\/p>\n

        \"Activate

        Activate Service Worker<\/p><\/div>\n

        Network requests before Service Worker<\/h4>\n
        \"Network

        Network Request before Service Worker<\/p><\/div>\n

        Network requests after Service Worker<\/h4>\n
        \"Network

        Network Request after Service Worker<\/p><\/div>\n

        Cache stored in Cache Storage<\/h4>\n
        \"Cache

        Cache stored in Cache Storage<\/p><\/div>\n

        Conclusion<\/h3>\n

        Service worker is a great feature to improve web performance and providing superior offline user experiences. By using service worker caching correctly, we can optimize the load time and make our applications more fast and responsive.<\/p>\n","protected":false},"excerpt":{"rendered":"

        Introduction We often hear about service workers in the context of caching techniques, their importance in PWAs, and overall optimization. They enable us to create offline experiences within websites or applications, perform background sync activities, and create push notifications, among other features. Let us understand what service worker is and how to implement it in […]<\/p>\n","protected":false},"author":1284,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":123},"categories":[5876],"tags":[118,3259,55,7636,477,2683,7635],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/73405"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/1284"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=73405"}],"version-history":[{"count":8,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/73405\/revisions"}],"predecessor-version":[{"id":73744,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/73405\/revisions\/73744"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=73405"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=73405"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=73405"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}