Piwigo 2.2

Posté par Pierrick Le Gall (site web personnel) le 05 avril 2011 à 09:00. Modéré par j.

Étiquettes :

avr.

2011

Piwigo est un logiciel libre de galerie photo pour le Web, créé en 2002. Piwigo propose des fonctionnalités simples et puissantes pour publier et gérer vos photos sur votre propre site Web.

Quelles nouveautés pour cette version 2.2 ? L’ajout de photos par les utilisateurs a été entièrement réécrit et devient beaucoup plus simple à configurer. L’outil de gestion par lot a également été réécrit. Vous pouvez désormais détecter et mettre à jour automatiquement vos thèmes et langues disponibles en quelques clics. Piwigo est désormais disponible en 37 langues.

Côté technique, un effort important a été engagé pour réduire les échanges entre le navigateur Web et le serveur Web, avec pour résultat une plus grande vitesse d’affichage des pages : fusion automatique des fichiers CSS et des fichiers JavaScript, utilisation de « sprites CSS » pour les icônes (un fichier image contient toutes les icônes).

Détaillons les changements entre Piwigo 2.1 et Piwigo 2.2 :

Fonctionnalités pour les utilisateurs :

nouvel ajout utilisateur : le greffon Community s’occupe de cette fonctionnalité. Avec un nouveau formulaire, les utilisateurs peuvent envoyer plusieurs photos à la fois, elles sont automatiquement redimensionnées et soumises à modération ;
oubliez les « catégories », les « éléments » ou les « images » : le vocabulaire change, les « catégories » deviennent des « albums » et les « éléments » ou « images » deviennent des « photos », tout simplement ;
nouvel outil de gestion par lot : d’abord vous filtrez, ensuite vous sélectionnez une liste de photos, puis vous leur appliquez une action (comme ajouter des tags). Le tout avec une interface utilisateur dynamique et qui progresse en fonction de vos choix ;
37 langues et 1 nouveau Language Switch : soient 14 de plus par apport à Piwigo 2.1.0 : le greffon Language Switch change d’affichage pour indiquer le nom de chaque langue en plus d’un drapeau ;
nouvelles options pour le tri des albums : en quelques clics, l’administrateur peut trier toute une arborescence d’albums ;
suppression ou redimensionnement des hautes définitions : pour gagner de la place ou de la bande passante sur votre hébergement, ou simplement pour éviter qu’on puisse récupérer vos photos au format original ;
des suppression de photos plus faciles : vous pouvez supprimer une photo précise sans passer par la gestion par lot, quelle que soit la méthode d’ajout de la photo (même par FTP) ;
lundi ou dimanche ? : selon les pays, certains commencent la semaine avec le lundi, d’autres avec le dimanche, ce qui se traduit par un affichage adapté dans la vue calendrier ;
rotation automatique : en fonction des informations EXIF contenues dans la photo, Piwigo la tournera automatiquement, histoire d’éviter les torticolis !
multi-site : possibilité de faire tourner plusieurs galeries à partir d’une seule installation Piwigo ;
suppression du mode « Conseiller » : il était compliqué à configurer, potentiellement dangereux et avait de l’impact sur de nombreux fichiers ;
tags orphelins. Piwigo détecte les tags orphelins (ceux qui ne sont liés à aucune photo) et propose de les supprimer en un seul clic ;
mises à jour automatiques pour les thèmes et les langues : Piwigo se connecte au gestionnaire d’extensions sur piwigo.org et vérifie si de nouvelles versions de vos thèmes et langues sont disponibles.

Fonctionnalités pour les développeurs :

ImageMagick. S’il est disponible, Piwigo utilise automatiquement ImageMagick à la place de GD pour le redimensionnement des photos. Contrairement à GD, ImageMagick conserve les métadonnées EXIF/IPTC dans la photo redimensionnée ;
fusion des fichiers CSS, fusion des fichiers JavaScript, des sprites CSS pour les icônes. Chaque thème et chaque greffon peut charger un ou plusieurs fichiers CSS / JavaScript. Avec la nouvelle fonctionnalité « combine_css », vos visiteurs ne téléchargeront qu’un seul fichier CSS. Avec la nouvelle fonctionnalité « combine_script », vos visiteurs ne téléchargeront qu’un seul fichier JavaScript (quand c’est possible, Piwigo fait au mieux). Au lieu d’avoir un fichier par icône, votre navigateur Web ne télécharge qu’un seul fichier pour toutes les icônes.

Mise à jour depuis une version antérieure de Piwigo

La mise à jour est très simple puisqu’elle est entièrement automatique grâce au greffon Piwigo Auto Upgrade. Avant de migrer, Piwigo vous dira si certains de vos thèmes et greffons ne sont pas encore compatibles avec la version 2.2.

Aller plus loin

Notes de la version 2.2 (nombreuses captures d’écran) (422 clics)
Guide de mise à jour automatique (50 clics)
Piwigo (356 clics)
Démonstration en ligne (730 clics)

# MySQL

Posté par 🚲 Tanguy Ortolo (site web personnel) le 05 avril 2011 à 10:27. Évalué à 5.

Bravo, ça a l'air bien fichu, je passerais bien de Gallery 2 à Piwigo, moi.

Mais ça nécessite une base de données MySQL, n'est-ce pas ? Est-il prévu de pouvoir s'en passer ? C'est quelque chose que je comprends de moins en moins, qu'un outil de gestion de site intimement lié au système de fichiers ait besoin d'une base de données plutôt que de se reposer sur des informations en système de fichiers.
- [^] # Re: MySQL
  
  Posté par Kévin Belliz le 05 avril 2011 à 10:49. Évalué à 3.
  
  J'imagine que c'est parce que la galerie ne fait pas seulement d'afficher des photos. On à les commentaires, les notes, les tags, les infos EXIF, ... Faut bien stocker tout ça quelque part.
  - [^] # Re: MySQL
    
    Posté par Juke (site web personnel) le 05 avril 2011 à 10:56. Évalué à 4.
    
    Le mardi 05 avril 2011 à 10:49 +0200, Bellisario Kevin a écrit :
    
    On à les commentaires, les notes, les tags, les infos EXIF, ...
    
    on peut pas stocker ça dans les données EXIF justement ?
    
    (peut etre pas les commentaires)
    - [^] # Re: MySQL
      
      Posté par Kévin Belliz le 05 avril 2011 à 11:09. Évalué à 2.
      
      Logiquement si, mais je pense que la limitation se situe au niveau de la rapidité et du nombre d'accès disque élevé. (Mais c'est possible que je me trompe, c'est seulement une hypothèse)
      - [^] # Re: MySQL
        
        Posté par Juke (site web personnel) le 05 avril 2011 à 11:17. Évalué à 2.
        
        Le mardi 05 avril 2011 à 11:09 +0200, Bellisario Kevin a écrit :
        
        je pense que la limitation se situe au niveau de la rapidité et du nombre d'accès disque élevé.
        
        Dans ce cas c'est le cache qu'il faut optimiser non ?
        
        [^] # Re: MySQL
        
        Posté par Thomas Douillard le 06 avril 2011 à 19:50. Évalué à 6.
        
        L'avantage d'une base de donnée c'est que c'est quand même fait pour ça ... sinon autant redévelopper un système de gestion de donnée, un cache, des indexs pour optimiser l'accès, et caetera ...
        
        [^] # Re: MySQL
        
        Posté par Juke (site web personnel) le 08 avril 2011 à 12:33. Évalué à 2.
        
        C'est vrai qu'on a vite fait de réinventer la roue...
    - [^] # Re: MySQL
      
      Posté par claudex le 05 avril 2011 à 11:19. Évalué à 3.
      
      (peut etre pas les commentaires)
      
      Ni les droits d'accès ou toutes les autres données qui ne sont pas liées directement aux photos.
      
      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
  - [^] # Re: MySQL
    
    Posté par 🚲 Tanguy Ortolo (site web personnel) le 05 avril 2011 à 11:08. Évalué à 1.
    
    Jamais dit le contraire, seulement qu'une base de données me semble inadaptée. Mais je peux détailler : ça ajoute une dépendance à un logiciel supplémentaire qui peut échouer, sans rien apporter en terme de passage à l'échelle.
    
    Personnellement j'irais plutôt stocker ça dans des fichiers dédiés, par photo ou par répertoire. Ou à la rigueur dans une base SQLite à côté des photos.
    - [^] # Re: MySQL
      
      Posté par Kévin Belliz le 05 avril 2011 à 11:12. Évalué à 3.
      
      Avec Piwigo, on peut également créer des dossiers virtuel, du coup je pense que ça complique beaucoup le système et qu'on ne peut pas se baser sur le système de fichier.
    - [^] # Re: MySQL
      
      Posté par claudex le 05 avril 2011 à 11:19. Évalué à 3.
      
      Il me semble que MySQL est plus souvent proposé par les hébergeurs que SQLite.
      
      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
      - [^] # Re: MySQL
        
        Posté par Larry Cow le 05 avril 2011 à 12:22. Évalué à 2.
        
        D'un autre côté, SQLite est directement intégré à PHP et ne nécessite pas de serveur. La dernière fois que j'ai regardé l'hébergement Free - ma définition personnelle du "au pire" - il gérait SQLite.
        
        [^] # Re: MySQL
        
        Posté par Laurent Pointecouteau (site web personnel, Mastodon) le 05 avril 2011 à 12:43. Évalué à 1.
        
        Y'a bien Picoplog qui, me semble-il, ne fonctionne qu'avec des informations du système de fichiers. Mais il requiert mod_rewrite qui n'est pas présent chez Free.
        
        [^] # Re: MySQL
        
        Posté par Pierrick Le Gall (site web personnel) le 05 avril 2011 à 12:58. Évalué à 1.
        
        Autant la dépendance à MySQL est facile à satisfaire car c'est présent partout dès qu'on propose également PHP, autant la disponibilité de mod_rewrite c'est beaucoup plus limitatif.
        
        Piwigo permet d'avoir des URL lisibles sans pour autant nécessiter mod_rewrite.
        
        [^] # Re: MySQL
        
        Posté par claudex le 05 avril 2011 à 13:41. Évalué à 3.
        
        Malgré cela, ce n'est pas présent partout. Et SQLite a des problèmes de performance dès qu'un site est un peu beaucoup utilisé. Ce que je trouve bien, c'est d'avoir le choix à l'installation en fonction du public visé.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: MySQL
        
        Posté par sifu le 05 avril 2011 à 14:21. Évalué à 1.
        
        La dernière fois que j'ai utilisé SQLite sur free.fr (il y a un peu plus d'un an), cela ne fonctionnait pas toujours très bien.
        
        J'avais trainé un peu sur les forums de l'ADUF et on m'avait expliqué que son utilisation n'était pas forcément conseillé. De mémoire, il y avait une histoire de NFS pour le stockage des fichiers qui posait problème avec SQLite.
- [^] # Re: MySQL
  
  Posté par Pierrick Le Gall (site web personnel) le 05 avril 2011 à 12:55. Évalué à 9.
  
  MySQL [...] pouvoir s'en passer ? C'est quelque chose que je comprends de moins en moins, qu'un outil de gestion de site intimement lié au système de fichiers ait besoin d'une base de données plutôt que de se reposer sur des informations en système de fichiers.
  
  C'est une question qui revient quasiment à chaque fois qu'on annonce une sortie majeure de Piwigo sur Linuxfr.org.
  
  L'utilisation d'une base de données permet une énorme souplesse et permet des fonctionnalités avancées qui serait beaucoup plus compliquées à implémenter avec juste des fichiers pour stocker les infos (pas impossible mais très compliqué). Après s'il faut générer un cache pour pouvoir faire de la navigation par tag, pour avoir une organisation "logique" d'albums qui ne soit pas identique à l'organisation "physique" des répertoires, pour lancer des recherches... alors ça va finir dans une base de données, donc autant le faire dès le départ.
  
  Il existe des outils de création de galerie photo sans base de données. Elles auront probablement moins de fonctionnalités disponibles que Piwigo ou ses concurrents directs (MenaltoGallery3, Zenphoto qui utilisent aussi une base de données), mais elles peuvent parfaitement convenir selon les besoins de chacun.
  
  Note: on a fait le choix de MySQL par défaut, c'est plutôt un bon choix si on réfléchit de manière pragmatique en regardant la disponibilité de cette "dépendance" sur les hébergeurs.
  - [^] # Re: MySQL
    
    Posté par claudex le 05 avril 2011 à 13:46. Évalué à 3.
    
    Note: on a fait le choix de MySQL par défaut, c'est plutôt un bon choix si on réfléchit de manière pragmatique en regardant la disponibilité de cette "dépendance" sur les hébergeurs.
    
    Ne serait-il pas possible de proposer le choix entre différents SGBDR comme MySQL, PostrgreSQL et SQLite? Il me semble que pour les utilisations courantes, les commandes SQL ne sont pas très différentes.
    
    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
    - [^] # Re: MySQL
      
      Posté par Pierrick Le Gall (site web personnel) le 05 avril 2011 à 14:33. Évalué à 4.
      
      proposer le choix entre différents SGBDR comme MySQL, PostrgreSQL et SQLite?
      
      Hum... c'est déjà le cas. Même si PostgreSQL et SQLite sont proposés à titre "expérimental", car pas aussi bien supporté que MySQL (notamment par les plugins, mais aussi par le core parfois, il y a des bugs à corriger).
      - [^] # Re: MySQL
        
        Posté par claudex le 05 avril 2011 à 16:28. Évalué à 3.
        
        Ah désolé, je n'avais pas vu sur le site (mais je n'avais pas bien cherché non plus).
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
- [^] # Re: MySQL
  
  Posté par ʭ ☯ le 05 avril 2011 à 18:33. Évalué à 3.
  
  Tu peux essayer VeSPA, si tu veux la même gestion bourrine que moi ;-)
  http://jjorge.free.fr/vespa/
  
  Pour tester:
  
  http://fotosjorge.free.fr
  
  Je le dis de suite, c'est pour les feignants, qui veulent juste dupliquer leur photothèque dans un site. Ça affiche les tags et commentaires EXIF, point.
  
  Ça permet les diaporamas récursifs sur toutes les photos, mais là le disque doit souffrir chez Free ;-)
  
  Et ça tient en 3/4 fichiers.
  
  ⚓ À g'Auch TOUTE! http://afdgauch.online.fr
# Rapide

Posté par bob le homard le 05 avril 2011 à 10:36. Évalué à 1.

salut,

+1 pour les sprites CSS. Sinon je ne sais pas si c'est mon FF4 mais je trouve que le service est très rapide... ce qui n'est pas souvent le cas chez les scripts de galerie photos. Bravo! Petite question quel est l’intérêt de fusionner les css et les js? Est-ce que le gain est significatif?
- [^] # Re: Rapide
  
  Posté par Kévin Belliz le 05 avril 2011 à 10:51. Évalué à 1.
  
  On évite pas mal d'entête de demande de fichier. Au lieu d'en demander 10 on en demande qu'un seul.
- [^] # Re: Rapide
  
  Posté par Pierrick Le Gall (site web personnel) le 05 avril 2011 à 13:01. Évalué à 3.
  
  L'intéret de fusionner les CSS et les JS (1 pour les CSS, 1 autre pour les JS) est exactement le même que les icônes avec les sprites CSS : limiter le nombre de requêtes HTTP entre le navigateur web et le serveur web.
  
  Une galerie Piwigo qui utilise des plugins qui suivent les préconisations ne téléchargera qu'un unique fichier CSS, quel que soit le nombre de plugins, et ça c'est bien pour ton serveur web, mais aussi pour celui qui navigue sur ton site.
# Merci et mise à jour

Posté par duf le 05 avril 2011 à 11:45. Évalué à 1.

Bonjour,

Déjà félicitations pour cette galerie photos que j'apprécie beaucoup et que j'utilise depuis peu. Je trouve qu'elle a de bonnes performance, en tout cas j'en suis très satisfait.

Sinon si pour ceux qui comme moi aurait un petit souci lors de la mise à jour (avec quelques erreurs de base de données après l'opération de MAJ dans le style => _PHP Warning: [mysql error 1054] Unknown column 'user_representative_picture_id' in 'field list'\n\nSELECT\n c.*,\n _ ) alors un petit passage par la case http://yourwebsite/photos/upgrade.php ou http://yourwebsite/upgrade.php vous permettra sans doute de régler le problème (sans oublier d'utiliser la maintenance disponible dans Options).

Encore merci pour le bouleau, elle est vraiment très très bien cette galerie !

@+
- [^] # Re: Merci et mise à jour
  
  Posté par SigNix le 05 avril 2011 à 13:35. Évalué à 1.
  
  Merci pour le conseil qui vient de m'éviter d'aller chercher l'information sur le site de piwigo.
  Bravo à l'équipe de dév. La mise à jour automatique est un vrai bonheur. Les outils d'envoi de photos (plugin pour digikam ou outils de piwigo) sont aussi bien pratique.
  - [^] # Re: Merci et mise à jour
    
    Posté par duf le 05 avril 2011 à 20:01. Évalué à 1.
    Pour ma part je me suis fait un petit script (qui mériterait d'être amélioré pour interagir avec l'utilisateur suivant les besoins de réaliser ou pas telle ou telle opération) qui me permet de faire du redimensionnement en touchant à la taille, la compression et la qualité des images (on trouve pas mal d'exemple d'utilisation de djpeg, pnmscale et Cie en cherchant sur google).
    
    On en trouve pleins sur le forum de piwigo bien plus évolué mais à titre d'information voilà le bout de code du mien :
```
#si besoin de renommer uniformément par la date exif
#jhead -n%Y%m%d_%H%M%S *
#rotation automatique des photos
#jhead -autorot *.jpg
echo "debut creation repertoire pwg_high et deplacement images"
mkdir pwg_high
mv *.jpg pwg_high/
cd pwg_high
echo "debut creation images en 800*600"
for i in `ls *.jpg`; do djpeg $i | pnmscale -xysize 800 600| cjpeg -optimize -progressive -quality 95 > ../$i; echo $i processed; done
echo "debut creation miniatures"
cd ..
mkdir thumbnail
for i in `ls *.jpg`; do djpeg $i | pnmscale -xysize 128 110| cjpeg -optimize -progressive -quality 75 > thumbnail/TN-$i; echo $i processed; done
```
    @+
  - [^] # Re: Merci et mise à jour
    
    Posté par MarbolanGos (site web personnel) le 06 avril 2011 à 08:51. Évalué à 1.
    Merci pour le conseil qui vient de m'éviter d'aller chercher l'information sur le site de piwigo.
    1. Je me demandais si j'avais pas raté la mise a jour... Merci pour piwigo c'est vraiment excellent comme projet !
# question

Posté par Adrien le 05 avril 2011 à 11:57. Évalué à 1.

Je m'intéressais justement à piwigo pour mettre en ligne des photos d'Antarctique.

Est-ce qu'il y a possibilité d'afficher les photos « à la lightbox » ? (avec des effets de fondus, en surimpression de la page par ex.)
- [^] # Re: question
  
  Posté par Frédéric COIFFIER le 05 avril 2011 à 12:30. Évalué à 2.
  
  Il y a ce plugin qui existe :
  http://fr.piwigo.org/ext/extension_view.php?eid=280
  - [^] # Re: question
    
    Posté par Adrien le 05 avril 2011 à 12:42. Évalué à 1.
    
    merci beaucoup, je pense que c'est ce que je cherchais :-))
  - [^] # Re: question
    
    Posté par dj_ (site web personnel) le 10 mai 2011 à 19:51. Évalué à 1.
    
    Par contre il faudrait changer le partie plugins du site piwigo, se taper 36 pages pour trouver un plugins c'est....
    
    Faire comme pour dotclear par exemple : administration, affichage etc
- [^] # Re: question
  
  Posté par Laurent Pointecouteau (site web personnel, Mastodon) le 05 avril 2011 à 15:45. Évalué à 3.
  
  Moi aussi j'ai une question : peut-on faire de Piwigo une galerie de vidéos en HTML5 ? J'avais tenté de forker Picoplog (mentionné plus haut) pour ce faire, mais la dépendance à mod_rewrite le rendait incompatible avec la plupart des hébergeurs gratuits. Ce serait chouette d'avoir un CMS spécialisé dans la vidéo (surtout depuis que le WebM est lu par les navigateurs libres) et facile à déployer, vous ne trouvez pas ?
  - [^] # Re: question
    
    Posté par duf le 05 avril 2011 à 20:05. Évalué à 2.
    
    Je suis d'accord et au moins un plugin permet de publier ces vidéos au sein de Piwigo (mais en conservant le format d'origine si je ne dis pas de bêtises).
    
    La possibilité de publier ses vidéos dans un codec/conteneur libre de son choix partie intégrante d'html5 serait un réel plus, par contre cela nécessite de passer par la case "transcode" par forcément légère. Ma petite part Gandi serait pour le coup fortement utilisée je pense :-)
    
    Par contre ce serait super intéressant, il faut peut être attendre qu'html5 (et la balise vidéo) se démocratise.
    - [^] # Re: question
      
      Posté par Laurent Pointecouteau (site web personnel, Mastodon) le 06 avril 2011 à 20:08. Évalué à 1.
      
      Pour ce qui est de compresser les vidéos, sous Linux on a ce qu'il faut : Arista, Transmageddon, ffmpeg, les logiciels de montage (Pitivi et Openshot), ffmpeg en ligne de commande, etc. Sous Windows, il y a Miro Converter ou XMedia Recode. Tout ça c'est ce que j'ai testé pour le WebM : pour le Theora ou le H.264, il doit y avoir encore plus de choix.
      
      Par contre, si la "démocratisation" consiste à attendre que le player HTML5 de Youtube fonctionne correctement, ça risque de prendre pas mal de mois encore. C'est dommage, il serait bien pratique d'ajouter à Piwigo des vidéos uploadées sur un site spécialisé ; or, à ma connaissance, seul blip.tv permet de faire ça (en utilisant le lien direct vers la vidéo, plutôt que leur player qui bouffe tout le CPU). C'est de cette manière que j'ai pu faire des sites de vidéos HTML5 avec seulement un peu de PHP sur un hébergement Free.
# Fusion CSS et JavaScript

Posté par 🚲 Tanguy Ortolo (site web personnel) le 05 avril 2011 à 14:03. Évalué à 3.

fusion automatique des fichiers CSS et des fichiers JavaScript

Comment ça marche au juste ? Vous codez vos styles en JavaScript ? C'est une pratique que j'ai vue une fois dans un bouquin, mais jamais utilisée en pratique…
- [^] # Re: Fusion CSS et JavaScript
  
  Posté par Pierrick Le Gall (site web personnel) le 05 avril 2011 à 14:35. Évalué à 2.
  
  Non non, j'aurais dû faire une phrase plus longue pour éviter les quiproquos : les fichiers CSS sont fusionnés en un seul fichier CSS, les fichiers Javascript sont fusionnés dans un seul fichier Javascript (quand c'est possible)
  - [^] # Re: Fusion CSS et JavaScript
    
    Posté par 🚲 Tanguy Ortolo (site web personnel) le 05 avril 2011 à 17:18. Évalué à 1.
    
    Ok. :-)
    
    Comme je le disais, il est possible de coder ses styles en JavaScript, mais je ne l'ai jamais vu faire en vrai.
    - [^] # Re: Fusion CSS et JavaScript
      
      Posté par Christophe Turbout le 05 avril 2011 à 17:46. Évalué à 2.
      
      et tu gagnes réellement quelque chose ou bien c'est de la méthode coué ?
      
      globalement tu dois gagner au premier chargement mais après le cache de ton navigateur
      masque les appels car tes fichiers ne doivent pas être modifiés ...
      
      du coup as-tu réellement mesuré pour vérifier ?
      
      par ailleurs s'il y a beaucoup de javascript ou de css ça devient vite le bazar notamment
      quand tu intègre des style de différents outils et plugin, le fait de les séparer je trouve
      ça plutôt sympa et propre quand tu dois changer un style.
      - [^] # Re: Fusion CSS et JavaScript
        
        Posté par claudex le 05 avril 2011 à 18:36. Évalué à 4.
        
        Le premier chargement, c'est quand même celui qui concerne le plus de visiteur. De plus, même avec le cache, il faut faire une requête pour avoir le 302, et il en vaut mieux une que 10.
        
        Par contre, il n'est pas interdit de développer des fichiers séparer et de ne les rassembler que pour la distribution des version stables. C'est ce qui est fait sur ce site par exemple.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Fusion CSS et JavaScript
        
        Posté par Christophe Turbout le 06 avril 2011 à 13:44. Évalué à 1.
        
        304 en l’occurrence car 302 c'est autre chose ...
        
        je conçois qu'en terme d'io avec une forte charge ça puisse avoir un impact côté serveur ...
        
        maintenant pour les clients, les navigateurs modernes lancent les requêtes en parallèles
        du coup que tu en ais un ou 5 ça ne change pas grand chose sur le temps de chargement de ta page ...
        
        s'il y en a 50 forcément c'est autre chose !
        
        puisque nous parlons du site linuxfr tient pourquoi a-t-on une configuration qui
        empêche l'utilisation du cache (proxy) pour toutes les pages de linuxfr ?
        
        dans la réponse du header on a : "Cache-Control:max-age=0, private, must-revalidate"
        
        du coup la page html est systématiquement téléchargée même si elle n'a pas changé.
      - [^] # Re: Fusion CSS et JavaScript
        
        Posté par LupusMic (site web personnel, Mastodon) le 06 avril 2011 à 19:45. Évalué à 1.
        
        Tu peux gagner énormément en performance, rien qu'en n'analysant qu'un seul fichier.
        
        Ensuite, c'est vrai que ça peut devenir le bazar si tu le fais à l'arrache. C'est pourquoi il y a des outils qui permettent de « compiler » les données, et simplifier la maintenance.
        
        Mais ça reste une optimisation : il faut mesurer, et estimer si ça vaut le coup.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.