Vous l’avez peut-être déjà remarqué, depuis octobre 2019, l’onglet vitesse a fait son apparition sur la Google Search Console. Cet onglet liste les pages « lentes » de votre site. C’est une métrique indispensable pour le SEO car comme nous le savons, les pages trop lentes sont pénalisées en termes de référencement naturel. Dans l’article d’aujourd’hui, nous détaillerons le fonctionnement de ce nouveau module et nous vous en proposerons une analyse. Que contient le rapport vitesse de la Google Search Console ? Google définit trois vitesses de page : lente (en rouge), moyenne (en orange) et rapide (en vert). L’écran principal du module de vitesse présente le nombre de pages dans chacune des catégories en fonction du temps. Une page lente sur mobile ne l’est pas forcément sur desktop. Les données sont donc réparties dans deux graphiques différents. En cliquant sur « Ouvrir le rapport », vous pouvez accéder à une vue plus détaillée des données. Ce rapport vous permet de filtrer selon la catégorie de vitesse sur laquelle vous souhaitez avoir plus de détails. Notamment, vous pourrez identifier la raison pour laquelle chacune de vos page est considérée comme lente. Comment Google mesure la vitesse de vos pages ? Google se base sur deux mesures pour qualifier vos pages. Le First Contentful Paint, FCP : temps entre l’instant où l’internaute essaie d’accéder à l’URL et l’instant où le navigateur affiche la première image. Le First Input Delay, FID : délai entre la première interaction de l’internaute (clique sur un lien ou sur un bouton) et le moment où le navigateur répond à cette interaction. Le tableau suivant permet ensuite de catégoriser vos...
D’après une étude menée par la fondation Mozilla, les internautes qui utilisent un bloqueur de publicité ont un taux d’engagement 50% supérieur aux autres. De manière générale, l’internaute associe rarement publicités en ligne et bonnes performances de navigation. Dans un article précédent, nous évoquions l’impact de la performance web sur les revenus publicitaires. Intéressons-nous aujourd’hui à la question inverse : l’impact de la publicité sur les performances web. Nous listerons les différents problèmes d’expérience utilisateur amenés par de la publicité mal intégrée. Puis nous donnerons quelques conseils techniques permettant de les contourner. Publicité en ligne et expérience utilisateur Single point of failure (SPOF) Le SPOF désigne une dépendance externe critique de votre site. En d’autres termes, votre site ne peut pas fonctionner correctement sans cette dépendance. Si celle-ci est localisée sur un domaine disponible et performant alors il n’y aura pas vraiment de problème. Cependant, si le serveur en question tombe, les conséquences peuvent être dramatiques. Si en plus, il s’agit d’une ressource bloquante, alors l’internaute attendra devant une page blanche pendant une vingtaine de seconde ! Il est important de noter que ce problème n’est pas applicable uniquement à la publicité mais en fait à tous les domaines tiers que vous utilisez. Origine des contenus Les contenus publicitaires proviennent de sources très variées. Même si vous n’incluez qu’un seul script de publicité, celui-ci peut faire appel à des tiers eux-mêmes appelant des tiers, etc. Il sera finalement très difficile pour vous de prévoir à l’avance les contenus qui seront finalement chargés sur votre site. Cela pourra provoquer entre autre : Des ralentissements sur le chargement des pages Une...
Lorsqu’on cherche à optimiser la performance d’un site web, le réflexe courant est de s’intéresser à la structure des pages. Mes pages contiennent-elles des scripts bloquants ? Le navigateur des internautes garde-t-il bien les ressources statiques en cache ? Mes contenus statiques sont-ils mis à disposition via des CDN ? Même si toutes ces questions sont très importantes, il ne faut pas oublier qu’avant de revenir sur le poste client la requête de l’internaute traverse plusieurs étapes. Le TTFB, Time To First Byte est une valeur temporelle qui englobe ces étapes. L’objectif de cet article sera de vous présenter cette métrique, son rôle dans le web moderne et surtout comment la réduire pour améliorer les performances web de vos applications. Qu’est-ce que le Time To First Byte ? TTFB est l’acronyme de Time To First Byte. Il se traduit en français par « Temps pour le premier octet ». C’est par définition la durée entre le clic de l’utilisateur et l’arrivée du premier octet sur son navigateur. Ce temps est ainsi divisé en 3 parties : Le temps que met sa requête à arriver jusqu’au serveur. Le temps que met le serveur à traiter la requête et à générer une réponse. Le temps que met la réponse à arriver sur le poste client, aussi appelé régulièrement la latence. Cette métrique exclut donc la complexité du rendu HTML sur le poste client. Elle permet ainsi de concentrer les efforts d’optimisation sur les aspects serveurs et réseaux. Google recommande une valeur sous 200ms pour le TTFB. Dans la plupart des cas, on observera plutôt entre 500 et 800ms. Le Time To First Byte...
Vous avez besoin forcément d’un CDN ! Longtemps considérées pour beaucoup comme trop onéreuses, il existe aujourd’hui des solutions CDN diverses et pour tous les budgets. La fonction de base de ces solutions étant de distribuer les contenus en proximité des utilisateurs, elles s’avèrent indispensables pour les sites à audience internationale. Mais elles présentent aussi de nombreux autres avantages : disponibilité accrue des contenus, déchargement des serveurs origines, sécurité améliorée… Bref, c’est un excellent moyen d’améliorer l’expérience utilisateur de vos services web. Cependant, il existe énormément de CDN différents et il peut être difficile de s’y retrouver. Voici le guide de tout ce que vous devez savoir pour bien choisir votre CDN. Voir aussi : CDN & Web Acceleration Prérequis : connaitre vos utilisateurs et leur niveau de satisfaction Avant de commencer à comparer les différents CDN du marché, vous devez vous assurer que vous connaissez bien vos utilisateurs. En particulier, vous devez connaitre la répartition géographique de votre audience. Cela vous permettra de faire une estimation plus précise de la tarification. De plus, il est primordial de superviser le niveau de performance avant et après la mise en place du CDN. Vous pourrez ainsi vous fixer des objectifs réalistes et mesurer les améliorations. Pour ce faire, rien de mieux qu’une solution de Real User Monitoring ! Voici un exemple issu de l’application appYuser qui fournit une bonne partie des informations que nous venons d’évoquer. Copie d’écran tirée d’appYuser : le niveau de satisfaction par pays Les critères de sélection d’un CDN Le prix : Estimer précisément le coût mensuel d’un CDN peut rapidement s’avérer compliqué. En général, un...
On ne le répétera jamais assez, chaque octet compte quand il s’agit de web performance. Plus les ressources échangées entre le serveur et le client sont volumineuses plus ces échanges seront longs. Ce qui impactera l’expérience utilisateur de vos internautes. La compression HTTP est une technique qui consiste à compresser les fichiers avant de les envoyer, réduisant ainsi leur taille. Son activation est une best-practice récurrente dans les projets d’optimisation de performance web. En ce qui concerne les algorithmes de compression, Gzip règne en maître depuis son introduction. De nombreuses tentatives ont échoué à surpasser son excellent compromis taux/vitesse de compression. Brotli, l’algorithme de compression publié par Google en 2016, est un sérieux candidat à la couronne. Comment utilise-t-on Brotli ? En prérequis, pour échanger des données compressées entre client et serveur HTTP, il faut que le serveur (Apache, Nginx, etc.) et le client (votre navigateur) soient compatibles avec Brotli. Support de Brotli par les navigateurs : compatibilité Les dernières versions des principaux navigateurs sont compatibles avec Brotli depuis fin 2017. Le site caniuse estime la couverture à 89,66% des utilisateurs. Support de Brotli par les navigateurs d’après caniuse (vert=supporté, rouge=non supporté, la taille des cases pour chaque navigateur est proportionnelle au nombre d’utilisateurs). Support de Brotli par les serveurs HTTP Les 3 serveurs web majeurs : Microsoft IIS, Apache et Nginx proposent un module permettant d’intégrer Brotli. Apache : le module mod_brotli permet d’ajouter le support de Brotli, module disponible à partir de la version 2.4.26 d’Apache Nginx : le module ngx_brotli (fourni par Google) est disponible Microsoft IIS : il existe une extension développée par la communauté, IIS...
Nous utilisons des cookies pour améliorer votre experience de navigation sur le site. Cookie settingsACCEPTER
Cookies et confidentialité
Privacy Overview
Ce site utilise des cookies pour améliorer votre expérience de navigation sur le site. Hors de ces cookies, les cookies classés comme nécessaires sont stockés dans votre navigateur car ils sont aussi essentiels au fonctionnement des fonctionnalités de base du site. Nous utilisons également des cookies tiers qui nous aident à analyser et à comprendre comment vous utilisez ce site. Ces cookies ne seront stockés dans votre navigateur qu'avec votre consentement. Vous avez également la possibilité de désactiver ces cookies. Toutefois, la désactivation de certains de ces cookies peut avoir une incidence sur votre expérience de navigation.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
