Ce que vous apprendrez
JavaScript peut créer d'excellentes expériences, mais il peut également cacher les informations dont un client a besoin derrière les offres groupées lentes, les défaillances côté client, les mises en page instables et les retards d'interaction. L'objectif n'est pas d'éviter JavaScript. Il s'agit de décider quelles informations doivent arriver rapidement et de manière fiable, puis de prouver qu'elles arrivent.
Pourquoi ce travail est important : Créez des expériences JavaScript et mobiles rapides et fiables
Une page peut bien paraître sur l'ordinateur portable rapide d'un développeur tandis qu'un client sur un réseau mobile voit une coque vide, des boutons mobiles ou un filtre inutilisable. Le même écart peut affecter ce qu'un robot d'exploration peut analyser. La performance est donc un problème d'expérience client et de fiabilité opérationnelle, et non une poursuite décorative du score.
Les équipes techniques ont besoin de preuves spécifiques. « Rendez-le plus rapide » n'est pas un ticket. « La page de catégorie de produits attend 4,2 secondes pour afficher son prix principal et le bouton du filtre se déplace après l'hydratation sur les appareils Android de milieu de gamme » donne à l'ingénierie un problème qu'ils peuvent inspecter.
Idées clés : Créez des expériences JavaScript et mobiles rapides et fiables
La stratégie de rendu suit la criticité du contenu
Contenu de rendu serveur ou pré-rendu qui est essentiel pour comprendre une page : titre, réponse principale, prix ou disponibilité le cas échéant, navigation, liens principaux et faits structurés. Le rendu client peut améliorer les outils interactifs, mais un shell vierge est un point de départ fragile pour les informations clés.
Utilisez-le quand : Si JavaScript échoue ou est lent, un client peut-il toujours comprendre la page et accéder à ses liens essentiels ?
Mesurer l'expérience sur le terrain ainsi que les tests de laboratoire
Les outils de laboratoire reproduisent des conditions contrôlées et aident à isoler les causes. Les données sur le terrain reflètent les appareils, les réseaux et les comportements réels. Utilisez les deux : les données sur le terrain identifient la population touchée ; les tests de laboratoire aident les ingénieurs à reproduire et à améliorer une défaillance spécifique.
Utilisez-le quand : Savez-vous si le problème affecte les utilisateurs réels, quelles pages et quels segments d'appareils ou de réseau ?
La stabilité de la mise en page est une promesse
Préserver les dimensions pour les images, les publicités, les intégrations, les bannières de consentement et les composants à chargement tardif. Lorsqu'un bouton se déplace sous le pouce de quelqu'un, la page rompt une promesse d'interaction de base, même si la conception visuelle finale semble correcte.
Utilisez-le quand : Un utilisateur peut-il appuyer ou lire le contenu principal sans que l'interface ne saute après le chargement ?
Les états d'erreur font partie de l'indexabilité et de l'UX
Le délai d'attente des API expire, les données de stock échouent, l'authentification expire et les scripts sont bloqués. Une page robuste montre un état d'erreur honnête, préserve la navigation, signale les erreurs et évite de servir une page de réussite apparente avec un contenu de base manquant.
Utilisez-le quand : Qu'est-ce qu'un client voit lorsque la demande critique du client échoue, et peut-il encore prendre une prochaine étape raisonnable ?
Étapes pratiques : Créez des expériences JavaScript et mobiles rapides et fiables
- 01
Choisissez un parcours mobile représentatif
Sélectionnez une page et une tâche de grande valeur, comme trouver le prix d'un produit, comparer les plans, soumettre un formulaire d'éligibilité ou ouvrir un article d'aide sur un téléphone de milieu de gamme.
- 02
Capturez le document initial
Inspectez la réponse avant la fin des scripts du client. Vérifiez le titre de la page, l'en-tête principal, le contenu principal, la navigation, les signaux canoniques et les liens internes significatifs.
- 03
Suivre le chemin de rendu et de réseau
Identifiez les ressources de blocage du rendu, les paquets lourds, les demandes en double, les API lentes, les scripts tiers, les retards de police, le chargement d'images et le travail d'hydratation qui bloque l'interaction.
- 04
Test sous des contraintes réalistes
Utilisez les paramètres du réseau limité et du processeur, un appareil physique si possible, la navigation au clavier, un mouvement réduit et des largeurs d'écran étroites. Enregistrez l'échec exact plutôt qu'un score vague.
- 05
Définir les budgets de performance
Convenez des budgets spécifiques à la page pour la réponse critique, la visibilité du contenu principal, les changements de mise en page, le délai d'interaction, le poids JavaScript, le coût de l'image et l'impact des tiers. Les budgets doivent protéger la tâche d'un client, et non poursuivre un numéro.
- 06
Navire, observer et se protéger contre les régressions
Libérez le plus petit correctif, suivez les données de terrain et les erreurs par modèle de page, annotez le déploiement et ajoutez des contrôles automatisés ou manuels pour détecter le même échec la prochaine fois.
Atelier guidé
Valider une page JavaScript en tant que client et un robot d'exploration la rencontrerait
Votre livrable : Un mémoire de validation JavaScript et mobile couvrant le HTML initial, le contenu rendu, les liens, les erreurs, les performances et les vérifications de version.
Scénario de pratique
Scénario pratique : une page de tarification SaaS a été repensée en tant qu'application rendue par le client. La conception visuelle semble correcte après le règlement de la page. Sur une connexion mobile lente, cependant, la comparaison des prix apparaît tardivement, la FAQ nécessite un script qui échoue parfois, et les liens internes ne sont créés qu'après l'interaction de l'utilisateur.
L'équipe évite de traiter JavaScript comme intrinsèquement mauvais. Il identifie ce qui est essentiel pour comprendre l'offre et ce qui peut améliorer l'expérience en toute sécurité. Il compare la réponse initiale avec la page rendue, teste l'itinéraire important sur un périphérique contraint et vérifie comment les erreurs se comportent lorsque les données ne sont pas disponibles.
Le résultat est un mémoire de publication avec quelques non négociables : l'offre principale et les liens utiles sont présents dans la réponse principale lorsque c'est pratique, la page reste utilisable pendant le chargement, et les états d'erreur indiquent à une personne quoi faire ensuite.
Construisez-le étape par étape
Définir l'essentiel de la page
Énumérez les informations, la navigation, la preuve et l'action dont un visiteur a besoin avant la fin d'un script. Incluez le titre de la page, le titre principal, la réponse de base, les liens pertinents, le prix ou le contexte de disponibilité et l'action accessible.
- Enregistrement
- Une liste de contenu essentiel
- Décision qu'il soutient
- Ce qui doit être protégé dans l'expérience initiale
- Risque à vérifier
- Appeler chaque amélioration visuelle essentielle
Comparer la réponse et la page rendue
Inspectez ce qui arrive dans le HTML initial et ce qui apparaît après l'exécution des scripts. Enregistrez les différences de contenu, de liens, de faits canoniques, structurés, d'erreurs et de contrôles utilisateur. Utilisez la même URL et les mêmes conditions d'appareil.
- Enregistrement
- Une comparaison brute contre rendue
- Décision qu'il soutient
- Quels éléments essentiels dépendent du rendu tardif
- Risque à vérifier
- En supposant que la vue visuelle du navigateur montre l'ensemble du chemin de livraison
Tester les conditions mobiles contraintes
Utilisez un réseau plus lent, une fenêtre d'affichage plus petite et une charge à froid. Vérifiez l'ordre de chargement, les décalages de mise en page, les cibles tactiles, le texte lisible, l'accès au clavier et si l'itinéraire principal peut être complété sans attendre les fonctionnalités non essentielles.
- Enregistrement
- Une observation d'expérience mobile
- Décision qu'il soutient
- Où le retard ou l'interaction bloque la tâche du client
- Risque à vérifier
- Tester uniquement un navigateur de bureau puissant
Inspectez les liens normaux et la navigation
Confirmez que les itinéraires importants utilisent des liens normaux et significatifs qui fonctionnent sans gestionnaire de clics cachés. Vérifiez les menus, la chapelure, le contenu connexe, la pagination et le chemin de retour des états d'erreur ou vides.
- Enregistrement
- Une liste de contrôle du comportement des liens
- Décision qu'il soutient
- Si les chemins de découverte sont durables et compréhensibles
- Risque à vérifier
- Utiliser un élément qui ne ressemble qu'à un lien
Erreur du plan et états de secours
Identifiez les échecs de données, les scripts bloqués, les API lentes, l'inventaire indisponible, les bords de connexion et les conditions hors ligne. Fournissez un message clair, un repli sûr et un moyen de récupérer ou de contacter l'assistance.
- Enregistrement
- Une carte d'état d'erreur
- Décision qu'il soutient
- Ce que les clients voient lorsque le chemin idéal échoue
- Risque à vérifier
- Laisser une coque de chargement vierge être la seule expérience d'échec
mise en production à travers un petit ensemble de validation
Avant un déploiement plus large, testez des URL de grande valeur sur les modèles et les appareils. Enregistrez les captures d'écran, les détails des réponses clés et les parcours terminés. Attribuez une condition d'arrêt et un responsable de restauration pour la fenêtre de lancement.
- Enregistrement
- Une liste de contrôle de version JavaScript
- Décision qu'il soutient
- Si le changement est sûr pour s'étendre
- Risque à vérifier
- En attente des rapports des clients pour trouver des échecs de base
Modèle de travail
- Contenu essentiel : Énumérez la réponse, la preuve, les liens et l'action qui doivent être utilisables avant l'amélioration. Un responsable de produit doit convenir que ceux-ci sont essentiels pour le client.
- Réponse initiale : Enregistrez ce qui est présent dans la première réponse, y compris les titres, les liens, les contrôles et les signaux de page. Un ingénieur devrait être en mesure de reproduire la capture.
- Comparaison rendue : Notez ce qui apparaît, disparaît ou change après l'exécution des scripts. Un évaluateur devrait voir si le contenu essentiel s'est déplacé derrière une dépendance.
- Observation mobile : Capturez le réseau, la fenêtre d'affichage, l'état de chargement, l'interaction et le comportement d'erreur. Un concepteur et un évaluateur d'accessibilité devraient être en mesure de le vérifier.
- Retour : Décrivez ce que le visiteur peut encore faire lorsque les données ou les scripts sont retardés ou indisponibles. L'assistance doit savoir comment guider un client tout au long du repli.
- Décision de mise en production : Indiquez les URL canari, la condition d'arrêt, le responsable et le chemin de retour en arrière. Le responsable de la mise en production devrait être en mesure d'agir sans réunion séparée.
Examen de la qualité avant l'expédition
- Comparez le HTML initial, le contenu rendu et un navigateur mobile pour un modèle important. Un fait qui n'existe qu'après une interaction fragile ou un script retardé ne doit pas être supposé être constamment disponible.
- Utilisez un réseau lent et un petit écran pendant la vérification. Vérifiez que la question principale, la preuve, le prix ou les conditions et l'action suivante restent visibles avant que les éléments décoratifs ou les scripts non essentiels ne terminent le chargement.
- Répertorie les scripts tiers par valeur du client, responsable et mode d'échec. Supprimez ou différez tout ce qui bloque le contenu essentiel sans aider un utilisateur à terminer la tâche qui l'a amené à la page.
Règles de décision pour le monde réel
Un élément visuel apparaît après un long délai
Faire : Décidez si c'est essentiel. Si c'est le cas, déplacez le contenu utile plus tôt ou améliorez le chemin de livraison.
Éviter : N'appelez pas la page rapidement car l'écran final semble poli.
Un lien clé ne fonctionne que par le biais d'un gestionnaire de clic
Faire : Utilisez un lien standard pour la destination et l'interaction de la couche en haut là où cela aide.
Éviter : La navigation ne dépend pas d'un script sans raison claire.
La page a un état de chargement mais pas d'état d'erreur
Faire : Ajoutez un message d'échec concis, une option de récupération et un itinéraire d'assistance pour le client.
Éviter : Ne laissez pas le visiteur avec un spinner sans fin.
Les données de performance sont mitigées
Faire : Segmenter par appareil, itinéraire, marketing et cohorte de mise en production avant de hiérarchiser le travail.
Éviter : N'utilisez pas une moyenne à l'échelle du site pour expliquer un échec de page spécifique.
Notes de l'entraîneur
- JavaScript peut prendre en charge une expérience riche. La question pratique est de savoir si l'essentiel reste clair lorsque les conditions sont imparfaites.
- Les tests mobiles sont un test de contenu et de parcours, pas seulement un test de vitesse.
- Un petit ensemble de canaris donne à une équipe un moyen reproductible de protéger les pages importantes.
Exemple travaillé : une page de prix du logiciel d'abonnement
La page des prix a une excellente copie, mais ne fournit presque aucune information sur le plan jusqu'à ce qu'une grande application client s'hydrate. Sur un téléphone Android plus lent, la page affiche d'abord un squelette, puis déplace la bascule de facturation annuelle sous le pli, et le tableau de comparaison ne devient interactif qu'après quelques secondes. La source de la page n'a pas de texte de plan ni de liens internes.
L'équipe rend les noms des plans, les prix, les résumés des fonctionnalités et les liens de comparaison sur le serveur. Il réserve de l'espace pour la bascule et la table, reporte un widget de chat non essentiel, compresse la demande de données de plan et ajoute un repli clair pour la calculatrice. Ils testent à la fois la sortie rendue et un voyage mobile étranglé avant la sortie.
Améliorer le résultat : Créer des expériences JavaScript et mobiles rapides et fiables
Créer un contrat de rendu
Pour chaque modèle de clé, documentez quels faits doivent être présents dans la réponse initiale, ce qui peut améliorer après l'interaction, de quelles API ils dépendent et à quoi ressemble le repli. Cela donne à l'ingénierie et au référencement une norme partagée.
Auditer les scripts tiers par coût client
Les gestionnaires de balises, les cartes thermiques, les outils de chat, les publicités et les plateformes d'expérimentation peuvent bloquer ou retarder une page. Enregistrez le responsable de leur entreprise, le coût de l'octet, le temps du fil principal, le comportement d'échec, les conditions de consentement et s'ils appartiennent au modèle.
Utiliser des canaris de mise en production
Avant un changement de cadre à l'échelle du site, publiez sur une petite cohorte de page ou une tranche de trafic. Surveillez les taux d'erreur, le comportement de réponse, les vérifications de rendu, l'expérience sur le terrain, les conversions et les contacts d'assistance avant de développer.
Traiter l'accessibilité comme le même problème de fiabilité
La mise au point au clavier, les commandes sémantiques, le contraste, les étiquettes, les régions en direct et les cibles tactiles échouent souvent dans les mêmes composants rendus par le client qui causent des problèmes de performance. Testez-les ensemble, pas comme un laissez-passer cosmétique séparé.
Orientations actuelles
Mesurer les performances là où les clients utilisent réellement le site
Les tests de laboratoire rapides sont utiles pour le diagnostic. Les données de terrain Core Web Vitals montrent comment les visiteurs réels ont vécu une page. Utilisez les deux et gardez l'objectif simple : un chemin stable et réactif pour le client.
- Utilisez les données de terrain pour voir l'expérience réel de l'utilisateur. Google recommande de viser la peinture la plus grande contenu dans les 2,5 secondes, l'interaction avec la peinture suivante en dessous de 200 millisecondes et le décalage cumulatif de la mise en page en dessous de 0,1 au 75e centile.
- Traitez un bon score comme une preuve d'une meilleure expérience de page, et non comme une augmentation de classement garantie. Une page doit encore résoudre la tâche du client.
- Testez les modèles mobiles les plus utilisés et les flux importants : atterrissage, navigation, recherche ou filtres, formulaires, paiement, réservation et erreurs. Une page d'accueil rapide ne prouve pas un chemin de conversion rapide.
- Lorsque les résultats du laboratoire et du terrain ne sont pas d'accord, commencez par les conditions de l'utilisateur réel : mélange d'appareils, réseau, géographie, consentement, scripts tiers, personnalisation et le modèle mesuré.
- Corrigez d'abord le plus grand goulot d'étranglement visible, puis mesurez à nouveau. Évitez de courir après de petits changements de notation pendant que les clients attendent toujours une image clé, un contrôle ou un état de confirmation.
Utilisez ceci avant de publier
- L'équipe suit les données sur le terrain pour les modèles et les appareils qui comptent le plus.
- Une découverte de performance nomme la tâche de l'utilisateur concerné, et pas seulement une mesure.
- Chaque version vérifie la stabilité du chargement, de l'interaction et de la mise en page sur le véritable chemin mobile.
Note de champ actuelle
Gardez la page principale compréhensible avant l'exécution de JavaScript
Google peut rendre JavaScript, mais le HTML initial est toujours le point de départ le plus clair et le plus rapide pour les utilisateurs et les robots d'exploration. Mettez-y le contenu principal, les liens utiles et le signal canonique stable lorsque votre plate-forme le permet.
- Vérifiez la réponse brute et la page rendue pour le même contenu essentiel, le même statut et la même URL canonique.
- Conservez les liens importants comme liens d'exploration normaux et évitez de bloquer les scripts ou les styles requis.
- Testez les modèles mobiles représentatifs après une version, y compris les connexions lentes et les états d'erreur.
Référence officielle : Google : Les bases du référencement JavaScript ↗
livrable de leçon
JavaScript et dossier de validation mobile
Créez un résumé d'expérience technique pour une page mobile de grande valeur.
Tâche critique : Décrivez l'utilisateur, le contexte de l'appareil et l'action exacte que la page doit prendre en charge. Nommez les informations qui doivent être disponibles avant la fin de JavaScript.
Capture de preuves : Enregistrez le temps de réponse, le contenu HTML initial, la cascade du réseau, les changements de mise en page, le délai d'interaction, les erreurs JavaScript et un enregistrement d'écran du voyage.
Contrat de rendu : Indiquez ce qui est rendu sur le serveur, ce qui s'améliore plus tard, les dépendances de l'API, le comportement de secours et les exigences d'accessibilité.
Budget et mise en production : Définissez des budgets spécifiques à la page, nommez le responsable de chaque problème, choisissez un petit groupe de déploiement et définissez les contrôles de régression que vous exécuterez après la publication.
Avant de passer à autre chose
- La réponse initiale contient les informations et les itinéraires essentiels de la page.
- J'ai testé un parcours de réseau mobile et contraint réaliste.
- L'espace de mise en page est réservé au contenu et aux contrôles de chargement tardif.
- Les interactions critiques ont des replis utiles et des états d'erreur observables.
- Les budgets de performance protègent les tâches des clients et sont vérifiés après la publication.
Progression de la leçon
Vous avez terminé cette leçon ?
Enregistrez votre progression sur cet appareil pour reprendre facilement là où vous vous êtes arrêté.
Cette leçon n'est pas encore marquée comme terminée.
Mettez la leçon en pratique.
Créez un compte Spacebrain gratuit et utilisez la suite SEO avec vos propres fournisseurs de données.