Savez-vous où et comment se règle la négociation de fichiers sous Apache ?
Pour les langages, ok, mais par exemple pour les images, je ne mets
souvent que le nom du fichier sans l'extension et il va chercher ce
qu'il trouve. Mais dans quel ordre ?
http://httpd.apache.org/docs/2.2/content-negotiation.html ne m'a pas
beaucoup aidé.
Mon but est de pouvoir dire :
- que je veux des png avant tout (s'il existe des gif du même nom)
- qu'il aille chercher des .css.gz avant des .css
Si déjà j'ai une réponse, c'est beau mais j'ai une question auxiliaire :
est-ce qu'Apache met en cache un fichier qu'il compresse ?
Parce qu'activer la compression sur html, css, js, ça fait bcp de chose
à faire à chaque requête pour Apache.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Olivier Miakinen
Le 15/01/2010 17:36, Olivier Masson a écrit :
Savez-vous où et comment se règle la négociation de fichiers sous Apache ?
Non, mais note que toutes tes questions à propos du fonctionnement d'Apache sont en charte sur fciw.serveurs, où Patrick Mevzek répond en général assez vite, même après plusieurs mois d'inactivité du groupe. Bon, la réponse de Bernd n'a pas encore trouvé de réponse, mais il ne l'a posée qu'hier... ;-)
Le 15/01/2010 17:36, Olivier Masson a écrit :
Savez-vous où et comment se règle la négociation de fichiers sous Apache ?
Non, mais note que toutes tes questions à propos du fonctionnement
d'Apache sont en charte sur fciw.serveurs, où Patrick Mevzek répond en
général assez vite, même après plusieurs mois d'inactivité du groupe.
Bon, la réponse de Bernd n'a pas encore trouvé de réponse, mais il ne
l'a posée qu'hier... ;-)
Savez-vous où et comment se règle la négociation de fichiers sous Apache ?
Non, mais note que toutes tes questions à propos du fonctionnement d'Apache sont en charte sur fciw.serveurs, où Patrick Mevzek répond en général assez vite, même après plusieurs mois d'inactivité du groupe. Bon, la réponse de Bernd n'a pas encore trouvé de réponse, mais il ne l'a posée qu'hier... ;-)
Olivier Masson
Le 15/01/2010 18:04, Olivier Miakinen a écrit :
Le 15/01/2010 17:36, Olivier Masson a écrit :
Savez-vous où et comment se règle la négociation de fichiers sous Apache ?
Non, mais note que toutes tes questions à propos du fonctionnement d'Apache sont en charte sur fciw.serveurs, où Patrick Mevzek répond en général assez vite, même après plusieurs mois d'inactivité du groupe. Bon, la réponse de Bernd n'a pas encore trouvé de réponse, mais il ne l'a posée qu'hier... ;-)
Merci, je vais poster là-bas alors.
Le 15/01/2010 18:04, Olivier Miakinen a écrit :
Le 15/01/2010 17:36, Olivier Masson a écrit :
Savez-vous où et comment se règle la négociation de fichiers sous Apache ?
Non, mais note que toutes tes questions à propos du fonctionnement
d'Apache sont en charte sur fciw.serveurs, où Patrick Mevzek répond en
général assez vite, même après plusieurs mois d'inactivité du groupe.
Bon, la réponse de Bernd n'a pas encore trouvé de réponse, mais il ne
l'a posée qu'hier... ;-)
Savez-vous où et comment se règle la négociation de fichiers sous Apache ?
Non, mais note que toutes tes questions à propos du fonctionnement d'Apache sont en charte sur fciw.serveurs, où Patrick Mevzek répond en général assez vite, même après plusieurs mois d'inactivité du groupe. Bon, la réponse de Bernd n'a pas encore trouvé de réponse, mais il ne l'a posée qu'hier... ;-)
Merci, je vais poster là-bas alors.
Olivier Miakinen
Le 15/01/2010 18:04, j'écrivais :
la réponse de Bernd n'a pas encore trouvé de réponse
^^^^^^^ ^^^^^^^ Qu'est-ce que je peux raconter comme conneries, parfois !
(suivi nulle part)
Le 15/01/2010 18:04, j'écrivais :
la réponse de Bernd n'a pas encore trouvé de réponse
^^^^^^^ ^^^^^^^
Qu'est-ce que je peux raconter comme conneries, parfois !
la réponse de Bernd n'a pas encore trouvé de réponse
^^^^^^^ ^^^^^^^ Qu'est-ce que je peux raconter comme conneries, parfois !
(suivi nulle part)
SAM
Le 1/15/10 5:36 PM, Olivier Masson a écrit :
Bonjour,
Savez-vous où et comment se règle la négociation de fichiers sous Apache ? Pour les langages, ok, mais par exemple pour les images, je ne mets souvent que le nom du fichier sans l'extension et il va chercher ce qu'il trouve. Mais dans quel ordre ?
Apache n'a pas besoin des extensions pour trouver un fichier ... à condition qu'il n'y ait pas plusieurs fichiers (et/ou dossier ?) de même nom !
http://httpd.apache.org/docs/2.2/content-negotiation.html ne m'a pas beaucoup aidé.
Avant d'aller voir à mon avis les extensions ne lui servent qu'à - savoir s'il faut passer le fichier à un interpréteur (php, ssi, cgi ...) - choisir le fichier de la langue : fr, en, es, etc. en fonction des préfs du navigateur : <http://stephane.moriaux.pagesperso-orange.fr/truc/bonjour> en fonction de l'url : <http://stephane.moriaux.pagesperso-orange.fr/truc/bonjour.en> <http://stephane.moriaux.pagesperso-orange.fr/truc/bonjour.fr> Les fichiers y sont : bonjour.en.htm et bonjour.en.htm S'ils avaient été : bonjour.htm.en et bonjour.htm.en les liens personnalisés ci-dessus n'eussent pas fonctionné. - pour les jpg, gif, png, tif etc. ... maintenant que j'ai lu en diagonale et pour ta question, ça semble assez simple :
Content-type: image/gif; qs=0.5
il n'est peut-être pas obligatoire de le stipuler dans un fichier extérieur ? sans doute à placer vers la fin des instructions de type mime ?
<IfModule mod_mime.c>
Content-type: image/gif; qs=0.5
</IfModule>
Les png ou jpg ou tif (les !gif quoi) seront choisies d'abord sauf à ce que l'extension 'gif' soit donnée ... et que le navigateur n'ait pas dit qu'il n'en voulait pas ;-) ou qu'il n'ait pas lui-même indiqué un qs différent ?
<IfModule mod_mime.c>
Content-type: image/png; qs=0.9
Content-type: image/jpeg; qs=0.8
Content-type: image/gif; qs=0.5
Content-type: image/tiff; qs=0.1
</IfModule>
Mon but est de pouvoir dire : - que je veux des png avant tout (s'il existe des gif du même nom)
Déjà ça va dépendre du navigateur, des en-têtes qu'il envoie.
Il faut que tu fasses ta css en conséquence : .fond { background:url(truc.png) !important; background:url(truc.gif) }
- qu'il aille chercher des .css.gz avant des .css
Ne suffit-il pas de coder <link href="styles.gz" ? si le fichier est : 'styles.gz.css'
Mébon ... pour des css ... - ça va pas compresser terrible, non ? ... encore que ... y en a qui en mettent des tartines (dont de moult bis-repetita) - et puis ... ça file dans le cache du navigateur donc pas à charger si souvent
Si déjà j'ai une réponse, c'est beau mais j'ai une question auxiliaire : est-ce qu'Apache met en cache un fichier qu'il compresse ?
C'est pas impossible, mais no sè.
Parce qu'activer la compression sur html, css, js, ça fait bcp de chose à faire à chaque requête pour Apache.
Vu la vitesse à laquelle ça va ... il ne sera guère impressionné
Néanmoins on ne compresse que ce qu'il y a avantage à l'être : ( envoi direct - (compression + envoi allégé + décompression) ) > 0
À mon avis, c'est surtout intéressant pour les lourds tableaux (où la compression est très bonne) Et puis ... si ça fourmille d'images ... à quoi bon gagner qques ko face à des Mo ?
-- sm
Le 1/15/10 5:36 PM, Olivier Masson a écrit :
Bonjour,
Savez-vous où et comment se règle la négociation de fichiers sous Apache ?
Pour les langages, ok, mais par exemple pour les images, je ne mets
souvent que le nom du fichier sans l'extension et il va chercher ce
qu'il trouve. Mais dans quel ordre ?
Apache n'a pas besoin des extensions pour trouver un fichier
... à condition qu'il n'y ait pas plusieurs fichiers (et/ou dossier ?)
de même nom !
http://httpd.apache.org/docs/2.2/content-negotiation.html ne m'a pas
beaucoup aidé.
Avant d'aller voir
à mon avis les extensions ne lui servent qu'à
- savoir s'il faut passer le fichier à un interpréteur
(php, ssi, cgi ...)
- choisir le fichier de la langue : fr, en, es, etc.
en fonction des préfs du navigateur :
<http://stephane.moriaux.pagesperso-orange.fr/truc/bonjour>
en fonction de l'url :
<http://stephane.moriaux.pagesperso-orange.fr/truc/bonjour.en>
<http://stephane.moriaux.pagesperso-orange.fr/truc/bonjour.fr>
Les fichiers y sont : bonjour.en.htm et bonjour.en.htm
S'ils avaient été : bonjour.htm.en et bonjour.htm.en
les liens personnalisés ci-dessus n'eussent pas fonctionné.
- pour les jpg, gif, png, tif etc. ...
maintenant que j'ai lu en diagonale et pour ta question,
ça semble assez simple :
Content-type: image/gif; qs=0.5
il n'est peut-être pas obligatoire de le stipuler dans un fichier
extérieur ?
sans doute à placer vers la fin des instructions de type mime ?
<IfModule mod_mime.c>
Content-type: image/gif; qs=0.5
</IfModule>
Les png ou jpg ou tif (les !gif quoi) seront choisies d'abord
sauf à ce que l'extension 'gif' soit donnée
... et que le navigateur n'ait pas dit qu'il n'en voulait pas ;-)
ou qu'il n'ait pas lui-même indiqué un qs différent ?
<IfModule mod_mime.c>
Content-type: image/png; qs=0.9
Content-type: image/jpeg; qs=0.8
Content-type: image/gif; qs=0.5
Content-type: image/tiff; qs=0.1
</IfModule>
Mon but est de pouvoir dire :
- que je veux des png avant tout (s'il existe des gif du même nom)
Déjà ça va dépendre du navigateur, des en-têtes qu'il envoie.
Il faut que tu fasses ta css en conséquence :
.fond { background:url(truc.png) !important;
background:url(truc.gif)
}
- qu'il aille chercher des .css.gz avant des .css
Ne suffit-il pas de coder
<link href="styles.gz" ?
si le fichier est : 'styles.gz.css'
Mébon ... pour des css ...
- ça va pas compresser terrible, non ?
... encore que ... y en a qui en mettent des tartines
(dont de moult bis-repetita)
- et puis ... ça file dans le cache du navigateur
donc pas à charger si souvent
Si déjà j'ai une réponse, c'est beau mais j'ai une question auxiliaire :
est-ce qu'Apache met en cache un fichier qu'il compresse ?
C'est pas impossible, mais no sè.
Parce qu'activer la compression sur html, css, js, ça fait bcp de chose
à faire à chaque requête pour Apache.
Vu la vitesse à laquelle ça va ... il ne sera guère impressionné
Néanmoins on ne compresse que ce qu'il y a avantage à l'être :
( envoi direct - (compression + envoi allégé + décompression) ) > 0
À mon avis, c'est surtout intéressant pour les lourds tableaux (où la
compression est très bonne)
Et puis ... si ça fourmille d'images ...
à quoi bon gagner qques ko face à des Mo ?
Savez-vous où et comment se règle la négociation de fichiers sous Apache ? Pour les langages, ok, mais par exemple pour les images, je ne mets souvent que le nom du fichier sans l'extension et il va chercher ce qu'il trouve. Mais dans quel ordre ?
Apache n'a pas besoin des extensions pour trouver un fichier ... à condition qu'il n'y ait pas plusieurs fichiers (et/ou dossier ?) de même nom !
http://httpd.apache.org/docs/2.2/content-negotiation.html ne m'a pas beaucoup aidé.
Avant d'aller voir à mon avis les extensions ne lui servent qu'à - savoir s'il faut passer le fichier à un interpréteur (php, ssi, cgi ...) - choisir le fichier de la langue : fr, en, es, etc. en fonction des préfs du navigateur : <http://stephane.moriaux.pagesperso-orange.fr/truc/bonjour> en fonction de l'url : <http://stephane.moriaux.pagesperso-orange.fr/truc/bonjour.en> <http://stephane.moriaux.pagesperso-orange.fr/truc/bonjour.fr> Les fichiers y sont : bonjour.en.htm et bonjour.en.htm S'ils avaient été : bonjour.htm.en et bonjour.htm.en les liens personnalisés ci-dessus n'eussent pas fonctionné. - pour les jpg, gif, png, tif etc. ... maintenant que j'ai lu en diagonale et pour ta question, ça semble assez simple :
Content-type: image/gif; qs=0.5
il n'est peut-être pas obligatoire de le stipuler dans un fichier extérieur ? sans doute à placer vers la fin des instructions de type mime ?
<IfModule mod_mime.c>
Content-type: image/gif; qs=0.5
</IfModule>
Les png ou jpg ou tif (les !gif quoi) seront choisies d'abord sauf à ce que l'extension 'gif' soit donnée ... et que le navigateur n'ait pas dit qu'il n'en voulait pas ;-) ou qu'il n'ait pas lui-même indiqué un qs différent ?
<IfModule mod_mime.c>
Content-type: image/png; qs=0.9
Content-type: image/jpeg; qs=0.8
Content-type: image/gif; qs=0.5
Content-type: image/tiff; qs=0.1
</IfModule>
Mon but est de pouvoir dire : - que je veux des png avant tout (s'il existe des gif du même nom)
Déjà ça va dépendre du navigateur, des en-têtes qu'il envoie.
Il faut que tu fasses ta css en conséquence : .fond { background:url(truc.png) !important; background:url(truc.gif) }
- qu'il aille chercher des .css.gz avant des .css
Ne suffit-il pas de coder <link href="styles.gz" ? si le fichier est : 'styles.gz.css'
Mébon ... pour des css ... - ça va pas compresser terrible, non ? ... encore que ... y en a qui en mettent des tartines (dont de moult bis-repetita) - et puis ... ça file dans le cache du navigateur donc pas à charger si souvent
Si déjà j'ai une réponse, c'est beau mais j'ai une question auxiliaire : est-ce qu'Apache met en cache un fichier qu'il compresse ?
C'est pas impossible, mais no sè.
Parce qu'activer la compression sur html, css, js, ça fait bcp de chose à faire à chaque requête pour Apache.
Vu la vitesse à laquelle ça va ... il ne sera guère impressionné
Néanmoins on ne compresse que ce qu'il y a avantage à l'être : ( envoi direct - (compression + envoi allégé + décompression) ) > 0
À mon avis, c'est surtout intéressant pour les lourds tableaux (où la compression est très bonne) Et puis ... si ça fourmille d'images ... à quoi bon gagner qques ko face à des Mo ?
-- sm
SAM
Le 1/15/10 6:04 PM, Olivier Miakinen a écrit :
Le 15/01/2010 17:36, Olivier Masson a écrit :
Savez-vous où et comment se règle la négociation de fichiers sous Apache ?
Non, mais note que toutes tes questions à propos du fonctionnement
pour les langues c'est assez facile yaka lire le fichier de config c'est assez bien commenté
Le blème qui m'apparait le plus important est d'abord : les négociations navigateur<->serveur qui, si j'ai bien compris, prennent le pas sur les petites manies qu'on aura concoctées amoureusement dans son fichier de config
d'Apache sont en charte sur fciw.serveurs, où Patrick Mevzek répond en général assez vite, même après plusieurs mois d'inactivité du groupe. Bon, la réponse de Bernd n'a pas encore trouvé de réponse, mais il ne l'a posée qu'hier... ;-)
S'il fréquente aussi le NG php ... il ne s'étonnera pas de ne pas recevoir de question à sa réponse (ou lycée de Versailles) dans l'heure ;-)
-- sm
Le 1/15/10 6:04 PM, Olivier Miakinen a écrit :
Le 15/01/2010 17:36, Olivier Masson a écrit :
Savez-vous où et comment se règle la négociation de fichiers sous Apache ?
Non, mais note que toutes tes questions à propos du fonctionnement
pour les langues c'est assez facile
yaka lire le fichier de config
c'est assez bien commenté
Le blème qui m'apparait le plus important est d'abord :
les négociations navigateur<->serveur
qui, si j'ai bien compris, prennent le pas sur les petites manies qu'on
aura concoctées amoureusement dans son fichier de config
d'Apache sont en charte sur fciw.serveurs, où Patrick Mevzek répond en
général assez vite, même après plusieurs mois d'inactivité du groupe.
Bon, la réponse de Bernd n'a pas encore trouvé de réponse, mais il ne
l'a posée qu'hier... ;-)
S'il fréquente aussi le NG php ...
il ne s'étonnera pas de ne pas recevoir de question à sa réponse
(ou lycée de Versailles) dans l'heure
;-)
Savez-vous où et comment se règle la négociation de fichiers sous Apache ?
Non, mais note que toutes tes questions à propos du fonctionnement
pour les langues c'est assez facile yaka lire le fichier de config c'est assez bien commenté
Le blème qui m'apparait le plus important est d'abord : les négociations navigateur<->serveur qui, si j'ai bien compris, prennent le pas sur les petites manies qu'on aura concoctées amoureusement dans son fichier de config
d'Apache sont en charte sur fciw.serveurs, où Patrick Mevzek répond en général assez vite, même après plusieurs mois d'inactivité du groupe. Bon, la réponse de Bernd n'a pas encore trouvé de réponse, mais il ne l'a posée qu'hier... ;-)
S'il fréquente aussi le NG php ... il ne s'étonnera pas de ne pas recevoir de question à sa réponse (ou lycée de Versailles) dans l'heure ;-)
-- sm
Olivier Masson
Le 15/01/2010 20:12, SAM a écrit :
Apache n'a pas besoin des extensions pour trouver un fichier ... à condition qu'il n'y ait pas plusieurs fichiers (et/ou dossier ?) de même nom !
Si, ça fonctionne, mais avec une priorité, apparemment par défaut.
<IfModule mod_mime.c>
Content-type: image/png; qs=0.9
Content-type: image/jpeg; qs=0.8
Content-type: image/gif; qs=0.5
Content-type: image/tiff; qs=0.1
</IfModule>
Je vais essayer ça.
Déjà ça va dépendre du navigateur, des en-têtes qu'il envoie.
J'en ai pas vu concernant autre chose que la langue et le fait qu'il accepte gzip. Jamais vu de "je préfère du svg puis du png32...".
Il faut que tu fasses ta css en conséquence : .fond { background:url(truc.png) !important; background:url(truc.gif) }
Tu penses bien que c'est un raisonnement global. Je ne vais pas m'amuser à ajouter ça à toutes les images. De plus, ça concerne d'autres types de fichiers.
Ne suffit-il pas de coder <link href="styles.gz" ? si le fichier est : 'styles.gz.css'
Oui, et il se passe quoi si le .gz n'existe pas ? Encore une fois : raisonnement global. Je ne vais pas m'amuser à vérifier l'existence d'un fichier, ni même faire un file_exists en PHP.
Mébon ... pour des css ... - ça va pas compresser terrible, non ? ... encore que ... y en a qui en mettent des tartines (dont de moult bis-repetita) - et puis ... ça file dans le cache du navigateur donc pas à charger si souvent
ça te ressemble comme réflexion ça ! Donc tu préfères bouffer 100k de JS et 50k de CSS plutôt que respectivement 30 et 15 ? J'ai déjà parlé de raisonnement global ? Pense que j'ai un script qui va compresser (supprimer commentaires et caractères superflus), puis gzipper. Mais que je ne gzippe pas si le fichier est trop petit. Et que je conserve de toutes façons tous les fichiers originaux pour garder les commentaires et éditer facilement.
Vu la vitesse à laquelle ça va ... il ne sera guère impressionné
Pour un site qui fait 100 visites/mois avec 10 pages statiques, non. Mais selon le serveur web, le type de site, le nombre de visiteurs, ça peut grimper vite. J'ai déjà baissé le niveau de compression pour text/html (que j'ai laissé à la volée par Apache.)
Néanmoins on ne compresse que ce qu'il y a avantage à l'être : ( envoi direct - (compression + envoi allégé + décompression) ) > 0
À mon avis, c'est surtout intéressant pour les lourds tableaux (où la compression est très bonne) Et puis ... si ça fourmille d'images ...
L'intérêt est aussi au niveau de l'exécution. Il faut que le DOM soit entièrement chargé, le plus rapidement possible. Les images peuvent se charger moins rapidement, c'est moins génant.
Le 15/01/2010 20:12, SAM a écrit :
Apache n'a pas besoin des extensions pour trouver un fichier
... à condition qu'il n'y ait pas plusieurs fichiers (et/ou dossier ?)
de même nom !
Si, ça fonctionne, mais avec une priorité, apparemment par défaut.
<IfModule mod_mime.c>
Content-type: image/png; qs=0.9
Content-type: image/jpeg; qs=0.8
Content-type: image/gif; qs=0.5
Content-type: image/tiff; qs=0.1
</IfModule>
Je vais essayer ça.
Déjà ça va dépendre du navigateur, des en-têtes qu'il envoie.
J'en ai pas vu concernant autre chose que la langue et le fait qu'il
accepte gzip. Jamais vu de "je préfère du svg puis du png32...".
Il faut que tu fasses ta css en conséquence :
.fond { background:url(truc.png) !important;
background:url(truc.gif)
}
Tu penses bien que c'est un raisonnement global. Je ne vais pas m'amuser
à ajouter ça à toutes les images.
De plus, ça concerne d'autres types de fichiers.
Ne suffit-il pas de coder
<link href="styles.gz" ?
si le fichier est : 'styles.gz.css'
Oui, et il se passe quoi si le .gz n'existe pas ?
Encore une fois : raisonnement global. Je ne vais pas m'amuser à
vérifier l'existence d'un fichier, ni même faire un file_exists en PHP.
Mébon ... pour des css ...
- ça va pas compresser terrible, non ?
... encore que ... y en a qui en mettent des tartines
(dont de moult bis-repetita)
- et puis ... ça file dans le cache du navigateur
donc pas à charger si souvent
ça te ressemble comme réflexion ça !
Donc tu préfères bouffer 100k de JS et 50k de CSS plutôt que
respectivement 30 et 15 ?
J'ai déjà parlé de raisonnement global ?
Pense que j'ai un script qui va compresser (supprimer commentaires et
caractères superflus), puis gzipper. Mais que je ne gzippe pas si le
fichier est trop petit. Et que je conserve de toutes façons tous les
fichiers originaux pour garder les commentaires et éditer facilement.
Vu la vitesse à laquelle ça va ... il ne sera guère impressionné
Pour un site qui fait 100 visites/mois avec 10 pages statiques, non.
Mais selon le serveur web, le type de site, le nombre de visiteurs, ça
peut grimper vite. J'ai déjà baissé le niveau de compression pour
text/html (que j'ai laissé à la volée par Apache.)
Néanmoins on ne compresse que ce qu'il y a avantage à l'être :
( envoi direct - (compression + envoi allégé + décompression) ) > 0
À mon avis, c'est surtout intéressant pour les lourds tableaux (où la
compression est très bonne)
Et puis ... si ça fourmille d'images ...
L'intérêt est aussi au niveau de l'exécution. Il faut que le DOM soit
entièrement chargé, le plus rapidement possible.
Les images peuvent se charger moins rapidement, c'est moins génant.
Apache n'a pas besoin des extensions pour trouver un fichier ... à condition qu'il n'y ait pas plusieurs fichiers (et/ou dossier ?) de même nom !
Si, ça fonctionne, mais avec une priorité, apparemment par défaut.
<IfModule mod_mime.c>
Content-type: image/png; qs=0.9
Content-type: image/jpeg; qs=0.8
Content-type: image/gif; qs=0.5
Content-type: image/tiff; qs=0.1
</IfModule>
Je vais essayer ça.
Déjà ça va dépendre du navigateur, des en-têtes qu'il envoie.
J'en ai pas vu concernant autre chose que la langue et le fait qu'il accepte gzip. Jamais vu de "je préfère du svg puis du png32...".
Il faut que tu fasses ta css en conséquence : .fond { background:url(truc.png) !important; background:url(truc.gif) }
Tu penses bien que c'est un raisonnement global. Je ne vais pas m'amuser à ajouter ça à toutes les images. De plus, ça concerne d'autres types de fichiers.
Ne suffit-il pas de coder <link href="styles.gz" ? si le fichier est : 'styles.gz.css'
Oui, et il se passe quoi si le .gz n'existe pas ? Encore une fois : raisonnement global. Je ne vais pas m'amuser à vérifier l'existence d'un fichier, ni même faire un file_exists en PHP.
Mébon ... pour des css ... - ça va pas compresser terrible, non ? ... encore que ... y en a qui en mettent des tartines (dont de moult bis-repetita) - et puis ... ça file dans le cache du navigateur donc pas à charger si souvent
ça te ressemble comme réflexion ça ! Donc tu préfères bouffer 100k de JS et 50k de CSS plutôt que respectivement 30 et 15 ? J'ai déjà parlé de raisonnement global ? Pense que j'ai un script qui va compresser (supprimer commentaires et caractères superflus), puis gzipper. Mais que je ne gzippe pas si le fichier est trop petit. Et que je conserve de toutes façons tous les fichiers originaux pour garder les commentaires et éditer facilement.
Vu la vitesse à laquelle ça va ... il ne sera guère impressionné
Pour un site qui fait 100 visites/mois avec 10 pages statiques, non. Mais selon le serveur web, le type de site, le nombre de visiteurs, ça peut grimper vite. J'ai déjà baissé le niveau de compression pour text/html (que j'ai laissé à la volée par Apache.)
Néanmoins on ne compresse que ce qu'il y a avantage à l'être : ( envoi direct - (compression + envoi allégé + décompression) ) > 0
À mon avis, c'est surtout intéressant pour les lourds tableaux (où la compression est très bonne) Et puis ... si ça fourmille d'images ...
L'intérêt est aussi au niveau de l'exécution. Il faut que le DOM soit entièrement chargé, le plus rapidement possible. Les images peuvent se charger moins rapidement, c'est moins génant.