Optimiser l’IA côté client dans le navigateur
Faites tourner des modèles d'IA dans le navigateur sans ralentir vos pages : taille des modèles, mise en cache, web workers et expérience utilisateur fluide.
La plupart des fonctionnalités d’IA reposent sur des serveurs, mais l’IA côté client s’exécute directement dans le navigateur du visiteur. Les avantages sont réels : faible latence, coûts serveur réduits, pas de clé API à gérer, meilleure confidentialité et accès hors connexion. Des bibliothèques comme TensorFlow.js, Transformers.js ou MediaPipe GenAI rendent cette approche accessible, à condition de maîtriser les fondamentaux de la performance.
Le revers concerne la performance, et donc le SEO : le visiteur télécharge des fichiers plus lourds et son navigateur travaille davantage. Un modèle mal géré peut figer le thread principal, dégrader l’INP et ruiner l’expérience. La question préalable est simple : l’IA côté client est-elle vraiment adaptée à votre fonctionnalité, et avez-vous prévu une solution de secours ?
L’IA côté client est séduisante pour la latence et la confidentialité, mais on oublie vite qu’on demande au visiteur de télécharger un modèle parfois lourd et de faire chauffer son appareil. Mon parti pris est clair : vérifiez l’appareil et pesez la taille du modèle avant de l’imposer à tout le monde. Une inférence qui gèle l’interface, c’est un INP catastrophique et une expérience que Google constatera.
Avant le téléchargement : peser la taille du modèle
La taille du modèle est déterminante. Une règle empirique utile situe le seuil de vigilance autour de 5 Mo, qui correspond au 75e centile du poids des pages, 10 Mo étant un repère plus souple. Beaucoup de modèles spécialisés sont étonnamment légers, tandis que les modèles d’IA générative dépassent largement le poids raisonnable d’une page Web. Préférez toujours un modèle spécialisé dans votre tâche plutôt qu’un grand modèle généraliste : il sera plus petit et souvent suffisant.
| Modèle (exemple) | Taille approximative | Lecture pour le Web |
|---|---|---|
BudouX (césure de texte) |
9,4 ko en GZIP |
Très léger, négligeable |
Détection de langue MediaPipe |
315 ko |
Léger, sans souci |
Handpose (vision) |
13,4 Mo |
Comparable à une page médiane |
DistilBERT (NLP / petit LLM) |
67 Mo |
Au-delà du raisonnable pour le Web |
Gemma 2B (petit LLM) |
1,3 Go |
Plus de 100 fois une page médiane |
Vérifier l'appareil et limiter les téléchargements
Tous les appareils ne peuvent pas exécuter un modèle. À défaut de méthode fiable avant téléchargement, vous pouvez détecter la compatibilité WebGPU et estimer la puissance disponible via Navigator.hardwareConcurrency, Navigator.deviceMemory ou l’API Compute Pressure, en gardant en tête que ces signaux sont volontairement imprécis. Côté téléchargement, ne récupérez le modèle que lorsque la fonctionnalité va servir, mettez-le explicitement en cache avec l’API Cache, utile aussi hors connexion, pour éviter de le retélécharger, et découpez les gros fichiers en plusieurs morceaux.
Télécharger sans bloquer le visiteur
Pendant le téléchargement, ne bloquez jamais les fonctions essentielles : l’utilisateur doit pouvoir continuer à agir même si le modèle n’est pas prêt. Affichez une progression claire et le temps restant, et gérez proprement les coupures réseau en reprenant le téléchargement une fois la connexion rétablie. Les étapes de préparation du modèle, coûteuses, doivent être déportées vers un web worker pour ne pas figer l’interface.
// Estimer la puissance de l'appareil avant de charger un modèle
if (navigator.hardwareConcurrency && navigator.hardwareConcurrency >= 4) {
// Appareil suffisamment puissant : on peut envisager le téléchargement
}
// Mettre le modèle en cache pour éviter de le retélécharger
const cache = await caches.open('ai-models');
const response = await fetch('modele.bin');
await cache.put('modele.bin', response.clone());Pendant l'inférence : préserver la réactivité
L’inférence, c’est le moment où le modèle produit un résultat à partir d’une entrée. Elle peut être coûteuse et, comme toute longue tâche, peser sur la réactivité. Si elle s’appuie sur le GPU via WebGPU ou WebGL, elle s’exécute dans un processus distinct sans bloquer l’interface. Pour les implémentations sur processeur, déportez l’inférence vers un web worker. Encadrez systématiquement le code par des blocs try/catch, gérez les erreurs WebGPU, indiquez à l’utilisateur que le modèle réfléchit, et rendez l’inférence annulable pour ne pas gaspiller de ressources sur une réponse qui ne sera pas lue.
Les étapes de préparation et l’inférence sur processeur peuvent bloquer le thread principal et provoquer une page saccadée, ce qui dégrade l’INP. Déportez ces tâches vers un web worker. Prévoyez toujours un plan de secours : un appareil peut lancer un autre processus gourmand après vos vérifications, et un GPUDevice.lost peut survenir à tout moment.
À faire
- choisir un modèle spécialisé et léger
- télécharger seulement au besoin
- mettre en cache avec l’API Cache
- déporter préparation et inférence vers un web worker
- afficher la progression
À éviter
- charger un gros modèle par défaut
- bloquer les fonctions clés pendant le téléchargement
- exécuter l’inférence sur le thread principal
- ignorer les coupures réseau et les erreurs WebGPU
Points clés à retenir
- Vérifiez que l'IA côté client convient à votre cas d'usage et prévoyez un secours
- Privilégiez les modèles spécialisés, plus petits, et mesurez leur poids réel
- Ne téléchargez le modèle qu'au moment utile et mettez-le en cache
- Déportez préparation et inférence vers un web worker
- Affichez la progression et rendez l'inférence annulable
L’IA côté client n’est un atout que si elle ne dégrade pas la performance perçue.
Quiz : testez vos connaissances
Quiz : testez vos connaissances
-
Quel est un avantage réel de l'IA exécutée côté client, dans le navigateur ?
- Aucune contrainte de taille, quel que soit l'appareil
- Un modèle toujours plus précis qu'une IA hébergée sur serveur
- Une faible latence et aucune clé API à gérer
L’IA côté client offre une faible latence, des coûts serveur réduits, aucune clé API à gérer, une meilleure confidentialité et un accès possible hors connexion.
-
Où exécuter la préparation et l'inférence d'un modèle pour préserver la réactivité de la page ?
- Sur le thread principal, c'est plus rapide
- Dans un web worker, pour ne pas bloquer le thread principal
- Toujours sur le serveur, l'inférence locale est impossible
La préparation et l’inférence sur processeur peuvent bloquer le thread principal et dégrader l’INP. Les déporter vers un web worker préserve la réactivité.
-
Comment gérer le téléchargement d'un modèle d'IA côté client ?
- Bloquer la page tant que le modèle n'est pas prêt
- Le télécharger seulement au besoin, sans bloquer les fonctions essentielles
- Charger le modèle le plus gros par défaut, au cas où
Il vaut mieux télécharger le modèle uniquement quand il est utile et laisser l’utilisateur continuer à agir, même si le modèle n’est pas encore prêt.
À propos de l'auteur
Besoin d'un accompagnement SEO ?
Vous intégrez de l'IA dans le navigateur et craignez pour vos performances ? Évaluons ensemble l'impact sur votre vitesse.