FAUSSE BONNE IDÉE (oui, je sais, il ne faut pas crier dans les allées d'un forum, navré si j'en est réveillé qui faisait la sieste).
Une page standard de linuxfr.org est constituée d'un nombre important d'images qu'elle partage avec les autres pages de linuxfr.org. En embarquant les images dans le HTML, le système de cache des navigateurs est alors incapable de jouer son rôle et de diminuer la bande passante utilisée pour charger les pages en ne téléchargeant pas les images qu'il a en cache (puisque pour lui ce ne sont pas des ressources extérieures).
De plus, embarquer une image dans une page HTML signifie aussi augmenter la taille du HTML envoyé, augmentation proportionnelle au nombre de fois où les images apparaissent dans le document. En cas d'encodage Base64, une image est 33% plus "grosse" que l'originale, inflation il est vrai partiellement effacée par un transport compressif des documents HTML (mais tout de même avec une surcharge de 2 à 3% — cf.: http://en.wikipedia.org/wiki/Data_URI_scheme ).
Au final, le document HTML est donc plus gros de la taille des images embarquées, ce qui peut être non négligeable comme avec la page de garde de linuxfr.org (~100ko de HTML brut, ~20ko transféré comprimé, plus une 20aine d'images de catégorie — celles pillées en général par les autres sites — qui font en moyenne 3 à 4ko et sont très peu compressible (voire pas du tout), soit 60 à 80ko à renvoyer à chaque fois que le contenu de la page change).
Une meilleure façon de faire serait plutôt de rendre les URLs des images dépendantes du temps et, une fois leur temps fait, de recycler ces URLs pour en faire une redirection (301 "Moved Permanently") vers l'image dénonciatrice, celle-ci étant délivrée avec une temporisation de mise en cache très lointaine. Ainsi, si une personne navigant sur plusieurs sites indélicats doit charger plusieurs images "pillées" en dehors de leur "période optimale de fraîcheur", le navigateur fera autant de requête que d'image (tout au moins au premier chargement des pages), mais étant toujours redirigé vers la même image, ne téléchargera celle-ci qu'une seule fois.
[^] # Re: Ou alors, tout faire en embedded
Posté par Frédéric Blanc . En réponse à la dépêche De l'utilisation abusive des images des autres et du vol de bande passante. Évalué à 1.
Une page standard de linuxfr.org est constituée d'un nombre important d'images qu'elle partage avec les autres pages de linuxfr.org. En embarquant les images dans le HTML, le système de cache des navigateurs est alors incapable de jouer son rôle et de diminuer la bande passante utilisée pour charger les pages en ne téléchargeant pas les images qu'il a en cache (puisque pour lui ce ne sont pas des ressources extérieures).
De plus, embarquer une image dans une page HTML signifie aussi augmenter la taille du HTML envoyé, augmentation proportionnelle au nombre de fois où les images apparaissent dans le document. En cas d'encodage Base64, une image est 33% plus "grosse" que l'originale, inflation il est vrai partiellement effacée par un transport compressif des documents HTML (mais tout de même avec une surcharge de 2 à 3% — cf.: http://en.wikipedia.org/wiki/Data_URI_scheme ).
Au final, le document HTML est donc plus gros de la taille des images embarquées, ce qui peut être non négligeable comme avec la page de garde de linuxfr.org (~100ko de HTML brut, ~20ko transféré comprimé, plus une 20aine d'images de catégorie — celles pillées en général par les autres sites — qui font en moyenne 3 à 4ko et sont très peu compressible (voire pas du tout), soit 60 à 80ko à renvoyer à chaque fois que le contenu de la page change).
Une meilleure façon de faire serait plutôt de rendre les URLs des images dépendantes du temps et, une fois leur temps fait, de recycler ces URLs pour en faire une redirection (301 "Moved Permanently") vers l'image dénonciatrice, celle-ci étant délivrée avec une temporisation de mise en cache très lointaine. Ainsi, si une personne navigant sur plusieurs sites indélicats doit charger plusieurs images "pillées" en dehors de leur "période optimale de fraîcheur", le navigateur fera autant de requête que d'image (tout au moins au premier chargement des pages), mais étant toujours redirigé vers la même image, ne téléchargera celle-ci qu'une seule fois.