En bref
À retenir
- Un fichier à 60 images par seconde ne prouve pas que 60 images distinctes ont été capturées. Le mouvement, le son et leur synchronisation doivent traverser toute la chaîne d’enregistrement.
- Laissez la page dire quand démarrer et arrêter l’enregistrement. Attendre un nombre de secondes fixe finira par casser.
- Un rendu qui renvoie un fichier peut quand même être raté. Comptez les images perdues et renvoyez-les avec la vidéo.
Ce qu’enregistrer une page web implique vraiment
Un navigateur est déjà un bon outil de dessin. Le CSS anime, le Canvas dessine image par image, le WebGL gère les scènes 3D et l’API Web Audio produit du son. Si vous savez construire une page web, vous savez construire le contenu d’une vidéo : une explication animée, une visualisation de données, une démo produit, une chaîne qui publie toute seule.
Charger la page, c’est la partie facile. La partie difficile, c’est de capturer ce que vous voyez sans changer la façon dont le navigateur le dessine. Le GPU doit rester dans la boucle, la cadence doit rester stable, le son doit rester synchronisé, et quelque chose doit savoir quand la page est réellement prête.
Il faut aussi remarquer que deux métiers différents se cachent derrière la même recherche. Filmer quelqu’un qui navigue sur un site, c’est de la capture d’écran. Rendre une page conçue pour être une vidéo, cela ressemble davantage à une ferme de rendu. Pagecorder fait le second.
Pourquoi une simple capture d’écran ne suffisait pas
L’ancien mécanisme de screencast de Puppeteer illustre l’écart entre filmer un test de navigateur et produire une vidéo. Il reçoit des images PNG via le Chrome DevTools Protocol, décode leur transport en base64 dans Node.js et les transmet à un processus FFmpeg séparé. Cet enregistreur désactive explicitement le son et utilise un encodage VP9 logiciel. Une page rendue par le GPU ne transforme pas cette chaîne de transferts d’images en capture matérielle sans copie.
Son réglage de cadence définit la chronologie du fichier de sortie. L’enregistreur répète les images capturées pour combler les intervalles entre leur arrivée. Un fichier annoncé à 60 images par seconde peut donc contenir moins de 60 captures distinctes par seconde : répéter une image ne restitue pas un mouvement manqué. Enregistrer dans la page avec MediaRecorder ou canvas.captureStream est une autre piste, mais combiner HTML ordinaire, plusieurs canvas et son demande aussi de concevoir la capture.
Pagecorder a été conçu pour l’enregistrement complet : rendu GPU, capture native de l’écran et du son à 60 images par seconde, puis livraison d’un MP4 via une API. La page décide du début et de la fin. Les travaux peuvent utiliser une archive contenant la page et ses ressources, et le résultat comprend les images perdues, les erreurs HTTP et les journaux de console. Ce sont des exigences de capture, pas des options qu’un changement de format fournit.
- Capturer le mouvement, pas seulement afficher la cadence demandée dans les métadonnées.
- Faire fonctionner ensemble le rendu du navigateur, l’encodage vidéo et la synchronisation du son.
- Fournir les images manquées et les erreurs de la page avec la vidéo terminée.
Puppeteer a depuis ajouté une API distincte, Page.record, avec des options audio. Les limites ci-dessus concernent son ancien screencast PNG vers FFmpeg, pas toutes les méthodes actuelles. Une option d’API ne démontre pas à elle seule une qualité ou des performances de capture équivalentes.
Laissez la page décider du départ
Un enregistreur ne peut pas deviner quand votre animation est prête. Un réseau silencieux ne signifie pas que les polices sont posées, que les données ont fini de charger dans un worker, ou que l’animation a commencé. Démarrer cinq secondes après le chargement ne règle rien : cela déplace le problème là où il se verra moins.
Pagecorder fournit un point d’accroche pour démarrer et arrêter l’enregistrement lorsque la page est prête. Les appels optionnels ci-dessous sont ignorés lorsque ce point d’accroche est absent dans un navigateur normal. Ici, runAnimation représente votre propre fonction d’animation, qui renvoie une promesse résolue à la fin.
<script>
window.pagecorder?.('start');
runAnimation().then(() => {
window.pagecorder?.('stop');
});
</script>Attendez ce qu’un spectateur remarquerait réellement, pas simplement la fin du chargement.
À 60 images par seconde, vous avez 16 millisecondes
Soixante images par seconde, cela veut dire environ 16,7 millisecondes par image. La mise en page, votre JavaScript, le dessin, le travail GPU, la relecture de l’image et son encodage doivent tous tenir dans cette fenêtre. Une page parfaitement fluide sur votre portable peut très bien perdre des images une fois rendue en 4K avec un encodeur qui tourne à côté.
Les conseils habituels s’appliquent. Animez les transformations et l’opacité plutôt que ce qui force un recalcul de mise en page, sortez le travail de la boucle d’animation, et profilez les scènes Canvas ou WebGL lourdes à la taille réelle d’export. Mais l’enregistreur a une deuxième mission : remarquer ce qui a mal tourné. Une requête qui renvoie un fichier n’est pas un succès si cinquante images ont disparu en route.
Pagecorder renvoie donc, avec le MP4, l’horodatage des images perdues, les requêtes en échec et la console du navigateur. On passe de « la vidéo saccade » à « quelque chose a lâché à 14 secondes, et voilà ce dont la page se plaignait ».
Gardez le navigateur et l’encodeur côte à côte
Tout est parti d’un manque. Prendre des captures d’écran avec de l’automatisation de navigateur était facile ; déplacer des milliers d’images haute résolution entre processus assez vite pour les encoder ne l’était pas. La version qui tourne aujourd’hui utilise Chromium avec le GPU activé et parle directement aux bibliothèques de FFmpeg depuis du C++, au lieu d’appeler l’outil en ligne de commande.
L’idée derrière tout cela est simplement d’arrêter de copier. Chaque fois qu’une image passe de la carte graphique à la mémoire principale, franchit une frontière de processus puis entre dans un encodeur, elle passe son temps à être transportée plutôt que compressée. Rapprocher la capture et l’encodage laisse davantage de ces 16 millisecondes à la page elle-même.
Le son ajoute une deuxième horloge. Les images et les échantillons doivent s’accorder sur une même ligne de temps, survivre au tampon de l’encodeur et se terminer ensemble. Un pipeline qui ne gère que la vidéo paraît parfait sur un test de cinq secondes et dérive franchement sur un rendu de dix minutes.
Envoyez la page entière, pas seulement un lien
Pointer le moteur de rendu vers une URL publique est pratique, mais cela rend le résultat dépendant du DNS, de la vitesse du CDN, des limites de débit et de la version du site déployée ce jour-là. Une police qui ne charge pas ou une image qui arrive en retard change à la fois l’allure de la vidéo et sa durée.
Pagecorder accepte donc aussi une archive ZIP contenant la page et tout ce dont elle a besoin, servie localement le temps du travail. L’essentiel de la variabilité réseau disparaît, un rendu ancien peut être refait des années plus tard, et vous obtenez un fichier qui décrit exactement ce qui a été rendu plutôt que l’endroit où le moteur devait aller chercher.
Une simple URL reste le bon choix pour un coup unique. Pour tout ce que vous produisez de façon répétée, l’archive se comporte davantage comme un fichier source.
Le construire ou le payer
Le construire vous-même signifie prendre en charge la chaîne de capture, pas simplement appeler une API de navigateur. Il faut tester les images réellement distinctes, la synchronisation du son, le comportement du GPU et la qualité de sortie à la résolution et sur la durée prévues. Viennent ensuite les mises à jour du navigateur, les changements d’encodeur et les pannes qui n’apparaissent que sous charge.
Pagecorder place ce travail derrière une API de rendu. Envoyez une URL ou une archive ZIP, laissez la page signaler son début et sa fin, puis récupérez le MP4 et les diagnostics d’enregistrement. Le service s’adresse aux produits qui doivent générer de la vidéo sans construire et exploiter leur propre infrastructure de navigateurs et d’encodeurs.
Je ne peux pas citer les clients de Pagecorder, mais les usages reviennent : chaînes YouTube automatisées, formats courts pour les réseaux, démos produit, tableaux de bord transformés en vidéos, motion design réalisé par des gens qui connaissent déjà le CSS. Tous composent dans un navigateur et laissent le rendu à l’infrastructure de quelqu’un d’autre.
