Aujourd’hui, les pages web sont truffées d’images, de vidéos et d’éléments interactifs qui visent à améliorer l’expérience de l’utilisateur. Toutefois, ces éléments peuvent ralentir le temps de chargement de votre page.
À mesure que la technologie progresse, un objectif reste constant : la performance. Tout le monde espère que ses pages web se chargent à la vitesse de l’éclair.
L’un des moyens d’accélérer le chargement des pages web consiste à les rendre prêtes ou à les récupérer avant que l’utilisateur n’y accède.
Bref historique du pré-rendu
En 2011, l’équipe Chromium a introduit une première forme de pré-rendu dans le navigateur Chrome par le biais de la balise <link rel="prerender" … >.
Cette balise permettait aux développeurs d’indiquer aux navigateurs la ou les pages qu’un utilisateur pourrait visiter ensuite. Le navigateur récupère alors silencieusement ces pages et les rend en arrière-plan, ce qui réduit considérablement le temps de chargement lorsque l’utilisateur navigue vers ces pages.
Malgré ses avantages, cette première implémentation du pré-rendu utilisait beaucoup de bande passante et de ressources d’unité centrale et pouvait entrainer des problèmes de confidentialité si l’utilisateur ne visitait pas les pages pré-rendues. En outre, vous deviez sélectionner manuellement les liens à pré-rendre, ce qui n’était pas toujours efficace ou faisable.
Pour répondre à certains de ces problèmes, Chrome a supprimé le pré-rendu utilisant le lien rel=prerender hint en faveur de la méthode NoState Prefetch, qui consiste à récupérer les ressources d’une page sans exécuter de JavaScript ou d’autres actions susceptibles de porter atteinte à la vie privée.
La méthode NoState Prefetch a amélioré le chargement des ressources, mais n’a pas permis de charger instantanément la page comme le ferait un pré-rendu complet.
Présentation de l’API des Speculation Rules
L’API Speculation Rules est une nouvelle API expérimentale définie par JSON qui précharge spéculativement les URL avant de naviguer vers elles, ce qui permet d’accélérer les temps de rendu et d’améliorer l’expérience des utilisateurs.
L’API permet aux développeurs de configurer des règles avec une structure définie au format JSON dans un site script type="speculationrules" que le navigateur peut utiliser pour décider quelles URL doivent être pré-rendues.
<script type="speculationrules">
{
"prerender": [
{
"source": "list",
"urls": ["firstpage.html", "secondpage.html"]
}
]
}
</script>Il en va de même pour le prefetching, qui peut souvent constituer une bonne première étape sur la voie du pré-rendu :
<script type="speculationrules">
{
"prefetch": [
{
"urls": ["firstpage.html", "secondpage.html"]
}
]
}
</script>Les extraits de code ci-dessus montrent comment l’API Speculation Rules fonctionne en spécifiant une liste d’URL à prélever ou à pré-rendre.
Récemment, Google a annoncé de nouvelles améliorations de l’API Speculation Rules, qui offre désormais l’option de recherche automatique de liens à l’aide de règles documentaires. Cette option permet de récupérer des URL dans le document en fonction d’une condition where.
<script type="speculationrules">
{
"prerender": [
{
"source": "document",
"where": {
"and": [
{
"href_matches": "/*"
},
{
"not": {
"href_matches": [
"/wp-login.php",
"/wp-admin/*"
]
}
}
]
},
"eagerness": "moderate"
}
]
}
</script>Dans cet extrait de code, toutes les URL de la page sont prises en compte pour le pré-rendu, à l’exception de celles menant aux pages de connexion et d’administration de WordPress. Vous pouvez également spécifier un niveau de eagerness – eager (tout de suite), moderate (au survol de la page pendant 200 ms) et conservative (au passage de la souris ou au toucher de la page).
Les sélecteurs CSS peuvent également être utilisés comme alternative ou en conjonction avec les correspondances href pour trouver des liens sur la page en cours :
<script type="speculationrules">
{
"prerender": [{
"source": "document",
"where": {
"and": [
{ "selector_matches": ".prerender" },
{ "not": {"selector_matches": ".do-not-prerender"}}
]
},
"eagerness": "moderate"
}]
}
</script>Lorsque vous utilisez l’API Speculation Rules, vous pouvez l’inspecter à l’aide des services d’arrière-plan des charges spéculatives dans l’onglet Application de Chrome lorsque vous inspectez la page.
Il y a d’autres possibilités – nous les explorerons dans la section consacrée au débogage.
Prise en charge des navigateurs
L’API Règles de spéculation est prise en charge dans les navigateurs modernes basés sur Chromium, y compris Chrome et Edge, à partir de versions spécifiques.
Cela permet aux utilisateurs des navigateurs pris en charge de bénéficier de temps de chargement plus rapides, tandis que les utilisateurs d’autres navigateurs ne subiront pas d’effets négatifs, car l’API est un outil d’amélioration progressive.
Le plugin WordPress Speculative Loading
Pour profiter des avantages de l’API Speculation Rules dans WordPress, l’équipe de performance de WordPress (qui comprend des développeurs de Google) a récemment publié l’extension Speculative Loading. Cette extension permet le chargement spéculatif des URL frontend liées à la page.
Jusqu’à présent, l’extension a été peu adoptée car l’API est encore dans sa phase initiale, mais elle a reçu quelques critiques positives.
Par défaut, l’extension est configurée pour afficher les URL de WordPress lorsque l’utilisateur survole un lien pertinent. Ceci peut être personnalisé via la section Speculative Loading sous Réglages > Lecture.
Cela signifie que toutes les URL liées à la page sont pré-rendues avec une configuration eagerness de moderate, qui se déclenche généralement lorsque l’utilisateur survole un lien. En tant que tel, vous n’avez pas besoin de faire quoi que ce soit après avoir activé l’extension ; elle fonctionne tout simplement.
Par exemple, si vous avez déjà installé l’extension Speculative Loading sur un site WordPress. Utilisez les Chrome DevTools pour inspecter le site et cliquez sur l’onglet Éléments. Lorsque vous faites défiler le site vers le bas, vous remarquerez qu’une page script type="speculationrules" a déjà été ajoutée pour vous avec les différentes règles de spéculation.
Elles utilisent une expression rationnelle pour spécifier les liens qui doivent être pré-rendus, les liens qui ne doivent pas être pré-rendus et le degré d’impatience. Les sections suivantes expliquent ces règles en détail.
Limites pour éviter la surutilisation
Chrome a mis en place des limites pour éviter une utilisation excessive de l’API :
| Attente | Prévisibilité | Pré-rendu |
| immédiat/affairé | 50 | 10 |
| modéré/conservateur | 2 (FIFO) | 2 (FIFO) |
Ils empêchent la surutilisation grâce à divers réglages basés sur l’urgence et l’interaction avec l’utilisateur.
immediateeteager– Ils ne dépendent pas des actions de l’utilisateur et ont donc des limites plus élevées. Ils permettent des ajustements dynamiques de la capacité en supprimant les anciennes spéculations.moderateetconservative– En revanche, ces paramètres sont déclenchés par l’utilisateur et respectent le principe FIFO (First In, First Out) avec un plafond de 2, remplaçant les spéculations les plus anciennes par de nouvelles afin de conserver la mémoire.
Empêcher certaines URL d’être pré-renseignées et de faire l’objet d’un pré-rendu
Il est important de noter que les routes WP-admin sont exclues du prerendering et du prefetering par défaut. En tant que développeur WordPress, c’est à vous de déterminer les routes que vous souhaitez prioriser.
Vous pouvez personnaliser les règles concernant les types d’URL à précharger spéculativement en utilisant le filtre plsr_speculation_rules_href_exclude_paths.
L’exemple de code suivant garantit que les URLs comme https://wordpresssite.com/cart/ ou https://wordpresssite.com/cart/book/ seront exclues du prefetching et du prerendering :
<?php
add_filter(
'plsr_speculation_rules_href_exclude_paths',
function ( $exclude_paths ) {
$exclude_paths[] = '/cart/*';
return $exclude_paths;
}
);Il peut arriver que vous souhaitiez exclure une URL du prerendering et l’autoriser à être pré-renseignée. Par exemple, une page contenant du JavaScript côté client pour mettre à jour l’état de l’utilisateur ne devrait probablement pas faire l’objet d’un pré-rendu, mais il serait raisonnable qu’elle fasse l’objet d’un pré-rendu.
À cette fin, le filtre plsr_speculation_rules_href_exclude_paths reçoit le mode actuel ( prefetch ou prerender) pour fournir des exclusions conditionnelles.
Par exemple, assurons-nous que les URL telles que https://wordpresssite.com/products/ ne peuvent pas faire l’objet d’un pré-rendu tout en les autorisant à faire l’objet d’un pré-rendu.
<?php
add_filter(
'plsr_speculation_rules_href_exclude_paths',
function ( array $exclude_paths, string $mode ): array {
if ( 'prerender' === $mode ) {
$exclude_paths[] = '/products/*';
}
return $exclude_paths;
}
);Débogage des règles de spéculation pour les sites WordPress
Le débogage des règles de spéculation peut être délicat car les pages pré-rendues sont rendues dans un rendu séparé, comme un onglet d’arrière-plan caché qui remplace l’onglet actuel lorsqu’il est activé. L’équipe de Chrome a beaucoup travaillé avec les DevTools, vous permettant de déboguer avec eux.
Dans Chrome DevTools, accédez à l’onglet Applications, puis faites défiler vers le bas jusqu’à l’onglet Charges spéculatives. Les développeurs y trouveront des détails sur la spéculation, les URL pré-rendues, celles qui échouent, et bien d’autres choses encore.
Ici, vous voyez que cinq liens de la page peuvent être pré-rendus en fonction des URL qui correspondent aux règles définies dans le JSON des règles de spéculation, comme indiqué ci-dessous. Remarquez qu’il n’est pas nécessaire d’énumérer toutes les URL ; les règles de document permettent au navigateur de les récupérer à partir des liens de même origine sur la page.
Le « statut » de certains liens est « Non déclenché », ce qui signifie que le processus de pré-rendu n’a pas commencé. Cependant, lorsque vous survolez les liens sur la page, vous voyez l’état changer au fur et à mesure que chaque URL est pré-rendu.
N’oubliez pas que Chrome a fixé des limites aux prérenders, notamment un maximum de deux prérenders pour moderate eagerness, de sorte qu’après avoir survolé le troisième lien, nous voyons la raison de l’échec pour cette URL :
Il est également possible de changer le moteur de rendu utilisé par les panneaux DevTools à l’aide du menu déroulant en haut à droite ou en sélectionnant une URL dans la partie supérieure du panneau et en sélectionnant Inspecter :
Ce menu déroulant (et la valeur sélectionnée) est partagé par tous les autres panneaux, comme le panneau Réseau, où vous pouvez voir que la page demandée est la page pré-rendue :
Dans le panneau Éléments, vous pouvez voir le contenu de la page :
Tout comme vous pouvez déboguer les pages pré-rendues, vous pouvez également récupérer les pages. Pour l’extension Speculative loading, assurez-vous de sélectionner Prefetch comme mode de spéculation.
Maintenant, lorsque vous inspectez la page avec DevTools et que vous naviguez vers l’onglet Speculative loads, l’action sera Prefetch pour les différentes URL, et les règles seront également modifiées.
Lorsque vous accédez à l’onglet Réseau après avoir survolé un lien, les ressources préemptées sont affichées en dernier, comme le montre la colonne Type. Elles sont récupérées avec la priorité la plus faible, car elles sont destinées à des navigations futures, et Chrome donne la priorité aux ressources de la page en cours.
Comparaison des performances
Jusqu’à présent, vous avez compris ce que fait le plugin « Speculative Loading » et comment il fonctionne. Assez de théorie ; comparons les performances de deux sites identiques sur le même serveur (l’hébergement WordPress de Kinsta).
Pour cela, j’ai créé deux sites WordPress avec le tableau de bord MyKinsta sur le même centre de données (Iowa (US Central), qui est boosté en utilisant les VM C3D de Google) et sans installer aucune autre extension pour les deux sites.
le site « Bare-site » est sans l’extension, tandis que pour le site « Speculative-site », l’extension « Speculative Loading » est installée et activée sur le tableau de bord de WordPress. Il est important de savoir que l’API Speculative Rules n’améliore que le temps de chargement de la page suivante que vous êtes sur le point de parcourir – vous ne pouvez pas juger cela sur la base d’outils génériques de performance de site tels que Lighthouse.
Nous testerons la vitesse des pages en chargeant une page à partir d’un lien interne spécifique sur les deux sites web et en utilisant l’onglet Réseau de l’outil Chrome DevTool lorsque vous inspectez le site pour voir le temps de chargement et d’autres informations.
Dans le cas du « Bare-site », vous remarquerez que le chargement est plus long, car l’ensemble du processus de chargement se déroule en cours de route et le contenu du DOM est tout juste chargé :
Mais pour le « Speculative-site », le contenu du DOM a déjà été chargé via l’API spéculative et mis en cache.
La différence entre les deux sites peut sembler minime. Dans ce cas, la différence est d’environ 0,22 s, mais pour un grand site avec plus de contenu, vous commencez à remarquer une différence significative.
Impact de l’API Speculation Rules sur l’analyse
L’analyse est essentielle pour suivre l’utilisation du site web par le biais des pages vues et des évènements et pour évaluer les performances par le biais de la surveillance des utilisateurs réels (RUM). Il est important de savoir que le pré-rendu peut affecter l’analyse.
Par exemple, l’utilisation de l’API Speculation Rules peut nécessiter un code supplémentaire pour activer l’analyse uniquement lorsque les pages pré-rendues sont effectivement consultées. Bien que Google Analytics, Google Publisher Tag (GPT) et Google AdSense retardent le suivi jusqu’à ce qu’une page soit active, tous les fournisseurs ne le font pas par défaut.
Pour y remédier, une promesse peut être configurée pour n’initialiser l’analyse qu’au moment de l’activation de la page :
// Promise to activate analytics on page activation for prerendered pages
const whenActivated = new Promise((resolve) => {
if (document.prerendering) {
document.addEventListener('prerenderingchange', resolve);
} else {
resolve();
}
});
async function initAnalytics() {
await whenActivated;
// Initialize analytics
}
initAnalytics();Résumé
Cet article explique ce qu’est l’API Speculative Rules, comment elle fonctionne, et comment vous pouvez l’utiliser sur un site WordPress. Il s’agit encore d’une fonctionnalité expérimentale, mais elle est en train d’être adoptée massivement.
Les règles de spéculation sont encore limitées aux pages d’un même onglet, mais des efforts sont en cours pour réduire ces restrictions.
Il est également important de savoir qu’une part importante des performances de votre site dépend de la qualité de votre hébergement. Chez Kinsta, nous sommes connus pour fournir un hébergement WordPress haut de gamme avec des dizaines de fonctionnalités premium.
Notre infrastructure est entièrement conteneurisée et alimentée exclusivement par Google Cloud Platform sur le réseau Premium Tier de Google, ce qui nous permet de vous fournir une large sélection des serveurs de données les plus rapides, des performances incroyables, une mise en cache au niveau du serveur, des ressources dédiées et une sécurité renforcée.
Consultez les commentaires de nos clients ou contactez-nous pour en savoir plus sur notre solution d’hébergement infogéré et sur son excellence.
Que pensez-vous de l’API Speculative Rules et de son introduction dans WordPress ? Partagez-les dans les commentaires ci-dessous !
Joel est un développeur d'interfaces publiques qui travaille chez Kinsta en tant que rédacteur technique. Il est un enseignant passionné par l'open source et a écrit plus de 200 articles techniques, principalement autour de JavaScript et de ses frameworks.
Laisser un commentaire