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écathlon, Mediapart, RMC Sport – le mois catastrophe

Décathlon, Mediapart, RMC Sport – le mois catastrophe

Quels sont les points communs ce mois-ci entre Décathlon, Mediapart et RMC Sport ? Un succès fou pour leurs contenus ? Oui !  Des abonnés ultra frustrés ? Oui aussi ! Les 3 ont été victimes de leur succès. Les produits et contenus proposés ont généré des audiences bien plus importantes que prévu. Malheureusement ces audiences n’avaient pas été bien anticipées, ce qui a généré une insatisfaction et une frustration immense pour tous les internautes qui n’ont pas pu y accéder. En effet, les serveurs n’ont pas tenu la charge ! La réédition d’un jogging de 1985 fait tomber le site Web de Decathlon (lire l’article). La publication d’un article sur l’affaire Benalla fait tomber le site Web de Mediapart… Edwy Plenel s’excuse auprès de ses abonnés. L’audience pour le match PSG / Manchester sature les serveurs et les abonnés furieux ne peuvent pas voir le match, plus de 1 million d’internautes iront voir le match de façon illégale sur le compte Facebook du PSG… ! La presse titrera Bugs en série sur RMC Sport pour les soirées de Ligue des Champions… En conclusion : C’est l’occasion de rappeler que des solutions existent pour éviter ces mésaventures. Ce ne sont pas forcément des solutions complexes et coûteuses, elles sont de plus en plus accessibles et permettent d’augmenter significativement son trafic en toute sérénité. Voir notre page d’explication sur les solutions CDN Web Acceleration et Front End Optimization. Ces solutions sont parfois plus simples à mettre en place que de gérer une communication délicate post événements pour s’excuser auprès des internautes, clients ou abonnés de n’avoir pas pu fournir les...
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...
Revenus publicitaires : l’influence de la Web Performance ?

Revenus publicitaires : l’influence de la Web Performance ?

Le lien entre le taux de conversion et la performance web a déjà été établi à de nombreuses reprises. Aujourd’hui, nous sommes même capables de calculer l’impact d’une optimisation de performance sur le taux de conversion comme nous vous le présentions déjà dans cet article. Cependant, la vente en ligne n’est pas le seul moyen de générer des revenus via votre site internet, la publicité peut augmenter sensiblement vos revenus. Dans cet article nous vous présenterons l’impact de la performance web sur les revenus générés par la publicité en ligne. La génération de revenus publicitaires Avant de présenter l’étude, détaillons tout d’abord les différents modèles de coûts appliqués à la publicité sur internet. Les modèles de coûts associés à la publicité sur internet CPM : cost per thousand views. C’est le modèle le plus simple car les revenus sont en général proportionnels à l’audience du site. Chaque fois que la publicité est vue par 1000 internautes un montant fixé à l’avance est reversé à l’hébergeur. CPC : cost per click. Dans ce cas, l’hébergeur ne touche des revenus que lorsqu’il y a un clic sur le lien de votre site. C’est ce modèle qui est le plus fréquemment répandu. CPA : cost per action. L’hébergeur ne touchera des revenus que si son internaute à initié une action à partir de la publicité. Ces actions peuvent varier : une vente, une création de compte, téléchargement d’un formulaire, accès à un site … Il est très difficile d’évaluer l’impact de la performance web dans le cas des modèles CPA et CPC. On comprend intuitivement que dans ces deux cas, le ciblage jouera...
Baromètre Webperf – 15 sites testés pour le Black Friday

Baromètre Webperf – 15 sites testés pour le Black Friday

Impossible de passer à côté, le Black Friday nous bombarde à coup de publicités, de newsletters voire de SMS depuis lundi. Historiquement nord-américain, il est aujourd’hui central en Europe et occupe une place de plus en plus critique dans l’activité e-commerce. Les chiffres ne mentent pas, avec une hausse de + 48% du nombre de commandes passées lors de l’édition 2017 selon le Webloyalty Panel, cet événement est désormais le jour le plus important pour le e-commerce français en devançant même le 1er jour des soldes. Cela se traduit bien évidemment par une augmentation considérable du trafic sur les sites marchands, qui rencontrent parfois des soucis de performance web. Qu’en est-il des acteurs majeurs ? Quadran a voulu s’interroger sur la question et a donc réalisé un baromètre de leur webperf, tant sur Desktop que sur Mobile. Voici les résultats. Méthodologie Webperf Quadran, cabinet de conseil, expert de la supervision et de l’optimisation des performances techniques de sites internet, a mené une étude afin d’analyser les performances techniques de quinze sites e-commerce, tous secteurs d’activité confondus.  Les tests ont été réalisés par des outils propres à Quadran (des robots pilotés à distance, situés à Paris), du 19 au 21 octobre. Ils ont été réalisés à la fois dans des conditions de connexion dites « raisonnablement mauvaises » et des conditions de connexion « raisonnablement bonnes ». Chacun des tests a été répété 15 fois, seules les mesures médianes ont été conservées afin d’exclure tout résultat aberrant. Dans cette étude, Quadran distingue trois métriques distinctes : Le « First Contentful Paint » : indique le moment où du contenu (texte ou image) s’est affiché...