กลยุทธ์ Service Worker ขั้นสูง: การแคชและการซิงค์เบื้องหลัง

Service Workers เป็นเทคโนโลยีที่ทรงพลังที่ช่วยให้นักพัฒนาสามารถสร้าง Progressive Web Apps (PWAs) ที่มีประสิทธิภาพสูงขึ้น มีความสามารถในการทำงานออฟไลน์ และมอบประสบการณ์ผู้ใช้ที่ดีขึ้น พวกมันทำหน้าที่เป็นพร็อกซีระหว่างเว็บแอปพลิเคชันและเครือข่าย ทำให้นักพัฒนาสามารถดักจับคำขอของเครือข่ายและตอบสนองด้วยแอสเซทที่แคชไว้หรือเริ่มต้นงานในเบื้องหลังได้ บทความนี้จะเจาะลึกถึงกลยุทธ์การแคชของ Service Worker ขั้นสูงและเทคนิคการซิงโครไนซ์เบื้องหลัง พร้อมทั้งให้ตัวอย่างที่เป็นประโยชน์และแนวทางปฏิบัติที่ดีที่สุดสำหรับการสร้างเว็บแอปพลิเคชันที่แข็งแกร่งและยืดหยุ่นสำหรับผู้ชมทั่วโลก

ทำความเข้าใจเกี่ยวกับ Service Workers

Service Worker คือไฟล์ JavaScript ที่ทำงานในเบื้องหลัง แยกจากเธรดหลักของเบราว์เซอร์ มันสามารถดักจับคำขอของเครือข่าย แคชทรัพยากร และส่งการแจ้งเตือนแบบพุชได้ แม้ว่าผู้ใช้จะไม่ได้ใช้งานเว็บแอปพลิเคชันอยู่ก็ตาม สิ่งนี้ช่วยให้เวลาในการโหลดเร็วขึ้น สามารถเข้าถึงเนื้อหาแบบออฟไลน์ได้ และสร้างประสบการณ์ผู้ใช้ที่มีส่วนร่วมมากขึ้น

คุณสมบัติหลักของ Service Workers ประกอบด้วย:

• การแคช (Caching): การจัดเก็บแอสเซทไว้ในเครื่องเพื่อปรับปรุงประสิทธิภาพและเปิดใช้งานการเข้าถึงแบบออฟไลน์
• การซิงค์เบื้องหลัง (Background Sync): การเลื่อนงานออกไปเพื่อดำเนินการเมื่ออุปกรณ์มีการเชื่อมต่อเครือข่าย
• การแจ้งเตือนแบบพุช (Push Notifications): การมีส่วนร่วมกับผู้ใช้ด้วยการอัปเดตและการแจ้งเตือนที่ทันท่วงที
• การดักจับคำขอของเครือข่าย (Intercepting Network Requests): การควบคุมวิธีการจัดการคำขอของเครือข่าย

กลยุทธ์การแคชขั้นสูง

การเลือกกลยุทธ์การแคชที่เหมาะสมเป็นสิ่งสำคัญอย่างยิ่งในการเพิ่มประสิทธิภาพของเว็บแอปพลิเคชันและรับประกันประสบการณ์ผู้ใช้ที่ราบรื่น นี่คือกลยุทธ์การแคชขั้นสูงบางส่วนที่ควรพิจารณา:

1. Cache-First (แคชก่อน)

กลยุทธ์ Cache-First ให้ความสำคัญกับการให้บริการเนื้อหาจากแคชทุกครั้งที่เป็นไปได้ แนวทางนี้เหมาะสำหรับแอสเซทแบบคงที่ เช่น รูปภาพ ไฟล์ CSS และไฟล์ JavaScript ที่ไม่ค่อยมีการเปลี่ยนแปลง

วิธีการทำงาน:

1. Service Worker ดักจับคำขอของเครือข่าย
2. มันจะตรวจสอบว่าแอสเซทที่ร้องขอมีอยู่ในแคชหรือไม่
3. หากพบ แอสเซทจะถูกให้บริการโดยตรงจากแคช
4. หากไม่พบ คำขอจะถูกส่งไปยังเครือข่าย และการตอบกลับจะถูกแคชไว้เพื่อใช้ในอนาคต

ตัวอย่าง:

            self.addEventListener('fetch', event => {
  event.respondWith(
    caches.match(event.request)
      .then(response => {
        // Cache hit - return response
        if (response) {
          return response;
        }

        // Not in cache - return fetch
        return fetch(event.request).then(
          function(response) {
            // Check if we received a valid response
            if(!response || response.status !== 200 || response.type !== 'basic') {
              return response;
            }

            // IMPORTANT: Clone the response. A response is a stream
            // and because we want the browser to consume the response
            // as well as the cache consuming the response, we need
            // to clone it so we have two streams.
            var responseToCache = response.clone();

            caches.open(CACHE_NAME)
              .then(function(cache) {
                cache.put(event.request, responseToCache);
              });

            return response;
          }
        );
      })
    );
});

            

              
                Copy
              
            
          

2. Network-First (เครือข่ายก่อน)

กลยุทธ์ Network-First ให้ความสำคัญกับการดึงเนื้อหาจากเครือข่ายทุกครั้งที่เป็นไปได้ หากคำขอของเครือข่ายล้มเหลว Service Worker จะกลับไปใช้แคช กลยุทธ์นี้เหมาะสำหรับเนื้อหาที่อัปเดตบ่อยครั้งซึ่งความสดใหม่เป็นสิ่งสำคัญ

วิธีการทำงาน:

1. Service Worker ดักจับคำขอของเครือข่าย
2. มันจะพยายามดึงแอสเซทจากเครือข่าย
3. หากคำขอของเครือข่ายสำเร็จ แอสเซทจะถูกให้บริการและแคชไว้
4. หากคำขอของเครือข่ายล้มเหลว (เช่น เนื่องจากข้อผิดพลาดของเครือข่าย) Service Worker จะตรวจสอบแคช
5. หากพบแอสเซทในแคช แอสเซทนั้นจะถูกให้บริการ
6. หากไม่พบแอสเซทในแคช ข้อความแสดงข้อผิดพลาดจะปรากฏขึ้น (หรือมีการตอบกลับสำรอง)

ตัวอย่าง:

            self.addEventListener('fetch', event => {
  event.respondWith(
    fetch(event.request)
      .then(response => {
        // Check if we received a valid response
        if(!response || response.status !== 200 || response.type !== 'basic') {
          return response;
        }

        // IMPORTANT: Clone the response. A response is a stream
        // and because we want the browser to consume the response
        // as well as the cache consuming the response, we need
        // to clone it so we have two streams.
        var responseToCache = response.clone();

        caches.open(CACHE_NAME)
          .then(function(cache) {
            cache.put(event.request, responseToCache);
          });

        return response;
      })
      .catch(err => {
        // Network request failed, try to get it from the cache.
        return caches.match(event.request);
      })
  );
});

            

              
                Copy
              
            
          

3. Stale-While-Revalidate (ใช้ข้อมูลเก่าขณะตรวจสอบใหม่)

กลยุทธ์ Stale-While-Revalidate จะส่งคืนเนื้อหาที่แคชไว้ทันที ในขณะเดียวกันก็จะดึงเวอร์ชันล่าสุดจากเครือข่ายไปพร้อมกัน วิธีนี้ช่วยให้โหลดครั้งแรกได้รวดเร็วพร้อมกับประโยชน์ของการอัปเดตแคชในเบื้องหลัง

วิธีการทำงาน:

1. Service Worker ดักจับคำขอของเครือข่าย
2. มันจะส่งคืนเวอร์ชันที่แคชไว้ของแอสเซททันที (ถ้ามี)
3. ในเบื้องหลัง มันจะดึงเวอร์ชันล่าสุดของแอสเซทจากเครือข่าย
4. เมื่อคำขอของเครือข่ายสำเร็จ แคชจะถูกอัปเดตด้วยเวอร์ชันใหม่

ตัวอย่าง:

            self.addEventListener('fetch', event => {
  event.respondWith(
    caches.match(event.request)
      .then(cachedResponse => {
        // Even if the response is in the cache, we fetch it from the network
        // and update the cache in the background.
        var fetchPromise = fetch(event.request).then(
          networkResponse => {
            caches.open(CACHE_NAME).then(cache => {
              cache.put(event.request, networkResponse.clone());
              return networkResponse;
            });
          })
        // Return the cached response if we have it, otherwise return the network response
        return cachedResponse || fetchPromise;
      })
  );
});

            

              
                Copy
              
            
          

4. Cache, then Network (แคชแล้วตามด้วยเครือข่าย)

กลยุทธ์ Cache, then Network จะพยายามให้บริการเนื้อหาจากแคชก่อน ในขณะเดียวกัน มันจะดึงเวอร์ชันล่าสุดจากเครือข่ายและอัปเดตแคช กลยุทธ์นี้มีประโยชน์สำหรับการแสดงเนื้อหาอย่างรวดเร็วในขณะที่รับประกันว่าผู้ใช้จะได้รับข้อมูลที่อัปเดตที่สุดในที่สุด มันคล้ายกับ Stale-While-Revalidate แต่รับประกันว่าคำขอของเครือข่ายจะถูกสร้างขึ้น *เสมอ* และแคชจะถูกอัปเดต แทนที่จะทำเฉพาะเมื่อไม่พบในแคชเท่านั้น

วิธีการทำงาน:

1. Service Worker ดักจับคำขอของเครือข่าย
2. มันจะส่งคืนเวอร์ชันที่แคชไว้ของแอสเซททันที (ถ้ามี)
3. มันจะดึงเวอร์ชันล่าสุดของแอสเซทจากเครือข่ายเสมอ
4. เมื่อคำขอของเครือข่ายสำเร็จ แคชจะถูกอัปเดตด้วยเวอร์ชันใหม่

ตัวอย่าง:

            self.addEventListener('fetch', event => {
  // First respond with what's already in the cache
  event.respondWith(caches.match(event.request));

  // Then update the cache with the network response.  This will trigger a
  // new 'fetch' event, which will again respond with the cached value
  // (immediately) while the cache is updated in the background.
  event.waitUntil(
    fetch(event.request).then(response =>
      caches.open(CACHE_NAME).then(cache => cache.put(event.request, response))
    )
  );
});

            

              
                Copy
              
            
          

5. Network Only (เครือข่ายเท่านั้น)

กลยุทธ์นี้บังคับให้ Service Worker ดึงทรัพยากรจากเครือข่ายเสมอ หากเครือข่ายไม่พร้อมใช้งาน คำขอจะล้มเหลว วิธีนี้มีประโยชน์สำหรับทรัพยากรที่มีการเปลี่ยนแปลงสูงและต้องเป็นข้อมูลล่าสุดเสมอ เช่น ฟีดข้อมูลแบบเรียลไทม์

วิธีการทำงาน:

1. Service Worker ดักจับคำขอของเครือข่าย
2. มันจะพยายามดึงแอสเซทจากเครือข่าย
3. หากสำเร็จ แอสเซทจะถูกให้บริการ
4. หากคำขอของเครือข่ายล้มเหลว จะเกิดข้อผิดพลาดขึ้น

ตัวอย่าง:

            self.addEventListener('fetch', event => {
  event.respondWith(fetch(event.request));
});

            

              
                Copy
              
            
          

6. Cache Only (แคชเท่านั้น)

กลยุทธ์นี้บังคับให้ Service Worker ดึงทรัพยากรจากแคชเสมอ หากทรัพยากรไม่พร้อมใช้งานในแคช คำขอจะล้มเหลว วิธีนี้เหมาะสำหรับแอสเซทที่ถูกแคชไว้อย่างชัดเจนและไม่ควรถูกดึงจากเครือข่าย เช่น หน้าสำรองสำหรับกรณีออฟไลน์

วิธีการทำงาน:

1. Service Worker ดักจับคำขอของเครือข่าย
2. มันจะตรวจสอบว่าแอสเซทมีอยู่ในแคชหรือไม่
3. หากพบ แอสเซทจะถูกให้บริการโดยตรงจากแคช
4. หากไม่พบ จะเกิดข้อผิดพลาดขึ้น

ตัวอย่าง:

            self.addEventListener('fetch', event => {
  event.respondWith(caches.match(event.request));
});

            

              
                Copy
              
            
          

7. Dynamic Caching (การแคชแบบไดนามิก)

การแคชแบบไดนามิกเกี่ยวข้องกับการแคชทรัพยากรที่ไม่เป็นที่รู้จักในขณะที่ติดตั้ง Service Worker สิ่งนี้มีประโยชน์อย่างยิ่งสำหรับการแคชการตอบกลับของ API และเนื้อหาไดนามิกอื่น ๆ คุณสามารถใช้ fetch event เพื่อดักจับคำขอของเครือข่ายและแคชการตอบกลับเมื่อได้รับ

ตัวอย่าง:

            self.addEventListener('fetch', event => {
  if (event.request.url.startsWith('https://api.example.com/')) {
    event.respondWith(
      caches.open('dynamic-cache').then(cache => {
        return fetch(event.request).then(response => {
          cache.put(event.request, response.clone());
          return response;
        });
      })
    );
  }
});

            

              
                Copy
              
            
          

การซิงโครไนซ์เบื้องหลัง (Background Synchronization)

Background Synchronization ช่วยให้คุณสามารถเลื่อนงานที่ต้องใช้การเชื่อมต่อเครือข่ายออกไปจนกว่าอุปกรณ์จะมีการเชื่อมต่อที่เสถียร สิ่งนี้มีประโยชน์อย่างยิ่งสำหรับสถานการณ์ที่ผู้ใช้อาจออฟไลน์หรือมีการเชื่อมต่อที่ไม่ต่อเนื่อง เช่น การส่งฟอร์ม การส่งข้อความ หรือการอัปเดตข้อมูล สิ่งนี้ช่วยปรับปรุงประสบการณ์ผู้ใช้อย่างมากในพื้นที่ที่มีเครือข่ายไม่น่าเชื่อถือ (เช่น พื้นที่ชนบทในประเทศกำลังพัฒนา)

การลงทะเบียนสำหรับ Background Sync

ในการใช้ Background Sync คุณต้องลงทะเบียน Service Worker ของคุณสำหรับ `sync` event ซึ่งสามารถทำได้ในโค้ดเว็บแอปพลิเคชันของคุณ:

            navigator.serviceWorker.ready.then(function(swRegistration) {
  return swRegistration.sync.register('my-background-sync');
});

            

              
                Copy
              
            
          

ในที่นี้ `'my-background-sync'` คือแท็กที่ระบุ sync event ที่เฉพาะเจาะจง คุณสามารถใช้แท็กที่แตกต่างกันสำหรับงานเบื้องหลังประเภทต่าง ๆ ได้

การจัดการ Sync Event

ใน Service Worker ของคุณ คุณต้องคอยฟัง `sync` event และจัดการงานเบื้องหลัง ตัวอย่างเช่น:

            self.addEventListener('sync', event => {
  if (event.tag === 'my-background-sync') {
    event.waitUntil(
      doSomeBackgroundTask()
    );
  }
});

            

              
                Copy
              
            
          

เมธอด `event.waitUntil()` จะบอกเบราว์เซอร์ให้คง Service Worker ไว้จนกว่า promise จะเสร็จสมบูรณ์ สิ่งนี้รับประกันว่างานเบื้องหลังจะเสร็จสิ้นแม้ว่าผู้ใช้จะปิดเว็บแอปพลิเคชันไปแล้วก็ตาม

ตัวอย่าง: การส่งฟอร์มในเบื้องหลัง

ลองพิจารณาตัวอย่างที่ผู้ใช้ส่งฟอร์มขณะออฟไลน์ ข้อมูลฟอร์มสามารถจัดเก็บไว้ในเครื่อง และการส่งสามารถเลื่อนออกไปจนกว่าอุปกรณ์จะมีการเชื่อมต่อเครือข่าย

1. การจัดเก็บข้อมูลฟอร์ม:

เมื่อผู้ใช้ส่งฟอร์ม ให้จัดเก็บข้อมูลใน IndexedDB:

            function submitForm(formData) {
  // Store the form data in IndexedDB
  openDatabase().then(db => {
    const tx = db.transaction('submissions', 'readwrite');
    const store = tx.objectStore('submissions');
    store.add(formData);
    return tx.done;
  }).then(() => {
    // Register for background sync
    return navigator.serviceWorker.ready;
  }).then(swRegistration => {
    return swRegistration.sync.register('form-submission');
  });
}

            

              
                Copy
              
            
          

2. การจัดการ Sync Event:

ใน Service Worker ให้คอยฟัง `sync` event และส่งข้อมูลฟอร์มไปยังเซิร์ฟเวอร์:

            self.addEventListener('sync', event => {
  if (event.tag === 'form-submission') {
    event.waitUntil(
      openDatabase().then(db => {
        const tx = db.transaction('submissions', 'readwrite');
        const store = tx.objectStore('submissions');
        return store.getAll();
      }).then(submissions => {
        // Submit each form data to the server
        return Promise.all(submissions.map(formData => {
          return fetch('/submit-form', {
            method: 'POST',
            body: JSON.stringify(formData),
            headers: {
              'Content-Type': 'application/json'
            }
          }).then(response => {
            if (response.ok) {
              // Remove the form data from IndexedDB
              return openDatabase().then(db => {
                const tx = db.transaction('submissions', 'readwrite');
                const store = tx.objectStore('submissions');
                store.delete(formData.id);
                return tx.done;
              });
            }
            throw new Error('Failed to submit form');
          });
        }));
      }).catch(error => {
        console.error('Failed to submit forms:', error);
      })
    );
  }
});

            

              
                Copy
              
            
          

แนวทางปฏิบัติที่ดีที่สุดสำหรับการนำ Service Worker ไปใช้งาน

เพื่อให้แน่ใจว่าการนำ Service Worker ไปใช้งานประสบความสำเร็จ ให้พิจารณาแนวทางปฏิบัติที่ดีที่สุดต่อไปนี้:

• ทำให้สคริปต์ Service Worker เรียบง่าย: หลีกเลี่ยงตรรกะที่ซับซ้อนในสคริปต์ Service Worker เพื่อลดข้อผิดพลาดและรับประกันประสิทธิภาพสูงสุด
• ทดสอบอย่างละเอียด: ทดสอบการใช้งาน Service Worker ของคุณในเบราว์เซอร์และเงื่อนไขเครือข่ายต่าง ๆ เพื่อระบุและแก้ไขปัญหาที่อาจเกิดขึ้น ใช้เครื่องมือสำหรับนักพัฒนาของเบราว์เซอร์ (เช่น Chrome DevTools) เพื่อตรวจสอบพฤติกรรมของ Service Worker
• จัดการข้อผิดพลาดอย่างนุ่มนวล: ใช้การจัดการข้อผิดพลาดเพื่อจัดการกับข้อผิดพลาดของเครือข่าย การไม่พบข้อมูลในแคช และสถานการณ์ที่ไม่คาดคิดอื่น ๆ อย่างนุ่มนวล ให้ข้อความแสดงข้อผิดพลาดที่เป็นประโยชน์แก่ผู้ใช้
• ใช้การกำหนดเวอร์ชัน: ใช้การกำหนดเวอร์ชันสำหรับ Service Worker ของคุณเพื่อให้แน่ใจว่าการอัปเดตจะถูกนำไปใช้อย่างถูกต้อง เพิ่มหมายเลขเวอร์ชันของชื่อแคชหรือชื่อไฟล์ Service Worker เมื่อมีการเปลี่ยนแปลง
• ตรวจสอบประสิทธิภาพ: ตรวจสอบประสิทธิภาพของการใช้งาน Service Worker ของคุณเพื่อระบุจุดที่ต้องปรับปรุง ใช้เครื่องมือเช่น Lighthouse เพื่อวัดตัวชี้วัดประสิทธิภาพ
• พิจารณาด้านความปลอดภัย: Service Workers ทำงานในบริบทที่ปลอดภัย (HTTPS) ควรติดตั้งเว็บแอปพลิเคชันของคุณผ่าน HTTPS เสมอเพื่อปกป้องข้อมูลผู้ใช้และป้องกันการโจมตีแบบ man-in-the-middle
• จัดเตรียมเนื้อหาสำรอง: ใช้เนื้อหาสำรองสำหรับสถานการณ์ออฟไลน์เพื่อมอบประสบการณ์ผู้ใช้พื้นฐานแม้ในขณะที่อุปกรณ์ไม่ได้เชื่อมต่อกับเครือข่าย

ตัวอย่างแอปพลิเคชันระดับโลกที่ใช้ Service Workers

• Google Maps Go: Google Maps เวอร์ชันน้ำหนักเบานี้ใช้ Service Workers เพื่อให้สามารถเข้าถึงแผนที่และการนำทางแบบออฟไลน์ได้ ซึ่งเป็นประโยชน์อย่างยิ่งในพื้นที่ที่มีการเชื่อมต่อจำกัด
• Starbucks PWA: Progressive Web App ของ Starbucks ช่วยให้ผู้ใช้สามารถเรียกดูเมนู สั่งซื้อ และจัดการบัญชีของตนได้แม้ในขณะออฟไลน์ สิ่งนี้ช่วยปรับปรุงประสบการณ์ผู้ใช้ในพื้นที่ที่มีสัญญาณโทรศัพท์หรือ Wi-Fi ไม่ดี
• Twitter Lite: Twitter Lite ใช้ Service Workers ในการแคชทวีตและรูปภาพ ลดการใช้ข้อมูลและปรับปรุงประสิทธิภาพบนเครือข่ายที่ช้า ซึ่งมีค่าอย่างยิ่งสำหรับผู้ใช้ในประเทศกำลังพัฒนาที่มีแผนข้อมูลราคาแพง
• AliExpress PWA: PWA ของ AliExpress ใช้ประโยชน์จาก Service Workers เพื่อให้เวลาในการโหลดเร็วขึ้นและการเรียกดูแคตตาล็อกสินค้าแบบออฟไลน์ ซึ่งช่วยเพิ่มประสบการณ์การช็อปปิ้งสำหรับผู้ใช้ทั่วโลก

สรุป

Service Workers เป็นเครื่องมือที่ทรงพลังสำหรับการสร้างเว็บแอปพลิเคชันสมัยใหม่ที่มีประสิทธิภาพสูงขึ้น มีความสามารถในการทำงานออฟไลน์ และมอบประสบการณ์ผู้ใช้ที่ดีขึ้น ด้วยการทำความเข้าใจและนำกลยุทธ์การแคชขั้นสูงและเทคนิคการซิงโครไนซ์เบื้องหลังไปใช้ นักพัฒนาสามารถสร้างแอปพลิเคชันที่แข็งแกร่งและยืดหยุ่นที่ทำงานได้อย่างราบรื่นในสภาพเครือข่ายและอุปกรณ์ต่าง ๆ สร้างประสบการณ์ที่ดีขึ้นสำหรับผู้ใช้ทุกคน โดยไม่คำนึงถึงตำแหน่งหรือคุณภาพเครือข่ายของพวกเขา ในขณะที่เทคโนโลยีเว็บยังคงพัฒนาต่อไป Service Workers จะมีบทบาทสำคัญมากขึ้นในการกำหนดอนาคตของเว็บ