Connexion Premium

Firefox 141 pour Windows intègrera l’API WebGPU

En retard, mais pas le dernier

Firefox 141 pour Windows intègrera l’API WebGPU

La prochaine version du navigateur, prévue pour le 22 juillet, prendra en charge une API graphique dont le développement est le fruit d'un effort collectif. Bien que Chrome en soit doté depuis longtemps, l'arrivée de WebGPU dans Firefox reste un petit évènement.

Le 17 juillet 2025 à 07h46

« Après des années de développement, nous allons lancer WebGPU sur Windows dans Firefox 141 ! », s’est exclamé hier l’équipe Mozilla GFX. Cette API, qui prend la suite de WebGL, fournit un accès beaucoup plus direct aux capacités des GPU. À la clé, des améliorations importantes de performances, aussi bien sur les calculs graphiques que sur d’autres liés à l’IA, dont l’inférence.

Millefeuille graphique

Cette interface de programmation est le fruit d’un effort conjoint au sein du W3C et réunissant des entreprises comme Mozilla, Apple, Intel et Microsoft, l’ensemble étant largement tracté par Google. L’objectif était de donner aux navigateurs un accès plus moderne au matériel, dans le sillage des API de bas niveau apparues sur les différentes plateformes. WebGPU dépend d’ailleurs de ces dernières, en fournissant un lot de capacités, selon son implémentation bien sûr.

L’ensemble n’est pas si simple. Sur toute plateforme, on trouve ainsi le pilote responsable de l’exploitation du GPU. Charge à lui d’exposer de transmettre les instructions à la puce. Au-dessus, l’API graphique native (Vulkan sur Linux par exemple) est une autre brique essentielle. Dans un système d’exploitation, elle expose les capacités, dans lesquelles les applications vont venir piocher. Puis vient WebGPU dans le navigateur ou, plus précisément, son implémentation. C'est elle qui créera des appareils logiques (logiciels) pour chaque application en ayant besoin.

Si vous utilisez Chrome ou un navigateur basé sur Chromium, vous pouvez déjà observer les possibilités de WebGPU via le site dédié. Chrome fournit en effet cette capacité depuis deux ans. Pourquoi tout ce temps chez Mozilla ? On ne sait pas exactement, mais Google y a consacré davantage de moyens, la plateforme web représentant le cœur de ses activités. Apple, bien qu’ayant participé au développement de l’API, ne l’intègrera que dans Safari 26 cet automne.

Il reste « beaucoup de travail »

Selon Mozilla, WebGPU est une API « vaste et complexe ». Les effets ont été concentrés assez logiquement sur les fonctions les plus évidentes, afin « que les applications et démonstrations WebGPU à haute visibilité fonctionnent sans problème ». Selon Mozilla, tout devrait donc bien se passer dans la plupart des cas.

L’équipe explique également qu’il reste « beaucoup de travail », aussi bien sur les performances que la conformité avec la spécification. Par exemple, le navigateur utilise une communication inter-processus sans tampon pour transmettre les requêtes à la sandbox du GPU. Ce problème a déjà été corrigé, mais la solution ne sera déployée que dans Firefox 142, avec des gains significatifs de performances.

En outre, le navigateur ne dispose pas d’un moyen moderne de savoir quand un GPU a terminé une opération et introduit des intervalles pour vérifier, ce qui entraine des latences. Les développeurs se penchent actuellement sur le problème et explorent diverses solutions. De même, Firefox ne prend pas encore en charge la méthode importExternalTexture de WebGPU, qui permet au GPU la lecture vidéo décompressée directement depuis le décodeur.

Windows d'abord, les autres d'ici la fin de l'année

Le support de WebGPU ne sera également disponible que pour Windows lorsque Firefox 141 sera disponible le 22 juillet. Une question de priorité pour Mozilla : c’est là que se trouve l’écrasante majorité des utilisateurs. L’équipe précise cependant que des versions Mac et Linux sont prévues « dans les mois à venir » et qu’il est possible de les tester dans le canal Nightly du navigateur. Le support sera aussi étendu à Android.

Enfin, Mozilla indique que l’implémentation de WebGPU dans Firefox est basée sur WGPU, un projet indépendant et écrit en Rust. Il permet d’offrir une interface unifiée pour exposer les capacités sous-jacentes des API bas niveau en fonction de la plateforme utilisée : Direct3D 12 sur Windows, Metal sur macOS et Vulkan sur Linux. Mozilla contribue activement au projet, évoque une communauté très vivante et invite les personnes intéressées à se pencher sur WGPU pour participer à son développement.

Commentaires (28)

votre avatar
ça peut être intéressant mais quid de la sécurité ? mozilla s'est manifestée contre l'implémentation bas niveau qu'est webusb, ici les risques sont tout aussi importants.
votre avatar
Pourquoi DX12 sous Windows alors que Vulkan est disponible ?
De cette façon, on ne développe l'utilisation que d'une seule librairie pour 2 OS ... on y gagne (ou pas, n'oublions pas que MS et les normes ça a toujours fait 2)
votre avatar
Probablement parce DX12 est plus utilisé et qu'il est donc probable que les drivers des cartes resteront mieux maintenus pour utiliser DX12 que Vulkan.
votre avatar
Conformisme morbide ?
votre avatar
des performances en + à attendre sur la navigation?
mon firefox galère souvent sur YouTube
votre avatar
Probablement rien a attendre de YouTube. De ce qu'on a pu voir ces dernière années, Google fait volontairement en sorte d'optimiser ses sites uniquement pour Chrome et d’éviter soigneusement toutes les optimisations qui pourraient profiter à d'autres navigateurs.
C'est pour cela que Microsoft à jeté l'éponge et est passé sous Blink plutôt que de développer son propre moteur.
votre avatar
J'espère qu'il y aura une option d'activation/désactivation.
Normalement c'est le cas par site pour les API audio, video, geolocalisation, usb, etc.
votre avatar
Pareil, je suis pas super chaud pour qu'un navigateur ai directement accès à des api bas niveau. Ca sent la porte d'entrée pour tout un tas de problème de sécurité.
votre avatar
Vu que WebGL, webRTC et compagnie sont désactivables depuis about:config, je pense que oui. Mais probablement pas depuis l'interface graphique.
votre avatar
Au vu des fonctionnalités montrées sur le site de démo, à part pour un site où le développeur et/ou designer veut montrer qu'il maîtrise l'animation je n'arrive pas à trouver d'exemple commun concret de l'utilisation de ce genre de technologie. Serait-il plus simple de miner de la crypto depuis le navigateur ? :mad2:
votre avatar
Du jeu vidéo 3D dans un navigateur peut être ?
votre avatar
Et, sincèrement, je trouve ça étrange qu'un navigateur ressemble de plus en plus à un OS... Cela me fait bizarre, cela me laisse perplexe, voire sceptique ... J'ai l'impression qu'on réinvente tout.
votre avatar
Je me faisais la réflexion suivante ce matin : l'OS devient un hyperviseur. Le navigateur des VM invités...
votre avatar
Perso ça fait des années que ça me saoule de voir qu'on ne sait plus concevoir un logiciel sans devoir empiler trente mille couches et démarrer le moteur javascript de Chrome.

Le navigateur est devenu un OS dans l'OS et en matière de surface d'attaque, c'est juste une horreur.
votre avatar
C'est un genre de gros container sandbox avec un accès très monitoré au système et ses périphériques. En plus rien besoin d'installer, les navigateurs sont déjà partout. Ça ne m'étonnerait pas que Google ait ça en tête depuis des années.

Et franchement, qui va s'en plaindre, a part quelques techs un peu pointilleux (dont je fais partie) ? Sécurité, accessibilité, mode session privée, même configuration de l'application partout,...
votre avatar
Et franchement, qui va s'en plaindre, a part quelques techs un peu pointilleux (dont je fais partie) ? Sécurité, accessibilité, mode session privée, même configuration de l'application partout,...
Perso, ce qui me dérange le plus, ce n'est pas le côté tech, c'est le côté "il faut une connexion pour tout". Et une connexion haut débit si on souhaite que ce soit "utilisable".

C'est bête, mais aujourd'hui, j'ai plus de connexion internet (panne, déplacement, que sais-je), ben je peux travailler malgré tout. Sans doute moins efficacement sans l'accès à un moteur de recherche, mais je peux toujours développer mes applications. Car je peux faire ça "offline", rédiger des mails, lire des documents Word, Excel, etc.

En théorie, on peut faire du offline avec du web (via les WPA). En pratique, j'ai rarement vu un cas vraiment fonctionnel. Et encore faut-il avoir accédé à l'application avant, etc.

Quand je vois des boites basées sur du Citrix ou techno équivalent être totalement à l'arrêt dans une agence car la connexion internet est indisponible, ou que le serveur central a laché, ça fait mal. Et ça arrive régulièrement.

Pour prendre un exemple d'une boite du domaine de la sécurité industrielle (dont je tairai le nom), une amie qui travaille là-bas a fait le bilan sur l'année 2024. 11j au total où elle n'a pas pu travailler du tout, car son outil de travail était indisponible faute de connexion internet. Parfois cela ne concernait que son agence, parfois cela concernait toute la boite.

Ce que je trouve dommage, c'est que la simplification technique apportée par le mode SaaS se traduit par une dépendance totale à la connectivité, y compris pour des activités qui ne nécessite pas, de base, une connexion internet...

Je ne parle pas non plus des applications qui au final sont des gouffres à cycle CPU et où tu as intérêt à avoir un PC puissant pour les utiliser à peu près correctement....
votre avatar
Ha oui je suis tout à fait d'accord avec toi, mais la majorité des gens (perso) et des boites (coûts) sont pour ce système. Et personne n'est dérangé par le poids des apps web. Donc bon... En perso la connexion internet qui saute j'ai pas eu ça depuis longtemps, et la "simplicité" vaut le "risque".

Encore une fois ce n'est pas mon avis, je préfère de loin la ligne de commande en local 🤣 Mais bon je ne représente pas une majorité et toi non plu ^^
votre avatar
Le javascript tourne parfaitement en local: WebGPU (et les API locales) vont dans ce sens: le calcul est fait localement, un jeu qui préchargerait ses textures pourrait très bien fonctionner 100% hors ligne.
Concernant les sites web dépendants à une connexion, c'est en partie dû aux développeurs qui ne savent plus coder sans entasser des librairies, utiliser des CDNs pour-que-ça-aille-plus-vite ou appeler des API cloudées pour tout et n'importe quoi... (spoiler: l'IA doit pousser ce type de dev, donc c'est pas pret de s'arranger)
LocalStorage permet de stocker une tonne d'info, tu peux très bien mettre en cache local toutes les infos, et enregistrer les modifs quand la connexion est disponible.
votre avatar
Concernant les sites web dépendants à une connexion, c'est en partie dû aux développeurs qui ne savent plus coder sans entasser des librairies, utiliser des CDNs pour-que-ça-aille-plus-vite ou appeler des API cloudées pour tout et n'importe quoi... (spoiler: l'IA doit pousser ce type de dev, donc c'est pas pret de s'arranger)
C'est vrai. Mais c'est aussi surtout du fait que pour pouvoir faire une application web disponible sans connexion, il faut passer par un webworker. Cela change drastiquement la manière de concevoir une application.
LocalStorage permet de stocker une tonne d'info
Non. LocalStorage est limité à quelques Mo (généralement 5). Dès que tu stockes tout en cache, tu atteints très vite cette limite.

Il existe d'autres moyens de stockage, mais qui ne sont pas forcément dispo côté web (par ex, car il faut un service worker) ou facile d'usage car "très bas niveau" (pour un dev JS).
votre avatar
Bah 5mo pour stoker de la data de site c'est déjà beaucoup en fait :
Imaginons stocker les données utilisateur du site next en localStorage :
- les param utilisateurs : thème sombre, nombre d'articles par page... (quelques octets)
- la liste des id d'utilisateurs bannis, c'est un tableau d'entier donc quelques ko au maxi
- la liste du dernier commentaire lu par article là c'est 2 entiers (un id article etun id du dernier comm) par news lue ça doit faire de quoi mémoriser ~2millions d'historiques d'articles :D

Après effectivement c'est pas non plus un cache: le navigateur fait le taf tout seul pour ça.
Si tu commences à y stocker les textes des articles ça marchera moins bien, si tu mets les belles images de Floc en base64 : tu n'en stoqueras qu'une avant saturation :D

Bon localStorage à un gros défaut : c’est comme son nom l'indique local à la machine, donc tu ne retrouverais pas ton histo depuis un autre PC ou tel :'(
votre avatar
Après effectivement c'est pas non plus un cache: le navigateur fait le taf tout seul pour ça.
Si tu commences à y stocker les textes des articles ça marchera moins bien, si tu mets les belles images de Floc en base64 : tu n'en stoqueras qu'une avant saturation :D

Le navigateur ne fait pas tout tout seul. Il fait des trucs, mais c'est pas pour autant que ça fonctionne (sur les assets statiques, en général, ça marche plutôt bien, mais pas pour le contenu).

Maintenant, si l'objectif est d'avoir un accès hors ligne à l'application, ben il faut bien stocker les info. Donc articles & images ;)

Non, franchement, localStorage pour un accès hors ligne, c'est juste insuffisant dans la plupart des cas.
votre avatar
Le navigateur fait ce que lui dit le serveur : le contenu dynamique est généralement volontairement étiqueté côté serveur en "Pragma: no-cache" ou "Cache-control: no-cache". Si tu mets autre chose (par exemple "Cache-control: max-age=604800") ton site marchera hors ligne pendant 7j (604800 secondes)...
Pas besoin de localeStorage pour stocker le cache.
votre avatar
pour un site entièrement statique oui. Sauf que les sites entièrement statiques, c'est hyper rare de nos jours.
votre avatar
Microsoft voulait non emmener dans sont monde où tout marche sous Windows, Google va nous emmener dans celui où tout passe par son navigateur.
votre avatar
archive.org Archive.org appuie sur le bouton power :D (sur pc)
votre avatar
Va t on avec ça rentrer dans une nouvelle air du web ; après les financements par clic pub, puis partage de données personnelles, l'arrivée massive du minage GPU dans le navigateur ???
votre avatar
l'arrivée massive du minage GPU dans le navigateur ???
Pour le coup, le javascript qui minait et faisait hurler le CPU était déjà une réalité. :craint:
votre avatar
Et concrètement, ça va permettre d’accélérer des sites web actuels ?
Genre Google maps, avec les bâtiments en 3D quand on se rapproche, ou les sites webs plus classiques mais utilisant une palanquée d'effets de transparence ou de défilement.

Firefox 141 pour Windows intègrera l’API WebGPU

  • Millefeuille graphique

  • Il reste « beaucoup de travail »

  • Windows d'abord, les autres d'ici la fin de l'année

Fermer