Eclaircissement Gzip

Réduire
X
 
  • Filtrer
  • Heure
  • Afficher
Tout effacer
nouveaux messages

  • Eclaircissement Gzip

    Bonjour, j'ai pas mal de connaissance à acquérir coté optimisation, et pour cause : les informations que je trouve sur Internet me paraissent parfois redondantes avec les fonctions intégrées à Joomla, voire inutile ou enfin complémentaires. J'ai donc besoin d'éclaircissements que je peux peut-être trouver ici ?

    Compréhension Gzip
    • Nous avons une fonction "Compression Gzip" (Configuration -> Onglet "Serveur" ) que l'on peut activer ou non.
    • Certains hébergeurs (i.e. : Siteground) conseille d'ajouter ces lignes de code au fichier .htaccess :
    Code HTML:
    <IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/plain
    AddOutputFilterByType DEFLATE text/html
    AddOutputFilterByType DEFLATE text/xml
    AddOutputFilterByType DEFLATE text/css
    AddOutputFilterByType DEFLATE application/xml
    AddOutputFilterByType DEFLATE application/xhtml+xml
    AddOutputFilterByType DEFLATE application/rss+xml
    AddOutputFilterByType DEFLATE application/javascript
    AddOutputFilterByType DEFLATE application/x-javascript
    </IfModule>
    • Et enfin, on peut activer la compression Gzip sur le Cpanel -> Optimisation du site
    Plusieurs questions me viennent à l'esprit :
    • Je suppose que ces options sont redondantes et qu'il faut donc en choisir une seule ? Mais est-ce vrai ?
    • Si il ne faut en choisir qu'une seule, laquelle semblerait la plus efficace en terme de compression bien sur, mais surtout en terme d'utilisation ressources et compatibilité (sachant que je ne travaille QUE sur des sites Joomla).
    • Et enfin, Gzip n'est pas possible à chaque fois. Par exemple, je ne peux pas utiliser RSForms correctement si Gzip est activé (pas de page de remerciement i.e.). Je le désactive simplement et ... tant pis ?
    • J'ai également lu à ce sujet que la fonction de compression Gzip était devenue quasi obsolète à ce jour vu les débit aujourd'hui accessibles. Est-ce une information pertinente ?
    Je sais que ça fait quelques questions, mais le but du jeu étant d'essayer d'avoir plusieurs avis sur le thème de la compression Gzip, e vous remercie d'avance pour toute information ou avis sur le sujet.

    mrc (<- remerciements d'avances compressés gzip :¬)
    Stéphane Herby
    http://www.paoproduction.com
    Nouvelle-Calédonie & Canada
    (Je sais NC & Canada ça fait bizarre, mais... c'est comme ça :¬p)

  • #2
    Envoyé par BigStef Voir le message
    mrc (<- remerciements d'avances compressés gzip :¬)
    mrc; bad CRC, impossible à décompresser; fatal error

    ;-)


    Envoyé par BigStef Voir le message
    Je suppose que ces options sont redondantes et qu'il faut donc en choisir une seule ? Mais est-ce vrai ?
    Exact.

    Quand tu as un fichier ZIP et que tu le compresses encore, tu verras que la taille du fichier sera plus grande puisque, normal, le seconde compression vient ajouter des caractères superflus pour décompresser le fichier déjà compressé. Compression ZIP sur compression sur compression et hop, tu as pléthore donc oui : un seul (et le bon) gzip est suffisant.

    En principe, plus tu es haut dans la chaîne mieux c'est.

    Par opposition, si tu compresses en PHP (ce que fait Joomla) est le moins bon et à activer uniquement si .htaccess ne peut être fait et seulement si la compression hébergeur ne peut être faite.

    En outre, une compression PHP est plus coûteuse en CPU, donc, une fois encore l'hébergeur (et ses modules Apache de compression) sont la meilleure option à privilégier.

    Envoyé par BigStef Voir le message
    Et enfin, Gzip n'est pas possible à chaque fois. Par exemple, je ne peux pas utiliser RSForms correctement si Gzip est activé (pas de page de remerciement i.e.). Je le désactive simplement et ... tant pis ?
    Ca c'est vraiment très étrange (et semble vraiment anormal) : en quoi une application quelconque puisse être impacté par ce qui se passe derrière elle ? La compression gzip se fait sur le résultat HTML, généré, de la page. Un code PHP s'exécutant pour produire ce HTML n'est en rien, je pense, concerné. Il ne sait pas que le navigateur reçoit un flux compressé; il ne sait pas et ne doit pas le savoir.

    Ce que tu mentionnes me paraît vraiment étrange.

    Envoyé par BigStef Voir le message
    J'ai également lu à ce sujet que la fonction de compression Gzip était devenue quasi obsolète à ce jour vu les débit aujourd'hui accessibles. Est-ce une information pertinente ?
    As-tu déjà comparé une page compressé / non compressé ? Parfois c'est un facteur de 90%, c'est énorme.

    Dans l'absolu, transférer 10 ko ou 90ko, oui, c'est juste quelques millisecondes en plus. Pour nous, bénéficiant d'une belle connexion au web, on ne le verrait même pas.

    Au milieu du désert, dans certains pays dont l'accès au web est plus compliqué, ..., là je pense que la différence est notable.

    Et puis, si je peux configurer mon application pour ne consommer que 10 ko et non pas 90 ko, pourquoi ne le ferais-je pas ? Je laisse de la bande passante, je consomme moins de data, etc.

    Mais oui, réalité et théorie peuvent probablement faire dire que la compression, d'une petite page, ne se verra même pas à nos yeux.

    En conclusion : oui, oui, oui, si tu peux compresser, fais-le ... une fois et au bon endroit ;-)
    BigStef et jfque aiment ceci.
    Christophe (cavo789)
    Mon blog, on y parle Docker, PHP, WSL, Markdown et plein d'autres choses : https://www.avonture.be
    Logiciel gratuit de scan antivirus : https://github.com/cavo789/aesecure_quickscan (plus de 45.000 virus détectés, 700.000 fichiers sur liste blanche)​

    Commentaire


    • #3
      Comme (très bien) expliqué par cavo789, la compression n'est pas obsolète.
      Ce qui l'est, c'est gzip. Il y a maintenant des fonctions plus performantes au niveau de la compression, mais elles sont encore rarement disponibles sur les serveurs proposés par les hébergeurs, donc, en attentant, il faut se contenter de gzip.
      BigStef aime ceci.
      Tous les services pour les sites Joomla! : sécurité, nettoyage de sites piratés, hébergement, SEO, applications Fabrik, migration, compatibilité mobiles, accessibilité, ...
      Administrateur certifié Joomla! 3
      https://www.betterweb.fr

      Commentaire


      • #4
        Merci beaucoup à vous deux pour vos réponses...
        Les précisions de cavo789 sont justes parfaites.
        Pour ma mention de RSForms, j'avais essayé de remettre la main sur le topic où je suis tombé il y a 2 mois quand j'ai rencontré des problème avec ce composants, mais hélas je n'ai pas retrouvé ça hier... Flûtre ! Je ferais un correctif plus tard sur ce topic si je remet la main dessus.

        Une petite précision, si la compression à un plus haut niveau est préférable, mieux vaut que je passe par le paramètre en Cpanel via le module mod_deflate d'apache je suppose.
        C'est encore plus haut que par le .htaccess, n'est-ce pas ?
        Sur ce point, il me demande la compression de TOUT ou de sélectionner certains types MIME. Est-ce raisonnable de sélectionner TOUT ? Ou cela est variable finalement pour chaque site, même si ils sont tous sous Joomla ?

        jfque, voilà une piste intéressante. Est-ce que tu penses au Zstandard par exemple (https://groups.google.com/forum/#!to...wl/bO6B6xQJnEE) ? En tous cas sur Siteground je n'ai que Gzip de proposé (pour l'instant du moins)...
        Stéphane Herby
        http://www.paoproduction.com
        Nouvelle-Calédonie & Canada
        (Je sais NC & Canada ça fait bizarre, mais... c'est comme ça :¬p)

        Commentaire


        • #5
          Bonsoir (ou bonjour)

          Envoyé par BigStef Voir le message
          Une petite précision, si la compression à un plus haut niveau est préférable, mieux vaut que je passe par le paramètre en Cpanel via le module mod_deflate d'apache je suppose. C'est encore plus haut que par le .htaccess, n'est-ce pas ?
          Mon explication n'était pas assez claire sur ce point, je m'en doutais ;-)

          Quand je mentionnais "au plus haut" je songeais à qui est le premier contacté : c'est l'hébergeur (le serveur web) qui reçoit la demande et la dirige vers ton site Joomla. La page accédée étant la dernière à entrer en scène et le code PHP de cette page étant vraiment la couche la plus basse; celle qui fait le job et qui renvoit un contenu HTML dans le sens inverse à la demande. Le code PHP génère le code HTML qui est pris en charge par Apache qui le renvoie au navigateur web du client.

          Au niveau le plus bas : une compression PHP va coûter plus de CPU et sera moins efficace qu'une compression faite avec un logiciel binaire comme mod_gzip ou, mieux, mod_deflate.

          Si tu peux activer mod_deflate dans le .htaccess, c'est mieux que d'activer la compression gzip dans les paramètres de Joomla.
          Si tu actives le compression au niveau du .htaccess, c'est le serveur web qui va compresser le contenu et pas Joomla (càd du code PHP), le serveur web étant "plus haut" dans la cascade des acteurs.

          Note : si ton hébergeur supporte le module pagespeed de Google, ce module est meilleur que mod_deflate (qui est meilleur que mod_gzip).

          Maintenant, encore plus en amont, tu as la capacité de ton hébergeur à compresser (optimiser) les pages. Chacun ses techniques mais selon la qualité de l'hébergeur, celui-ci va proposer plusieurs fonctionnalités (memcache, supercacher tm, php7/hhvm, ...), c'est à celles-là que je songe lorsque je pense à "plus en amont" dans la chaîne.

          Note : il y a quelques années, j'ai rédigé une présentation pour le JoomlaDay 2014, tu peux la retrouver ici : https://www.aesecure.com/downloads/optimiser-apache.pdf
          Prends connaissance du slide 50 où je démontre que la compression template (donc en PHP) a un effet négatif sur l'optimisation.

          Envoyé par BigStef Voir le message
          Sur ce point, il me demande la compression de TOUT ou de sélectionner certains types MIME. Est-ce raisonnable de sélectionner TOUT ? Ou cela est variable finalement pour chaque site, même si ils sont tous sous Joomla ?
          Je dirais : teste. Pour les raisons évoquées ci-dessus.
          Personnellement, quand j'interviens pour optimiser un site web, je n'ai que rarement accès au cpanel et donc j'active la compression deflate sur quantité de contenus dont les fichiers dont le contenu est du texte (css, js, php, html, xml, ...).

          Dans le meilleur des mondes (et c'est une utopie), il faudrait tester comme je le montre dans ma présentation après chaque activation d'une optimisation : est-ce que cette optimisation, pour ce site, pour ce template, avec cet hébergeur, ... donne un avantage ? Oui / Non. Si Oui, on garde, si Non, on jete.

          Bonne soirée.
          BigStef aime ceci.
          Christophe (cavo789)
          Mon blog, on y parle Docker, PHP, WSL, Markdown et plein d'autres choses : https://www.avonture.be
          Logiciel gratuit de scan antivirus : https://github.com/cavo789/aesecure_quickscan (plus de 45.000 virus détectés, 700.000 fichiers sur liste blanche)​

          Commentaire

          Annonce

          Réduire
          Aucune annonce pour le moment.

          Partenaire de l'association

          Réduire

          Hébergeur Web PlanetHoster
          Travaille ...
          X