Bug: IE n’affiche pas mes CSS
Un magnifique bug (parmi de nombreux autres) existe dans Internet Explorer (IE6, IE7, IE8).
IE6, IE7, IE8 ne supportent pas plus de 31 fichiers CSS liés dans une page html (que se soit par tag <link rel="stylesheet" ...>
ou CSS @import
).
Toutes les CSS venant après la 31ème seront simplement ignorées !
Ok, ça n’est pas idéal, d’un point de vue performance, de splitter ses CSS mais des fois nous n’avons pas le choix. (Ex : Développement Drupal avec quelques modules rajoutant chacun sa propre CSS).
La solution pour Drupal :
Un module existe (il ne loade pas de CSS propre) : IE CSS Optimizer concatène les CSS trouvées dans les répertoires /modules/
d’un projet Drupal une fois configuré et activé.
Et si je n’emploie pas Drupal ? :
Comme Microsoft le suggère [1] :
To work around this limitation, combine multiple classes into a single style tag.
Pour contourner cette limitation, combinez les différentes classes dans un seul tag style.
Le plus simple est de vérifier si les CSS liées sont vraiment nécessaires et en supprimer si besoin. D’autres solutions de concaténation existent (voir la librairie Minify)
Liens relatifs :
Addon Firefox: Content Encoding Detector 0.4b
Dans le but de promouvoir un web plus rapide et donc plus respectueux de ses utilisateurs, je viens de créer un petit Addon Firefox qui promeut l’encodage des pages en GZIP.
Cet encodage permet de réduire drastiquement le poid des fichiers transférés entre le serveur web et votre navigateur.
Point de vue technique :
L’addon Content Encoding Detector soumet l’url de la page que vous visitez au service JSON-HEAD de Simon Willison.
Si le serveur retourne l’http_header “Content-Encoding”, l’icône de status Firefox est mise à jour pour refléter l’encodage.
L’addon est en cours de validation mais vous pouvez déjà le télécharger à sa page Mozilla Addons.
tag: ContentEncoding
Performances Web: Impact du SSL
Depuis quelques temps, avec l’apparition de l’extension Firebug YSLOW, je m’intéresse de près aux performances des sites web.
J’ai profité des conseils avisés de Steve Souders et d’Éric Daspet dans quelques projets réalisés chez Emakina.
Un d’entre eux, le site smart.brusselsairlines.com, permettait aux participants de recevoir une réduction augmentant avec le nombre de participants (revenez-y de temps pour les prochaines promotions).
La mesure des visites du sites est gérée par une société externe EStat. Et, bien que je leur ai demandé de la documentation sur l’implémentation de leur script de tracking, on emploie toujours le vieux bout de code qui date de la première version du site.
Hors, le script de tracking est appelé via HTTPS. Vous voyez où je veux en venir.
Mesure des connections avec HTTPS.
Résultats de la requête #5 :
URL: | https://prof.estat.com/js/m.js |
---|---|
Host: | prof.estat.com |
IP: | 194.126.157.11 |
Location: | Valbonne, France* |
Error/Status Code: | 200 |
Start Offset: | 1.04 s |
DNS Lookup: | 178 ms |
Initial Connection: | 171 ms |
SSL Negotiation: | 505 ms |
Time to First Byte: | 164 ms |
Content Download: | 2 ms |
Bytes In (downloaded): | 2.0 KB |
Bytes Out (uploaded): | 0.6 KB |
Analyse :
Sur un total de 1023 ms, 505 ms – soit presque 50% du temps de la requête – sont consacrées à la négociation SSL pour des données ne nécéssitant pas l’emploi du SSL…
N’ayant pas eu la documentation du fournisseur de service EStat, je me suis permis de tester la technique pour supprimer le protocole https lors de l’appel à la ressource.
J’ai donc refait le test en faisant un requête vers le même fichier JS, mais sans passer par HTTPS.
Mesure des connections sans HTTPS.
Résultats de la requête #5 :
URL: | //prof.estat.com/js/m.js |
---|---|
Host: | prof.estat.com |
IP: | 194.126.157.11 |
Location: | Valbonne, France* |
Error/Status Code: | 200 |
Start Offset: | 1.19 s |
DNS Lookup: | 56 ms |
Initial Connection: | 155 ms |
Time to First Byte: | 163 ms |
Content Download: | 3 ms |
Bytes In (downloaded): | 1.1 KB |
Bytes Out (uploaded): | 0.3 KB |
Verdict :
Le résultat est flagrant : 378 ms contre 1023, il n’y a pas photo.
Quand vous devez reprendre un vieux site et l’optimiser pour, entre autre, des raisons de performance, n’oubliez pas de tenir compte des ressources externes en https !
Et en plus si le fournisseur de service ne vous fourni pas de documentation, et n’active pas le Keep-Alive sur ses serveurs, vous pouvez vivement envisager de changer de prestataire ! À bon entendeur…
2 commentaires