Soldes sur internet : e-commerçants 5 conseils performance

Soldes sur internet : e-commerçants 5 conseils performance

Quelques conseils de dernières minutes pour vous e-commerçants et webmasters avant le grand rush des soldes d’été, pour limiter les incidents et les indisponibilités de service et pour accueillir un maximum d’internautes dans la bonne humeur. A J-10 il faut faire simple ! Nos conseils : Vérifiez la taille et le format de vos images Les images représentent souvent la majorité des octets téléchargés sur une page Web, et occupent également une grande partie de l’espace visuel. En conséquence, l’optimisation des images permet souvent de réaliser les économies en octets et les améliorations des performances les plus importantes pour votre site Web. Pensez aussi à utiliser des images nouvelle génération (WebP, JPEG 2000 ou JPEG XR), ils offrent un taux de compression plus élevé, permettant ainsi de réduire le temps de chargement. Avez-vous besoin d’animations ? Si oui, le format GIF offre un bon compromis entre la qualité et la taille occupée. Quelques outils utiles Compressor pour réduire des images, ezGIF pour réduire la taille d’un GIF animé. Vérifiez les ressources chez votre hébergeur Demandez à votre hébergeur de vérifier que les espaces disques ne sont pas saturés ou en phase de l’être, supprimez éventuellement les logs et vérifiez qu’il n’y a pas de mode Debug (surtout si vous utilisez Magento). Nettoyez vos données obsolètes dans vos bases et assurez-vous que vos index sont récents, sinon réindexez vos bases avant le début des soldes. Redémarrez vos serveurs, c’est souvent ce qu’il y a de plus simple et efficace. Cachez vos contenus statiques Ne vous lancez pas dans des campagnes de tests de montée en charge, c’est trop tard, mais vous pouvez encore améliorer votre...
Les nouvelles métriques de performance web pour l’expérience utilisateur

Les nouvelles métriques de performance web pour l’expérience utilisateur

L’objectif est d’analyser les nouvelles métriques disponibles de performance web et de voir comment on peut les utiliser pour estimer l’expérience utilisateur. Aujourd’hui la seule mesure de fin de chargement d’une page ne suffit pas pour évaluer réellement l’expérience utilisateur, elle permet au mieux de réaliser des tests techniques. Pour évaluer finement ce que l’internaute a réellement vécu et la perception qu’il a eue lors d’une navigation sur un site, il faut être capable d’analyser d’autres « moments » bien plus significatifs pour l’expérience utilisateur au niveau des performances web. Pour être pertinente cette analyse ne peut se faire que sur le poste client, dans un contexte réel de navigation. C’est pour ces raisons que les nouvelles métriques de performance web se mesurent au niveau du « User », pour analyser la progression réelle de l’affichage, la prise de dialogue avec l’internaute « début d’affichage », le moment où il peut interagir avec la page et si les interactions « clic sur un bouton » sont frustrantes ou pas. Quelles sont les métriques actuelles pour évaluer la progression d’affichage et l’expérience utilisateur associée ? Il en existe suffisamment pour évaluer de façon pertinente si l’utilisateur a eu une bonne ou mauvaise expérience de navigation. La difficulté c’est que ces différentes métriques peuvent être récupérées soit grâce au navigateur de l’utilisateur dans son contexte réel (solutions RUM*) soit depuis des sondes sur des serveurs dédiés et des contextes limités (solutions synthétiques*). Identifions les métriques de performance web disponibles et leur lien avec l’Expérience Utilisateur ; indépendamment des solutions de monitoring : Expérience utilisateur Métriques associées Début d’affichage « Prise de contact » First...
Comment améliorer votre TTFB pour accélérer votre site web ?

Comment améliorer votre TTFB pour accélérer 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 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...
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...
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...