הטמעת Service Worker: אסטרטגיות מטמון ומצב לא מקוון

בעת טעינת אתר, כל בקשה נוספת לשרת מעלה את מדד ה-LCP. ללא Service Worker, המשאבים נשלפים מהרשת בכל ניווט, דבר קריטי במיוחד למשתמשים ניידים עם חיבורים לא יציבים. אנו פותרים בעיה זו על ידי הטמעת סקריפט רקע שתופס בקשות. הגדרה נכונה של אסטרטגיות מטמון יכולה להפחית את ה-LCP ב-40–60% ואת ה-TTFB פי 3–5. הניסיון שלנו מראה ש-Service Worker מכוון היטב מגדיל את שיעור ההמרה ב-10–20% ומפחית את עומס השרת בחצי.

מקרה עדכני מהפרקטיקה שלנו: אתר מסחר אלקטרוני מבוסס Next.js היה עם LCP של 4.2 שניות במקום הנורמה של 2.5 שניות. לאחר הגדרת ה-SW עם אסטרטגיית Network First לדפים ו-Cache First לנכסים סטטיים, ה-LCP ירד ל-1.8 שניות ושיעור ההמרה עלה ב-15%. במשך 6 שנות עבודה, הטמענו יותר מ-80 פרויקטים עם PWA, תוך הבטחת שיפור של לפחות 30% במדדי Core Web Vitals.

במאמר זה, נפרק כיצד להטמיע מטמון כראוי כך שמשתמשים יקבלו תוכן באופן מיידי גם כשהרשת נופלת. תלמדו אילו אסטרטגיות לבחור עבור סוגי משאבים שונים וכיצד להימנע מטעויות אופייניות.

אילו בעיות Service Worker פותר?

Service Worker מבטל מספר צווארי בקבוק אופייניים:

• ביקורים חוזרים איטיים: ללא מטמון, כל המשאבים נשלפים מחדש. ה-SW מחזיר אותם מהמטמון באופן מיידי.
• חוסר גישה לא מקוונת: כשהרשת נופלת, המשתמש רואה דף ריק. ה-SW יכול להציג גרסה שמורה במטמון.
• TTFB גבוה: אם בקשות API אינן שמורות במטמון, כל רינדור דף ממתין לתגובת השרת. ה-SW יכול להגיב מהמטמון תוך עדכון נתונים ברקע.
• חוסר התאמה בהידרציה: עם SSR, אי-התאמות בין ה-HTML של השרת ללקוח. שמירת נכסים סטטיים במטמון מפחיתה את זמן ההידרציה.

אסטרטגיות מטמון: השוואה

האסטרטגיות המרכזיות הן Cache First, Network First, Stale While Revalidate. הבחירה תלויה בסוג המשאב ובמידת הרעננות הנדרשת.

Cache First מגיש מהמטמון פי 10 מהר יותר מאשר Network First עבור נכסים סטטיים. האסטרטגיה הראשונה מתאימה לקבצים בלתי ניתנים לשינוי, השנייה לדפים שחייבים להיות תמיד רעננים, והשלישית למשאבים שבהם גרסה ישנה מקובלת למשך 1–2 שניות.

איך אנחנו עושים את זה: מקרה בוחן

אנחנו עובדים עם React, Next.js, Vite. עבור סביבת ייצור, אנו משתמשים בספריית Workbox — היא מבטלת ניהול מטמון ידני ומספקת מטפלים מוכנים. דוגמת תצורה עם vite-plugin-pwa:

// vite.config.ts
import { defineConfig } from 'vite';
import { VitePWA } from 'vite-plugin-pwa';

export default defineConfig({
  plugins: [
    VitePWA({
      registerType: 'autoUpdate',
      workbox: {
        globPatterns: ['**/*.{js,css,html,ico,png,svg,woff2}'],
        runtimeCaching: [
          {
            urlPattern: /^https:\/\/api\.example\.ru/,
            handler: 'NetworkFirst',
            options: {
              cacheName: 'api-cache',
              networkTimeoutSeconds: 3,
              expiration: {
                maxEntries: 50,
                maxAgeSeconds: 300,
              },
            },
          },
          {
            urlPattern: /\.(?:webp|avif|jpg|png|svg)$/,
            handler: 'StaleWhileRevalidate',
            options: {
              cacheName: 'images-cache',
              expiration: {
                maxEntries: 200,
                maxAgeSeconds: 30 * 24 * 60 * 60,
              },
            },
          },
        ],
      },
    }),
  ],
});

// src/service-worker-registration.ts
export function registerServiceWorker() {
  if ('serviceWorker' in navigator) {
    window.addEventListener('load', () => {
      navigator.serviceWorker.register('/sw.js', { scope: '/' })
        .then(registration => {
          console.log('SW registered:', registration.scope);
          setInterval(() => registration.update(), 60 * 60 * 1000);
        })
        .catch(err => console.error('SW registration failed:', err));
    });
  }
}

למה חשוב לשמור בקשות API במטמון?

בקשות API הן גורם נפוץ ל-TTFB גבוה. אם התגובות אינן שמורות במטמון, כל ניווט בדף מפעיל בקשה חדשה. אסטרטגיית Network First עם אורך חיים קצר למטמון (לדוגמה, 5 דקות) מאיצה צפיות חוזרות. במקרה של תקלת רשת, המשתמש יקבל לפחות נתונים שמורים במקום שגיאה. זמן תגובת API יכול להגיע עד 500 אלפיות השנייה, בעוד שמירה במטמון מפחיתה אותו ל-0–50 אלפיות השנייה.

איך לעדכן את המטמון מבלי לאבד משתמשים?

בעת עדכון Service Worker, חשוב לנהל נכון את גרסאות המטמון. באירוע // vite.config.ts import { defineConfig } from 'vite'; import { VitePWA } from 'vite-plugin-pwa'; export default defineConfig({ plugins: [ VitePWA({ registerType: 'autoUpdate', workbox: { globPatterns: ['**/*.{js,css,html,ico,png,svg,woff2}'], runtimeCaching: [ { urlPattern: /^https:\/\/api\.example\.ru/, handler: 'NetworkFirst', options: { cacheName: 'api-cache', networkTimeoutSeconds: 3, expiration: { maxEntries: 50, maxAgeSeconds: 300, }, }, }, { urlPattern: /\.(?:webp|avif|jpg|png|svg)$/, handler: 'StaleWhileRevalidate', options: { cacheName: 'images-cache', expiration: { maxEntries: 200, maxAgeSeconds: 30 * 24 * 60 * 60, }, }, }, ], }, }), ], }); , אנו מוחקים מטמונים ישנים, ושומרים רק את הנוכחי. כדי להודיע למשתמש על SW חדש, אנו משתמשים באירוע // src/service-worker-registration.ts export function registerServiceWorker() { if ('serviceWorker' in navigator) { window.addEventListener('load', () => { navigator.serviceWorker.register('/sw.js', { scope: '/' }) .then(registration => { console.log('SW registered:', registration.scope); setInterval(() => registration.update(), 60 * 60 * 1000); }) .catch(err => console.error('SW registration failed:', err)); }); } } ומציגים כפתור "עדכון":

navigator.serviceWorker.ready.then(registration => {
    registration.addEventListener('updatefound', () => {
        const newWorker = registration.installing!;
        newWorker.addEventListener('statechange', () => {
            if (newWorker.state === 'installed' && navigator.serviceWorker.controller) {
                showUpdateNotification(() => {
                    newWorker.postMessage({ type: 'SKIP_WAITING' });
                    window.location.reload();
                });
            }
        });
    });
});

תהליך העבודה

1. אנליטיקה: ביקורת על Core Web Vitals הנוכחיים, זיהוי צווארי בקבוק (LCP, CLS).
2. עיצוב: בחירת אסטרטגיות לכל קבוצת משאבים, קביעת היקף.
3. הטמעה: כתיבת Service Worker (ידנית או דרך Workbox), אינטגרציה עם מערכת הבנייה.
4. בדיקות: אימות ב-Chrome DevTools (Application > Service Workers), Lighthouse, WebPageTest.
5. פריסה: השקה הדרגתית, ניטור שגיאות.

לוחות זמנים משוערים

הגדרה בסיסית אורכת 1 עד 2 ימים. אם נדרשת לוגיקה מותאמת אישית (לדוגמה, שמירת GraphQL במטמון), לוח הזמנים גדל ל-4–5 ימים. העלות מחושבת באופן אישי — צרו קשר לקבלת הערכה.

מה כלול

• הגדרת Service Worker עם אסטרטגיות לנכסים סטטיים, דפים ו-API.
• הגדרת Workbox (אם משתמשים ב-Vite/Webpack).
• הטמעת התראות עדכון.
• יצירת דף לא מקוון.
• בדיקות ופרופילינג.
• תיעוד על אסטרטגיות ותפעול.
• תמיכה לאחר השקה (שבועיים).

טעויות אופייניות בהטמעת Service Worker

צרו קשר לקבלת ייעוץ לפרויקט שלכם. הזמינו הטמעת Service Worker לשיפור Core Web Vitals.

MDN Web Docs: Service Worker API