Archives du mot-clef http

Experience de voici.fr

4 réponses

J’aime bien apporter un peu de retours d’expérience, pour montrer que toute la théorie fonctionne aussi en pratique. Certes il y a Yahoo!, Google, Amazon, mais ce sont des trop gros sites pour que le développeur moyen se sente impliqué.

Alors voilà, Charles-Christian Croix nous parle un peu de ce qui a été réalisé sur Voici.fr. La première étape se fait via une configuration des entêtes HTTP de cache de ezPublish puis une configuration de mod_gzip sur Apache, et enfin par une configuration de mod_expires, toujours sur Apache. Il fait de même plus tard sur une installation Dotclear. Lire la suite →

Google SDCH et HTTP

5 réponses

On vous a dit de compresser vos échanges HTTP avec gzip ou deflate, des les identifier avec des ETag, mais pouvons nous faire mieux ? C’est la question abordée par certaines équipes de Google (slides disponibles) en juin dernier aux conférences Velocity 2008. Ils partent du principe qu’une page web est composée de plusieurs éléments, dont certains sont communs à plusieurs pages et ne nécessitent pas d’être renvoyés.

Google propose donc un codage supplémentaire pour HTTP qui s’appelle SDCH, Lire la suite →

Quelques outils en ligne

5 réponses

Je vous avais présenté quelques outils, aujourd’hui en voilà trois autres, en ligne.

Le concept de ces outils est le même : on prend une URL, on lance la page, et on trace la cascade des requêtes HTTP avec quelques statistiques. C’est là qu’on voit le temps pris par chaque composant, par la somme des composants, et les éventuels problèmes de performance comme les scripts bloquants. Lire la suite →

Expires et Cache-Control, une date limite de consommation pour vos contenus

22 réponses

Je parle de détails et de ce que je rencontre dans mes lectures, et j’en oublie le principal. alors voilà, si vous ne devez retenir qu’une chose c’est d’utiliser des dates d’expiration explicites sur vos contenus.

Il s’agit d’informer le navigateur que votre contenu est valable pendant une certaine durée. Cela peut être dix minutes, une heure, un jour, un mois, ou plusieurs années. Tant que cette durée n’a pas expirée, le navigateur sait que son contenu est à jour, il peut donc éviter de le retélécharger. Vous gagnez du temps en évitant la requête HTTP et vous laissez de la place pour d’autres téléchargements. Au lieu de prendre une demi seconde, votre contenu sera lu quasiment instantanément. Lire la suite →

Analyse d’une requête HTTP – serveur et réseau

8 réponses

On parle de temps, de performance, mais finalement que mesure t-on ? La question n’est pas inutile puisque pour une même requête il y a bien trois étape visibles du point de vue du visiteur, cinq du point de vue du navigateur et autant pour le serveur. Alors, que mesure t-on ?

Lire la suite →

Et pour le mobile ?

Laisser une réponse

Les mobiles ont longtemps été une cible très spécifique à base de WAP. C’est maintenant révolu et on a de réels navigateurs complets avec javascript et CSS. Que peut-on faire de spécifique pour le Web mobile ?

C’est Jason Grigsby de cloudfour qui vient de donner une présentation « Going fast on the mobile web« . 

Les règles de base et les spécificités

En gros peu de surprises, les règles de base sont celles de Yahoo! et devraient être bien connues dans un contexte de faible bande passante : pas de cookie, minimisation, compression, cache agressif, moins de requêtes HTTP, etc. On voit deux spécificités : la mémoire et le processeur. On a donc quelques contraintes de plus : Lire la suite →

Privé ou public ?

7 réponses

La directive Cache-Control est une vrai mine d’or pour la gestion du cache, au risque même de faire un peu fourre-tout. Aujourd’hui je m’intéresse surtout aux notions de document public et de document privé.

Visibilité et autorisation de cache

Pour faire court, cette directive contient quatre paramètres de visibilité : public, private, no-cache et no-store. Lire la suite →

Pipelining : enchaîner les requêtes HTTP

7 réponses

Le pipelining HTTP c’est faire gérer au serveur une file de requêtes. Le navigateur envoie plusieurs requêtes à la suite les unes des autres sans attendre la réponse du serveur. Le serveur renvoie alors les réponses dès qu’il les a, potentiellement en parallèle aux requêtes du navigateur. Non seulement on utilise le principe de la connexion persistante, mais on évite d’attendre la réponse précédente avant d’envoyer la suite. Pour chaque ressource à télécharger après la première, c’est un aller-retour réseau à rien faire qui est évité. Lire la suite →

Keep-alive et connexions persistantes

3 réponses

La latence réseau a un impact très important sur les performances. Si les ressources sont zippées, que vos images sont correctement compressées, et que les fichiers textes sont minimisés, la latence peut devenir presque plus pénalisante que les téléchargements eux même. Lire la suite →