Web Workers vs Service Workers : ce qu'ils sont et pourquoi

Web Workers vs Service Workers : aperçu rapide

Les navigateurs exécutent la plupart de votre JavaScript sur le thread principal—le même endroit qui gère les saisies utilisateur, les animations et le rendu de la page. Quand un travail lourd s'y produit (parsing de gros jeux de données, traitement d'images, calculs complexes), l'interface peut saccader ou « geler ». Les workers existent pour déplacer certaines tâches hors du thread principal ou en dehors du contrôle direct de la page, afin que votre app reste réactive.

Le problème que résolvent les workers

Si votre page est occupée à faire un calcul de 200 ms, le navigateur ne peut pas faire défiler en douceur, répondre aux clics ou maintenir les animations à 60 fps. Les workers aident en vous permettant d'effectuer du travail en arrière-plan pendant que le thread principal se concentre sur l'interface.

Définitions rapides

Un Web Worker est un thread JavaScript en arrière-plan que vous créez depuis une page. Il est idéal pour des tâches lourdes en CPU qui bloqueraient autrement l'interface.

Un Service Worker est un type spécial de worker qui se place entre votre application web et le réseau. Il peut intercepter des requêtes, mettre en cache des réponses et activer des fonctionnalités comme le support hors ligne et les notifications push.

Un modèle mental simple : « threads » vs « proxy réseau »

Pensez au Web Worker comme à un assistant qui fait des calculs dans une autre pièce. Vous lui envoyez un message, il travaille, puis il renvoie un message.

Pensez au Service Worker comme à un portier à la porte d'entrée. Les requêtes pour des pages, des scripts et des appels d'API passent devant lui, et il peut décider de récupérer depuis le réseau, servir depuis le cache, ou répondre d'une manière personnalisée.

Ce que vous apprendrez dans cet article

À la fin, vous saurez :

• quand un web worker est l'outil adapté pour la performance (et ce à quoi il n'a pas accès)
• ce qu'un service worker permet pour la mise en cache hors ligne, les mises à jour et le comportement d'une progressive web app
• comment la messagerie (comme postMessage) s'insère dans le modèle des workers, et pourquoi la Cache Storage API compte pour le hors ligne

Cet aperçu pose le « pourquoi » et le modèle mental—ensuite nous plongerons dans le comportement de chaque type de worker et où les utiliser dans des projets réels.

Pourquoi les navigateurs ont des workers

Quand vous ouvrez une page web, la plupart de ce que vous « ressentez » se passe sur le thread principal. Il est responsable d'afficher les pixels (rendu), de réagir aux taps et clics (saisie), et d'exécuter beaucoup de JavaScript.

Le thread principal est une file de caisse partagée

Parce que le rendu, la gestion des entrées et JavaScript s'exécutent souvent à tour de rôle sur le même thread, une tâche lente peut faire attendre tout le reste. C'est pourquoi les problèmes de performance se manifestent souvent comme des problèmes de réactivité, pas seulement du « code lent ».

Ce que « bloquer » donne à l'utilisateur :

• défilement saccadé (jank)
• les boutons ne répondent pas immédiatement aux clics
• la saisie est en retard par rapport au clavier
• les animations gèlent un instant

Asynchrone n'est pas synonyme de parallèle

JavaScript propose de nombreuses API asynchrones—fetch(), timers, événements—qui aident à éviter d'attendre. Mais l'asynchrone ne fait pas disparaître le fait que du travail lourd puisse s'exécuter sur le même thread que le rendu.

Si vous faites un calcul coûteux (traitement d'image, parsing d'un gros JSON, crypto, filtrage complexe) sur le thread principal, il rivalise toujours avec les mises à jour de l'UI. « Asynchrone » peut différer quand le code s'exécute, mais il peut toujours s'exécuter sur le même thread principal et provoquer des janks lorsqu'il s'exécute.

Où s'insèrent les workers dans l'architecture du navigateur

Les workers existent pour que les navigateurs puissent garder la page réactive tout en faisant un travail significatif.

• Web Workers vous permettent d'exécuter du JavaScript sur un thread en arrière-plan pour des tâches lourdes en CPU.\n- Service Workers s'exécutent séparément de n'importe quelle page, agissant davantage comme une couche réseau et de cache pouvant fonctionner même lorsque la page n'est pas ouverte.

En bref : les workers protègent le thread principal pour que votre application reste interactive tout en effectuant un vrai travail en arrière-plan.

Qu'est-ce qu'un Web Worker ?

Un Web Worker est un moyen d'exécuter du JavaScript hors du thread principal. Au lieu de rivaliser avec le travail UI (rendu, défilement, réponse aux clics), un worker s'exécute dans son propre thread en arrière-plan afin que les tâches lourdes puissent se terminer sans donner l'impression que la page est « bloquée ».

Pensez-y ainsi : la page reste concentrée sur l'interaction utilisateur, tandis que le worker gère des travaux lourds en CPU comme le parsing d'un gros fichier, le crunching de nombres ou la préparation de données pour des graphiques.

Où il s'exécute

Un Web Worker s'exécute dans un thread séparé avec son propre scope global. Il a toujours accès à de nombreuses API web (timers, fetch dans de nombreux navigateurs, crypto, etc.), mais il est volontairement isolé de la page.

Dedicated Worker vs Shared Worker

Il existe quelques variantes courantes :

• Dedicated Worker : connecté à une seule page/onglet. Quand cette page disparaît, le worker est généralement terminé.\n- Shared Worker : peut être partagé par plusieurs pages/onglets de la même origine, utile pour coordonner du travail entre onglets (par exemple partager une unique connexion ou synchroniser un état).

Si vous n'avez jamais utilisé les workers, la plupart des exemples sont des dedicated workers.

Comment communiquent les Web Workers

Les workers n'appellent pas de fonctions directement dans votre page. La communication se fait via l'envoi de messages :

• La page envoie des données au worker avec postMessage().\n- Le worker répond également avec postMessage().\n- Les données sont transférées en utilisant l'algorithme de structured clone, qui supporte de nombreux types natifs (objets, tableaux, chaînes, nombres, Maps/Sets, ArrayBuffers, etc.).

Pour de grosses données binaires, vous pouvez souvent améliorer la performance en transférant la propriété d'un ArrayBuffer (pour éviter la copie), ce qui garde le passage de messages rapide.

Limites courantes (par conception)

Parce qu'un worker est isolé, il existe quelques contraintes clés :

• Pas d'accès direct au DOM : un worker ne peut pas lire ni modifier le HTML, le CSS ou la mise en page de la page.\n- Globals différents : vous n'avez pas window ou document. Les workers s'exécutent sous self (un scope global worker), et les API disponibles peuvent différer de la page principale.\n- Esprit asynchrone : tout est basé sur des messages, vous structurez donc votre code autour de l'envoi de travail et de la réception des résultats.

Bien utilisé, un Web Worker est l'un des moyens les plus simples d'améliorer la performance du thread principal sans changer le comportement de votre application—seulement l'endroit où le travail coûteux s'exécute.

Quand utiliser un Web Worker (et quand ne pas l'utiliser)

Les Web Workers conviennent quand votre page semble « bloquée » parce que du JavaScript fait trop de travail sur le thread principal. Le thread principal gère aussi les interactions utilisateur et le rendu, donc des tâches lourdes peuvent entraîner du jank, des clics retardés et un défilement figé.

Meilleures utilisations pour les Web Workers

Utilisez un Web Worker quand vous avez du travail intensif en CPU qui n'a pas besoin d'accès direct au DOM :

• Calcul lourd : simulations, crunching de données, calculs intensifs.\n- Parsing et transformation : parsing de gros JSON, parsing CSV, validation de schéma.\n- Compression / décompression : charges type zip/gzip, encodage/décodage.\n- Traitement d'image : redimensionnement, filtrage, génération de vignettes (souvent associé à OffscreenCanvas dans les navigateurs supportés).

Un exemple pratique : si vous recevez un grand payload JSON et que son parsing provoque des saccades de l'UI, déplacez le parsing dans un worker, puis renvoyez le résultat.

Conseils de gestion des données (pour la vitesse)

La communication avec un worker se fait via postMessage. Pour de grandes données binaires, préférez les objets transférables (comme ArrayBuffer) afin que le navigateur puisse transférer la propriété mémoire au worker au lieu de la copier.

// main thread
worker.postMessage(buffer, [buffer]); // transfère l'ArrayBuffer

C'est particulièrement utile pour des buffers audio, des octets d'image, ou d'autres gros blocs de données.

Quand ne pas utiliser un Web Worker

Les workers ont un coût : fichiers supplémentaires, passage de messages, et un flux de débogage différent. Évitez-les quand :

• La tâche est minime (millisecondes) et s'exécute peu fréquemment.\n- Le travail nécessite des lectures/écritures DOM fréquentes (les workers ne peuvent pas toucher le DOM).\n- Vous avez besoin d'une communication très basse latence en aller-retour ; un ping-pong constant via postMessage peut annihiler le bénéfice.

Règle simple

Si une tâche peut provoquer une pause perceptible (souvent ~50 ms+) et peut s'exprimer comme « entrée → calcul → sortie » sans accès au DOM, un Web Worker en vaut généralement la peine. Si c'est principalement des mises à jour UI, restez sur le thread principal et optimisez là-bas.

Qu'est-ce qu'un Service Worker ?

Un Service Worker est un fichier JavaScript spécial qui s'exécute en arrière-plan dans le navigateur et agit comme une couche réseau programmable pour votre site. Au lieu de s'exécuter dans la page elle-même, il se place entre votre application web et le réseau, vous permettant de décider de ce qui se passe quand l'application demande des ressources (HTML, CSS, appels API, images).

Principes du cycle de vie (register → install → activate → control)

Un Service Worker a un cycle de vie séparé de n'importe quel onglet :

• Register : la page informe le navigateur « ce site a un service worker » (généralement depuis votre JS principal).\n- Install : le navigateur le télécharge et exécute une étape d'installation, souvent utilisée pour pré-cacher des fichiers importants.\n- Activate : le nouveau worker prend la main, typiquement après la fermeture des anciens onglets ou quand il est sûr de remplacer une version plus vieille.\n- Control : une fois actif, il peut « contrôler » les pages dans sa portée et commencer à intercepter les requêtes.

Comme il peut être arrêté et redémarré à tout moment, traitez-le comme un script piloté par des événements : faites le travail rapidement, stockez l'état dans un stockage persistant, et n'assumez pas qu'il tourne en permanence.

Règles de portée et d'origine (haut niveau)

Les Service Workers sont restreints à la même origine (même domaine/protocole/port) et ne contrôlent que les pages sous leur scope—généralement le dossier où le fichier worker est servi (et en dessous). Ils nécessitent aussi HTTPS (sauf localhost) car ils peuvent affecter les requêtes réseau.

APIs clés que vous verrez souvent

• Fetch event : intercepter les requêtes et décider d'utiliser le réseau, un cache, ou une réponse personnalisée.\n- Cache Storage API : stocker et récupérer des réponses en cache pour le hors ligne et la vitesse.\n- Clients API : communiquer avec et gérer les onglets/fenêtres ouverts que votre worker contrôle.

À quoi servent les Service Workers

Un Service Worker sert principalement à se placer entre votre application web et le réseau. Il peut décider quand utiliser le réseau, quand utiliser des données mises en cache, et effectuer un peu de travail en arrière-plan—sans bloquer la page.

Support hors ligne (caching intelligent)

La tâche la plus courante est d'activer des expériences hors ligne ou pour connexions faibles en mettant en cache des assets et des réponses.

Quelques stratégies de mise en cache pratiques :

• Cache-first : idéal pour les fichiers statiques (CSS, JS, logos). Rapide, fonctionne hors ligne.\n- Network-first : bon pour du contenu souvent mis à jour (news, feeds). Se rabat sur le cache quand il n'y a pas de réseau.\n- Stale-while-revalidate : affiche immédiatement le contenu mis en cache, puis le rafraîchit en arrière-plan pour la prochaine fois.

Ceci s'implémente généralement avec la Cache Storage API et le traitement de l'événement fetch.

Visites répétées plus rapides

Les Service Workers peuvent améliorer la vitesse perçue lors des retours en :

• Précaching : sauvegarder les fichiers « indispensables » de l'app pendant l'installation (souvent appelé app shell).\n- Mise en cache à l'exécution : mettre en cache des pages ou réponses API au fur et à mesure de la navigation.

Le résultat : moins de requêtes réseau, démarrage plus rapide et performances plus constantes sur des connexions instables.

Fonctionnalités en arrière-plan (si supportées)

Les Service Workers peuvent alimenter des capacités en arrière-plan comme les notifications push et la synchronisation en arrière-plan (le support varie selon le navigateur et la plateforme). Cela signifie que vous pouvez notifier les utilisateurs ou réessayer une requête échouée plus tard—même si la page n'est pas ouverte.

Briques de construction PWA

Si vous construisez une progressive web app, les Service Workers sont un pilier derrière :

• Installabilité (associé au web app manifest)\n- Pages hors ligne fiables (par exemple une page de secours conviviale)\n- Le modèle app shell pour une navigation réactive

Différences clés : Web Worker vs Service Worker

Si vous ne retenez qu'une chose : les Web Workers aident votre page à effectuer du travail lourd sans geler l'UI, tandis que les Service Workers aident votre application à contrôler les requêtes réseau et à se comporter comme une app installable (PWA).

Où ils s'exécutent (pour quel travail)

Un Web Worker sert pour des tâches lourdes en CPU—parser de grands fichiers, générer des vignettes, crunching de nombres—pour que le thread principal reste réactif.

Un Service Worker sert pour le traitement des requêtes et les tâches liées au cycle de vie de l'app—support hors ligne, stratégies de cache, synchronisation en arrière-plan et notifications push. Il peut se placer entre votre application et le réseau.

Durée de vie et « qui le possède »

Un Web Worker est typiquement lié à une page/onglet. Quand la page disparaît, le worker s'arrête (sauf cas spéciaux comme SharedWorker).

Un Service Worker est piloté par les événements. Le navigateur peut le démarrer pour traiter un événement (comme une requête fetch ou un push), puis l'arrêter quand il est inactif. Cela signifie qu'il peut fonctionner même quand aucun onglet n'est ouvert, tant qu'un événement le réveille.

Accès et contrôle du réseau

Un Web Worker ne peut pas intercepter les requêtes réseau faites par la page. Il peut faire des fetch(), mais il ne peut pas réécrire, mettre en cache ou servir des réponses pour d'autres parties de votre site.

Un Service Worker peut intercepter les requêtes réseau (via l'événement fetch), décider d'aller sur le réseau, répondre depuis le cache, ou renvoyer une page de secours.

Stockage et mise en cache

Un Web Worker ne gère pas le cache HTTP de votre app.

Un Service Worker utilise couramment la Cache Storage API pour stocker et servir des paires requête/réponse—fondation de la mise en cache hors ligne et des chargements « instantanés » lors de visites répétées.

Comment les mettre en place (étapes haut niveau)

Faire tourner un worker revient surtout à savoir d'où il s'exécute et comment il est chargé. Les Web Workers sont créés directement par un script de page. Les Service Workers sont enregistrés par la page et s'installent via le navigateur pour se placer « devant » les requêtes réseau de votre site.

Web Worker : le créer depuis votre page

Un Web Worker naît quand votre page en crée un. Vous pointez vers un fichier JavaScript séparé, puis communiquez via postMessage.

// main.js (exécuté sur la page)
const worker = new Worker('/workers/resize-worker.js', { type: 'module' });

worker.postMessage({ action: 'start', payload: { /* ... */ } });

worker.onmessage = (event) => {
  console.log('From worker:', event.data);
};

Un bon modèle mental : le fichier worker est simplement un autre URL de script que votre page peut récupérer, mais il s'exécute hors du thread principal.

Service Worker : l'enregistrer (une fois) et laisser le navigateur l'installer

Les Service Workers doivent être enregistrés depuis une page que l'utilisateur visite :

// main.js
if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js');
}

Après l'enregistrement, le navigateur gère le cycle install/activate. Votre sw.js peut écouter des événements comme install, activate et fetch.

Pourquoi les Service Workers exigent HTTPS

Les Service Workers peuvent intercepter les requêtes réseau et mettre en cache des réponses. Si l'enregistrement était autorisé en HTTP, un attaquant réseau pourrait remplacer un sw.js malveillant et contrôler les visites futures. HTTPS (ou http://localhost pour le développement) protège le script et le trafic qu'il peut influencer.

Mentalité de versioning : traitez les fichiers worker comme des « releases » déployables

Les navigateurs mettent en cache et mettent à jour les workers différemment des scripts de page normaux. Prévoyez des mises à jour :

• Modifiez le fichier quand le comportement change (souvent en déployant un nouveau sw.js/bundle worker).\n- Dans les Service Workers, attendez-vous à un flux d'« update » : un nouveau worker s'installe, puis s'active quand c'est sûr.\n- Quand vous changez les règles de cache, incluez une logique de nettoyage lors de l'activation pour que les anciens caches ne restent pas.

Si vous voulez une stratégie de déploiement plus douce, voyez /blog/debugging-workers pour des habitudes de test qui attrapent tôt les cas limites d'update.

Débogage et tests des workers dans le navigateur

Les workers échouent différemment du JavaScript « normal » : ils s'exécutent dans des contextes séparés, ont leur propre console, et peuvent être redémarrés par le navigateur. Une routine de débogage solide vous fera gagner des heures.

Débogage des Web Workers (DevTools)

Ouvrez DevTools et cherchez les cibles spécifiques aux workers. Dans Chrome/Edge, vous verrez souvent les workers listés sous Sources (ou via l'entrée « Dedicated worker ») et dans le sélecteur de contexte de la Console.

Utilisez les mêmes outils que sur le thread principal :

• Logging console : les logs d'un Web Worker apparaissent dans DevTools, mais assurez-vous de consulter le bon contexte.\n- Points d'arrêt : placez des breakpoints dans le script du worker ; parcourez les handlers onmessage et les fonctions longues.\n- Profilage de performance : enregistrez une trace Performance et vérifiez que le thread principal reste réactif pendant que le worker fait le travail.

Si des messages semblent « perdus », inspectez les deux côtés : vérifiez que vous appelez worker.postMessage(...), que le worker a self.onmessage = ..., et que la forme du message correspond.

Débogage des Service Workers (panneau Application)

Les Service Workers se déboguent mieux dans le panneau Application :

• Vérifiez le statut d'enregistrement, la portée et les versions active/attente/installée.\n- Utilisez les contrôles de cycle de vie comme Skip waiting et Unregister pour réinitialiser un état défectueux.\n- Activez Update on reload pour éviter de courir après du code obsolète lors de l'itération.

Surveillez aussi la Console pour des erreurs d'install/activate/fetch—elles expliquent souvent pourquoi la mise en cache ou le comportement hors ligne ne fonctionne pas.

Pièges courants et conseils de test

Les problèmes de cache sont la principale source de pertes de temps : mettre en cache les mauvais fichiers (ou trop agressivement) peut garder de l'HTML/JS ancien. Pendant les tests, effectuez un hard reload et confirmez ce qui est réellement servi depuis le cache.

Pour des tests réalistes, utilisez DevTools pour :

• simuler le mode Offline et vérifier les pages de secours\n- appliquer un throttling réseau\n- recharger plusieurs fois pour valider les mises à jour du Service Worker et la gestion des messages

Si vous itérez rapidement sur une PWA, il peut être utile de générer une app de base propre (avec un Service Worker et une sortie de build prévisibles) puis d'affiner les stratégies de cache depuis là. Des plateformes comme Koder.ai peuvent aider pour ce type d'expérimentation : vous pouvez prototyper une app React depuis une invite, exporter le code source, puis ajuster votre configuration de workers et vos règles de cache avec un retour plus rapide.

Considérations de sécurité, vie privée et performance

Les workers peuvent rendre les apps plus fluides et plus capables, mais ils changent l'endroit où le code s'exécute et ce à quoi il peut accéder. Un rapide contrôle sécurité/vie privée/performance vous évitera des bugs surprenants—et des utilisateurs mécontents.

Frontières de sécurité (et pourquoi la même origine importe)

Les Web Workers et les Service Workers sont restreints par la same-origin policy : ils ne peuvent interagir directement qu'avec des ressources de la même origine (même schéma/hôte/port) sauf si le serveur autorise l'accès cross-origin via CORS. Cela empêche un worker de tirer discrètement des données d'un autre site et de les mélanger dans votre app.

Les Service Workers ont des garde-fous supplémentaires : ils nécessitent généralement HTTPS (ou localhost en développement) car ils peuvent intercepter des requêtes réseau. Traitez-les comme du code privilégié : limitez les dépendances, évitez le chargement dynamique de code, et versionnez la logique de cache pour que d'anciens caches ne servent pas des fichiers périmés.

Vie privée et attentes des utilisateurs

Les fonctionnalités en arrière-plan doivent rester prévisibles. Les notifications push sont puissantes, mais les popups d'autorisation se prêtent facilement à l'abus.

Demandez la permission seulement quand il y a un bénéfice clair (par exemple après qu'un utilisateur a activé des alertes dans les paramètres), et expliquez ce qu'il recevra. Si vous synchronisez ou préchargez des données en arrière-plan, communiquez-le simplement—les utilisateurs remarquent une activité réseau inattendue ou des notifications.

Risques de performance à surveiller

Les workers ne sont pas « gratuits » en termes de performance. Leur surutilisation peut se retourner contre vous :

• Surcharge de messages : des postMessage fréquents (surtout avec de gros objets) peuvent devenir un goulot d'étranglement. Préférez le batching et l'utilisation d'objets transférables quand c'est pertinent.\n- Coût mémoire : chaque worker a son propre usage mémoire et un coût de démarrage ; trop de workers peut augmenter l'utilisation RAM et la consommation de batterie.\n- Croissance du cache : un Service Worker qui met en cache de manière agressive peut gonfler le stockage. Ajoutez des limites de cache et du nettoyage pendant les mises à jour.

Repli gracieux

Toutes les capacités ne sont pas disponibles partout (ou les utilisateurs peuvent bloquer des permissions). Faites de la détection de fonctionnalités et dégradez proprement :

if ('serviceWorker' in navigator) {
  // enregistrer le service worker
} else {
  // continuer sans fonctionnalités hors ligne
}

L'objectif : la fonctionnalité de base doit toujours marcher, avec les « plus » (hors ligne, push, calculs lourds) ajoutés quand ils sont disponibles.

Patterns courants qui utilisent les deux ensemble

Les Web Workers et les Service Workers résolvent des problèmes différents, donc ils se complètent bien quand une app a à la fois du calcul lourd et des chargements rapides/fiables. Un bon modèle mental : Web Worker = calcul, Service Worker = réseau + cache, thread principal = UI.

Pattern 1 : traitement d'images + galerie hors ligne

Supposons que votre app permet d'éditer des photos (redimensionner, filtres, suppression d'arrière-plan) et de voir une galerie plus tard sans connexion.

• Un Web Worker effectue le travail intensif CPU (décodage, transformation, génération de vignettes) pour que le défilement et les interactions restent fluides.\n- Un Service Worker met en cache les vignettes et originaux résultants dans Cache Storage (ou conserve des métadonnées dans IndexedDB) et les sert instantanément lors de visites répétées ou hors ligne.

Cette approche « calculer puis mettre en cache » garde les responsabilités séparées : le worker produit des sorties, et le service worker décide comment les stocker et les servir.

Pattern 2 : synchronisation de données + cache en arrière-plan

Pour des apps avec flux, formulaires ou données de terrain :

• Un Web Worker peut normaliser de gros payloads JSON, exécuter des diffs ou valider des données sans bloquer l'UI.\n- Un Service Worker peut mettre en cache les réponses API pour un démarrage rapide et gérer les lectures hors ligne. Quand la connectivité revient, il peut rafraîchir les caches et (lorsque supporté) coordonner une synchronisation en arrière-plan.

Même sans synchronisation complète en arrière-plan, un service worker améliore la vitesse perçue en servant des réponses en cache pendant que l'app met à jour en arrière-plan.

Séparer clairement les responsabilités

Évitez de mélanger les rôles :

• Thread UI : rendu, saisie utilisateur, accessibilité, liaison d'état minimale.\n- Web Worker : calcul pur et préparation de données (souvent via postMessage).\n- Service Worker : routage des requêtes, stratégie de cache, fallback hors ligne.

Checklist rapide : lequel vous faut-il ?

• La tâche est-elle lourde en CPU (parsing, encodage, crypto, traitement image/audio) ? Utilisez un Web Worker.\n- La tâche concerne-t-elle l'interception de fetch, le comportement hors ligne ou la mise en cache ? Utilisez un Service Worker.\n- Avez-vous besoin à la fois d'une UI réactive et d'un chargement rapide/hors ligne ? Utilisez les deux, mais gardez la frontière claire : calculez dans le web worker, stockez/servez via le service worker.

FAQ : questions pratiques fréquemment posées

Un Service Worker peut-il accéder au DOM ?

Non. Un Service Worker s'exécute en arrière-plan, séparé de tout onglet de page, et il n'a pas d'accès direct au DOM (aux éléments HTML de la page).

Cette séparation est volontaire : les Service Workers sont conçus pour continuer à fonctionner même lorsqu'aucune page n'est ouverte (par exemple pour répondre à un événement push ou pour servir des fichiers mis en cache). Parce qu'il peut ne pas y avoir de document actif à manipuler, le navigateur le garde isolé.

Si un Service Worker a besoin d'affecter ce que l'utilisateur voit, il communique avec les pages via des messages (par exemple postMessage) afin que la page mette à jour l'UI.

Ai-je besoin d'un Service Worker pour utiliser un Web Worker ?

Non. Les Web Workers et les Service Workers sont indépendants.

• Web Worker : pour déplacer le travail JavaScript lourd hors du thread principal (parsing, calculs, traitement d'images) et garder l'UI réactive.\n- Service Worker : pour des fonctionnalités au niveau réseau (mise en cache hors ligne, interception de requêtes, push, sync).

Vous pouvez utiliser l'un seul, l'autre, ou les deux selon les besoins de votre application.

Les workers sont-ils supportés partout ?

Dans les navigateurs modernes, les Web Workers sont largement supportés et constituent généralement un choix de base sûr.

Les Service Workers sont également largement supportés dans les versions récentes des principaux navigateurs, mais ils ont plus d'exigences et de cas limites :

• Ils nécessitent HTTPS (sauf localhost pour le développement).\n- Certaines fonctionnalités (comme les notifications push) varient selon le navigateur et la plateforme.

Si la compatibilité large est importante, considérez les Service Workers comme une amélioration progressive : construisez d'abord une bonne expérience de base, puis ajoutez le hors ligne/push là où c'est disponible.

Est-ce que cela rendra mon site automatiquement plus rapide ?

Pas automatiquement.

• Un Web Worker aide quand votre site est ralenti par du JavaScript intensif sur le thread principal. Déplacer ce travail peut réduire le jank et améliorer la réactivité—mais vous payez toujours un coût en passage de messages.\n- Un Service Worker aide quand votre site est ralenti par des requêtes réseau. La mise en cache et la gestion intelligente des fetchs peuvent rendre les visites répétées instantanées—mais mettre en cache les mauvaises choses peut causer des contenus périmés.

Les vrais gains viennent d'utiliser le bon worker pour le bon goulot d'étranglement, et de mesurer avant/après.