Tout savoir sur WordPress

Booster la rapidité de son site en préchargeant les pages avec HTML5

Pour améliorer le temps de chargement d’un site, il est possible de précharger une page avec HTML5 et rendre la navigation plus fluide.

De nos jours, l’importance du temps de chargement d’un site n’est plus à prouver. Pour répondre à ce besoin, HTML5 apporte une fonctionnalité nommée Prefetching qui permet de précharger une page afin qu’elle soit rendue presque instantanément à l’utilisateur lorsqu’il cliquera sur le lien redirigeant vers celle-ci.

Pour le moment, seuls les navigateurs Chrome et Firefox supportent le Prefetching. De plus, le code diffère selon que vous êtes sous Chrome (rel='prerender') ou Firefox (rel='prefetch'). Par conséquent, on doit indiquer les deux méthodes pour être certain d’avoir un maximum de compatibilité.

Ci-dessous, un exemple d’utilisation à placer dans le fichier functions.php présent à la racine de votre thème :

add_action('wp_head', 'gkp_prefetch');
function gkp_prefetch() {
	
    if ( is_single() ) {  ?>
		
	<!-- Préchargement de la page d'accueil -->
	<link rel="prefetch" href="<?php echo home_url(); ?>" />
	<link rel="prerender" href="<?php echo home_url(); ?>" />
		
	<!-- Préchargement de l'article suivant -->
	<link rel="prefetch" href="<?php echo get_permalink( get_adjacent_post(false,'',true) ); ?>" />
	<link rel="prerender" href="<?php echo get_permalink( get_adjacent_post(false,'',true) ); ?>" />
   <?php
   }
}

Pour cet exemple, on précharge l’article suivant et la page d’accueil quand on se trouve sur un article. On peut penser que le lecteur ira lire le prochain article ou qu’il retournera vers la page d’accueil s’il est arrivé sur votre site en faisant une recherche sur Google.

Quelques précautions

Le préchargement des pages en HTML5 doit être utilisé avec prudence. En effet, si on précharge trop de pages, cela ralentira le navigateur et consommera plus de bande passante. De plus, ce n’est pas forcément compatible avec tous les systèmes de gestion de cache.

Cet article a été publié il y a 1490 jours - Il n'est peut être plus à jour !

Article écrit par Jean-David

25 Commentaires

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

  1. Hello,

    Article intéressant :)
    Merci.

    Il aurait pu l’être davantage en allant chercher des solutions alternatives pour les navigateurs ou versions de navigateurs ne supportant pas cette valeur d’attribut. Par exemple, au sein de ton contrôle on aurait pu rajouter :

    <?php if (strpos($_SERVER['HTTP_USER_AGENT'], 'Firefox') !== false) { ?>
    <link rel="prefetch" href="article_suivant.php" />
     
    <?php } else { ?>
    <script type="text/javascript">
    window.onload = function() {
        var rq = new XMLHttpRequest();
        rq.open('GET', 'article_suivant.php', false);
        rq.send(null);
    };
    </script>
    <?php } ?>
    

    De même j’ai cru lire que pour un pré-chargement efficace de contenus dynamiques il fallait prévoir un header-expires suffisamment long.

    Autrement, qu’en est-il des requêtes https ? Le préchargement est-il fonctionnel pour celles-ci ?

    Bonne journée.

  2. @Geoffrey : Tu m’apprends quelque chose avec ta partie JavaScript. Ca permet d’avoir le même effet qu’un prefetch ou prerender ?!

  3. Le chargement en JS ne fait pas du tout la même chose puisqu’il ne charge que le dom de la page.
    Au contraire, le prefetching va charger tous les assets de la page (css, js, imgs…) qui constituent le plus gros du temps de chargement. Il prend également en charge le pré-rendu, ce que ne fait pas le JS.
    A la rigueur, le load en JS va permettre de générer une mise en cache serveur du billet mais je suis plus que sceptique sur le gain réel de perf de ce fallback en JS

  4. @geoffrey : Si tu te sert des stats serveur ca risque effectivement de fausser tes résultats. En revanche les tags analytics étant appelés par JS, et comme je doute que le prefetching execute le JS à l’avance à priori pas de souci. Dans le cas ou le JS soit executé, il devrait y avoir moyen de gérer sans trop de pb en utilisant la visibility API dispo sur les navigateurs récents

  5. @Etienne : l’idée était de relever la problématique du fallback, non de donner une solution en 4 lignes de JS. Il faudrait effectivement une solution plus complète.

    Merci pour ces compléments d’info :)

  6. @Jmlapam : Je pense que ce sont deux choses qui n’ont rien à voir. L’AJAX permet d’avoir un intéraction utilisateur plus agréable et son temps de chargement dépend des éléments à récupérer tandis que le pré-chargement HTML5 permet de « pré-charger » des pages que l’on va visiter « réellement ».

  7. @jonathan : d’accord mais je ne compare pas les technologies mais leur finalité parce que la cible reste l’utilisateur, à savoir améliorer sa navigation sur le site en question.

  8. Ah merci de ta précision. Mais quelle différence avec un système de cache? Donc je peux combiner les deux et j’aurai un affichage Ferrari ou utiliser cela permet de se passer de mon système de cache?

  9. Comme je disais, c’est deux choses qui sont totalement différentes et indépendantes. Je ne pense pas que l’on fasse un site en AJAX pour qu’il soit plus rapide.

    Pour répondre à ta question : oui c’est plus efficace que de l’ajax car cela charge la page instantanément.

  10. Comme l’a indiqué Jean David, l’usage des deux est à prendre avec des pincettes. Ca dépend du contenu du site.

    Par exemple, ce n’est pas compatible sur GeekPress car le footer peut changer si on est connecté ou non. Imagine que j’arrive sur la page de cet article et que j’utilise le pré-chargement, la page d’accueil sera pré-chargé avec les boutons de connexion. Je lis l’article et je décide de me connecter pour commenter et je décide d’aller sur la page d’accueil. Et bien le footer ne sera pas modifié car la page aura été pré-chargement avant que je sois connecté !

  11. Hello,

    Pour avoir testé plusieurs mois le préchargement c’est une solution que je décommande fortement. Je préchargeais certaines pages systématiquement et avec des pics de 10.000 visiteurs.
    Les consequenes ont ete de :
    – faire chauffer inutilement mon serveur
    – ralentir au final le chargement perçu des pages
    – mettre le boxon dans le calcul du CTR pub avec une chute très significative pour certaines régies
    – créer des pages fantômes dans un de mes outils de web analytics

    Bonne nouvelle cependant les services Google ont été épargnés (AdSense et Analytics)

    Au final à utiliser avec BEAUCOUP de précaution uniquement sur des chemins sur lesquels vous êtes certains à au moins 50% qu’il y aura un clic suivant. L’analyse des chemins dans Google Analytics permet de le déterminer avec une assez bonne précision.

  12. Hum, très pratique :)
    Il serait bon de faire un article ou un complément sur toutes les possibilités pour charger le contenu, image…. !
    Merci en tout cas,