Attention ! A tous ceux qui tentent d’optimiser leurs sites internet avec des conseils donnés par exemple par PageSpeed ou YSlow, réfléchissez avant de gzipper vos feuilles de style ! Il semble que Safari ne les comprennent pas, et donc n’affiche pas la page avec son CSS. N’oubliez pas non plus que Safari représente en moyenne 6% des visites sur le web, donc la proportion de visiteurs utilisant ce navigateur n’est pas négligeable.
Pour les utilisateurs de Safari, si vous tenez à l’environnement Apple, vous pouvez toujours utiliser Google Chrome, qui fonctionne à partir du moteur de rendu Webkit (comme Safari), Webkit ayant été développé à l’origine par Apple (mais dérivant de KHTML, qui vient de l’environnement KDE). Donc pour résumer, en utilisant Chrome, vous utilisez encore un produit contenant des composant Apple.
Pour les autres, j’ai fait le test, Chrome, Firefox et Internet Explorer passent très bien.
En cherchant sur internet, je n’ai pas trouvé beaucoup de monde reportant cette erreur (mais il est possible que peu de sites compressent leur CSS), à part là :
Safari 4 Beta fails to decompress a .js.gz file. It appears it does not recognize the headers sent(?)
Anyone had similar experiences with Safari 4? What version of IE were you referring to?
Safari 4 étant la dernière version de Safari, je me demande donc si cette version supporte bien les CSS gzippés, ou bien si c’est moi qui ais mal fait quelque chose. Bizarre tout de même que Firefox, Chrome et Internet Explorer (je n’ai pas testé sous Opéra) comprennent bien la ligne :
<link rel= »stylesheet » type= »text/css » href= »/style.css.gz » media= »all » />
Alors que Safari ne le comprend pas…
Remarquez qu’il est possible, enfin, que l’erreur vienne de la méthode employés. Pour ma part, je n’ai pas accès au paramétrage de mon serveur, et donc j’encode « à la main » le CSS en gzip (avec 7-zip, si vous voulez tout savoir), alors que la méthode souvent conseillée est d’activer le mod_deflate de PHP sur son serveur et de faire une petite manipulation après.
Si vous connaissez la réponse ou la solution a ce « bug » (qui n’en est peut-être pas un du tout), je reste preneur.
Enfin une raison à tout ça, enfin entre guillemets… Obligé de repasser sous Firefox rien que pour toi en attendant une solution… 😉
Non, reste sous Safari, je viens de virer le gzippé, donc normalement ça devrait marcher (je vais nettoyer le cache afin d'être sûr).
Ça fonctionne 😉
Je rencontre le même pb.
Sous Opéra/Firefox/Chrome, ça fonctionne. Pas sur Safari, alors qu’il supporte l’encoding gzip.
Pareil, et le pire c’est que c’est le client lui même qui la remarqué sur son site bien plus tard car il utilise Safari.
C’est navrant car la compression en gzip m’avait fait gagner près de 60% en vitesse.
Je continue les recherches.
J’ai trouvé une solution depuis : j’ai deux versions (générées automatiquement bien sûr), une en GZ et l’autre en CSS. Je gère automatiquement celle à fournir au client, CSS pour Safari, GZ pour les autres.
J’ai pensé également a cette solution mais je n’ai pas les connaissances en programmation pour improviser.
Si tu est d’attaque pour un petit article sur la solution détaillé, tu en sauverais plus d’un 😀
Ce serait un peu long car j’ai créé une bibliothèque PHP de 10 Ko qui rassemble et compresse CSS et JS :
– rassemblement des fichiers par hiérarchie (untel dépend de untel)
– réduction en taille par suppression des commentaires et des espaces
– compression avec l’algo de Edwards (eval…)
– compression GZIP
Tout ça avec MAJ automatique si changement de l’un des fichiers (comparaison de la date du précédent fichier avec les dates des fichiers assemblés). On est programmeur ou pas !
Au final, pour le Javascript, j’ai 250 ko de code initial dans 15 fichiers pour au final 40 Ko de dans 9 fichiers.
Côté CSS, 78 Ko dans 12 fichiers font 12 Ko dans 7 fichiers.
J’ai plusieurs fichiers finaux car, selon chaque page, le site ne charge que le minimum requis, parfois 2 fichiers CSS (tout en automatique, évidemment)
Côté rapidité, c’est très efficace (j’ai fait des tests YSlow et compagnie), mon site mets 2 secondes à charger (3 à 4 fois mieux que mes concurrents).
Grosso modo, pour faire TRES simple, tu peux essayer juste de tester la variable HTTP_USER_AGENT :
if (strpos(strtolower($_SERVER[« HTTP_USER_AGENT »]), « safari »)!==false)
$compressionGZIP=false;
else
$compressionGZIP=true;
if ($estJS) $ext= ».js »; else $ext= ».css »;
if ($compressionGZIP)
$ext.= ».gz »;
Après. il faut juste charger les fichiers.
Pas mal du tout la différence entre tes fichiers initiaux et les fichiers compressés!
Bah en fait j’ai trouvé encore plus simple pour que safari comprenne les gzip:
remplacer fichier.gz par fichier.jgz
Et voila!
Ah tiens, je ne connaissais pas cette possibilité. Merci.
http://www.webveteran.com/blog/index.php/web-coding/coldfusion/fix-for-safari-and-gzip-compressed-javascripts/
Pour les CSS, c’est CGZ alors ?
Je ne pense pas, je vais faire des tests et te reviendrais dessus.
@Desfossez Thomas et @adr_elo: Bonjour à vous deux.
Alors en fait, y’a deux choses. L’encodage du contenu et son extension. En clair, il est possible d’avoir un fichier .css qui en fait est gzippé. C’st ce que fait Apache avec le mod_deflate (je crois), et Nginx le fait aussi (il faut avoir un css et un .css.gz avec exactement le même nom dans le même dossier). Ce qui se passe, c’est que si ce mod est activé, quand vous demander le fichier .css à Apache, il regarde dans le dossier si y’a pas un .css.gz, et si oui, il vous le renvoie, mais avec le nom « .css », auquel cas Safari le prend sans problème.
En fait Safari n’aime pas les CSS qui n’ont pas l’extension .css, c’est tout, mais il s’en fout si ils sont encodés en gz.