Comment améliorer votre TTFB pour accélerer votre site web ?

Comment améliorer votre TTFB pour accélerer votre site web ?

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 englobent 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 dans...
Comment choisir son CDN ?

Comment choisir son CDN ?

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...
Compression HTTP : Brotli ou Gzip ?

Compression HTTP : Brotli ou Gzip ?

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...
SEO : comment la vitesse de votre site impacte votre référencement ?

SEO : comment la vitesse de votre site impacte votre référencement ?

La performance de votre site web a un réel impact sur votre référencement naturel. Si on réunissait plusieurs experts SEO, ils arriveraient sans aucun doute rapidement à ce consensus. Cependant, si on leur demandait d’évaluer précisément cet impact la tâche serait bien plus difficile. L’objectif de cet article est de lister les différents biais par lesquelles la performance web impacte votre référencement. Vous pourrez ainsi plus facilement vous positionner sur la question dans vos projets SEO. Un site trop lent est moins bien référencé Pour commencer, donnons quelques principes sur l’algorithme de Google. Son fonctionnement interne est très complexe mais son objectif est très simple : classer les sites web selon la recherche de l’utilisateur. Pour ce faire, il utilise un grand nombre de critères qui auront une importance variable dans le classement final. Même si cet algorithme n’est pas connus dans les détails, nous avons une bonne idée de certains critères grâce aux différentes communication de Google sur le sujet ainsi que de nombreux tests. En particulier, la vitesse de chargement des sites est un critère officiellement pris en compte dans le référencement. C’était déjà le cas sur les desktop depuis 2010,  c’est maintenant le cas sur les mobiles depuis juillet 2018. Plus précisément, les sites trop lents seront fortement pénalisés et verront leur ranking baisser. Un site rapide permet l’optimisation du crawling budget Le crawling budget est un concept intuitivement assez facile à comprendre. Les robots des moteurs de recherche parcourent chaque jour plusieurs millions de sites. Afin d’optimiser les efforts devant une telle masse d’informations, ils se doivent de se fixer des limitations par site. Ces limitations...
Déploiement HTTP/2 avec Akamai : cas client

Déploiement HTTP/2 avec Akamai : cas client

Nous avons récemment déployé le protocole HTTP/2 chez un de nos clients en l’activant depuis leurs plateformes Akamai. Nous vous faisons profiter des résultats. Sans HTTP/2 Ci-dessous le waterfall très coloré de notre client avant HTTP/2 : Rouge : la ressource est bloquée Violet : résolution DNS Bleu : la ressource est en attente Vert : la ressource est en réception On observe des temps de blocage de plus en plus importants à mesure qu’on avance dans le temps (barres rouges). Avec HTTP/2 Le même extrait du waterfall de notre client avec HTTP/2 : Le multiplexage HTTP/2 est bien en place, ça marche ! Nous n’avons plus aucun temps de blocage et un affichage optimisé de la page. Reste maintenant à évaluer l’impact réel sur le ressenti utilisateur pour tous les contextes et usages grâce à appYuser. La ligne bleue correspond à l’événement DOM Content Loaded. Lire aussi :  HTTP/3 est officiel ! Déploiement HTTP/2 avec Akamai : cas client was last modified: février 8th, 2019 by Aurélien...