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 :

• Testcase des différentes solutions envisageables
• Drupal IE CSS Optimizer Module
• via John Albin
• [1] : Résolution proposée par Microsoft

© Marin for Gatellier.be, 2010. | Permalink | 2 comments | Add to del.icio.us
Post tags: bug, concatenate, CSS, Drupal, IE, IE6, IE7, IE8, minify, Performances

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

© Marin for Gatellier.be, 2009. | Permalink | One comment | Add to del.icio.us
Post tags: addon, ContentEncoding, ContentEncodingDetector, ContentEncodingV04b, Firefox, gzip, performance

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 :

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 :

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...

© Marin for Gatellier.be, 2009. | Permalink | One comment | Add to del.icio.us
Post tags: estat, https, performance, ssl, tracking