Websourcing.fr

Websourcing.fr » ActualitĂ©s, Web, Logiciels et Fun

Image pour [Webdesign] Compression efficace des pages web de Wordpress en PHP

[Webdesign] Compression efficace des pages web de Wordpress en PHP

En ce moment je suis Ă  la recherche de solutions « quick-win » pour amĂ©liorer mon blog, tant au niveau rĂ©fĂ©rencement que performance.

Sur ce dernier point j’ai dĂ©jĂ  rĂ©ussi Ă  optimiser mes CSS de manière agile, sans plugin ni processus complexe.

Je me suis attelĂ© Ă  l’optimisation globale du temps de chargement des pages. Après avoir lu pas mal de conseils et tutoriels, et avoir pas mal bidouillĂ©, j’ai enfin trouvĂ© une technique toute simple qui me permet de rĂ©duire grandement la bande passante nĂ©cessaire.

Jusqu’ici, sur mon serveur, la compression Gzip PHP n’Ă©tait pas activĂ©e. J’ai donc mis en place Zlib sur celui-ci. La plupart des hĂ©bergeurs, y compris les low-cost, ont cette librairie configurĂ©e sur leurs serveurs.

Pour vĂ©rifier si Zlib est activĂ©e, il vous suffit de coller l’instruction PHP phpinfo() dans n’importe quelle page. Recherchez « Zlib » et vous trouverez une section Ă©quivalente Ă  celle-ci:

websourcing_fr_zlib_php

La suite est toute simple. Ouvrez le fichier header.php et collez les trois lignes suivantes au tout début du fichier:

ini_set('zlib.output_compression', 'On');
ini_set('zlib.output_compression_level', '1');
ob_start('ob_gzhandler');

C’est tout. Vos pages seront compressĂ©es.

Je n’Ă©tais moi-mĂŞme pas convaincu lorsque j’ai lu la technique. j’ai donc fais quelques tests pour voir.
J’ai donc activĂ© Firebug sur un chargement « complet » (= CTRL+ F5) de ma page d’accueil avant modification:

websourcing_fr_firebug_compression_desactivee

Après mise en place du mécanisme de compression, les résultats sont bien meilleurs, surtout sur le code HTML qui gagne près de 75% sur sa taille originale:

websourcing_fr_firebug_compression_activee

La technique est ultra efficace si l’on considère que les Ă©lĂ©ments tels les images ne seront pas re-tĂ©lĂ©chargĂ©s Ă  chaque fois grâce au cache du navigateur:

websourcing_fr_cache

Il ne reste donc que 11Ko tĂ©lĂ©chargĂ©s, c’est Ă  dire la structure HTML envoyĂ©e. Justement ce qui est compressĂ© Ă  75% !

L’investissement (3 minutes) en vaut donc la peine. Qu’en pensez vous? D’autres techniques/ »Quick-Win »?

Crédits: macdougalmedia.com


Cet article vous a plu ?

Commenter Laissez un commentaire | Recevez les mises à jour Souscrivez au flux RSS | Partager : Twitter AddInto Fuzz del.icio.us Wikio FR Blogonet
Websourcing.fr - Tous droits réservés. Reproduction interdite sans accord préalable.
  1. Répondre Citer #1 par Effy le 4 juillet 2009 - 01:13

    Donc si j’ai bien suivit la tu gagne 75% de 11ko soit 8,25 en moins a dl… certe je dis pas que c’est pas bien, mais le miliĂ©me de seconde de diffĂ©rence au niveau du dl j’ai un doute qu’il fasse une diffĂ©rence rĂ©elle. J’entend dire que la partie incomprĂ©ssible dĂ©but/fin du dl ne changeant pas tu va pas gagner tant que ca sur les dls qui sont de toute facon minuscules avec du haut dĂ©bit.

    Et quid du temps que met le serveur Ă  dĂ©compresser tes pages avant de les envoyer? ceci n’apparaissant pas dans notre merveilleux firebug…

    La compression de maniĂ©re gĂ©nĂ©ral est merveilleuse sur les gros fichiers et une calamitĂ©e sur les petits fichiers trĂ©s nombreux, mais je peux me tromper ‘:)… Enfin Ă  mon avis il existe des moyens bien plus efficasse (genre vĂ©rifier qu’un script js ne bloque pas la page, que les parties non utiles de la page sont bien chargĂ©es en derniers etc…)

    • Répondre Citer #2 par Lionel Roux le 4 juillet 2009 - 13:23

      Alors en fait, tu as mal suivi car 11Ko sont les 25% restants. Si tu regardes bien toutes les images on part de 44Ko pour arriver Ă  11Ko, soit 33ko de gagnĂ©, qui sur une base de 230 Ko reprĂ©sentent 15% du poids total d’un refresh total et donc 75 d’un refresh normal (avec cache). Pas nĂ©gligeable Ă  mon avis.

      Quant au temps serveur, c’est franchement nĂ©gligeable, surtout avec les caches serveurs. D’ailleurs ce n’est pas le serveur qui dĂ©compresse mais le navigateur du client qui demande la page. Tu voulais peut-ĂŞtre dire « compresser » et non pas  » dĂ©compresser ».

      Et effectivement mes scripts sont chargés en dernier, pour ne pas bloquer la page.

      En conclusion, je préfère envoyer 11ko plutôt que 44ko.

  2. Répondre Citer #3 par ZeK le 4 juillet 2009 - 10:55

    Tu te trompes pas mal. Activer la compression n’aura d’effet ici que sur les pages de ton site (le fichier html seulement, c’est tout). Ca n’a ABSOLUMENT AUCUN EFFET sur les autres fichiers, et pourtant c’est sur ceux-lĂ  qu’est le gaspillage.

    Quand tu Ă©crit « La technique est ultra efficace si l’on considère que les Ă©lĂ©ments tels les images ne seront pas re-tĂ©lĂ©chargĂ©s Ă  chaque fois grâce au cache du navigateur: », je ne comprend pas. Activer zLib ne touche pas aux images, et encore moins aux headers concernant le cache.

    Il ne faut pas oublier que compresser à la volée ça consomme aussi beaucoup plus de ressources serveur (CPU, RAM).
    La bonne solution consiste à Gzipper certains éléments comme les fichiers CSS et Javascript:
    http://blog.joshuaeichorn.com/archives/2007/01/10/compressing-javascript-and-css/

    Quant Ă  compresser les pages en elle-mĂŞme, il est gĂ©nĂ©ralement coĂ»teux de les compresser contre un gain minime en termes de traffic. Et les les images sont dĂ©jĂ  bien compressĂ©es (gif, jpeg, png), c’est donc inutile de les recompresser. C’est un peu comme zipper un divx, ça n’a aucun sens.

    • Répondre Citer #4 par Lionel Roux le 4 juillet 2009 - 13:26

      « Tu te trompes pas mal. Activer la compression n’aura d’effet ici que sur les pages de ton site (le fichier html seulement, c’est tout). Ça n’a ABSOLUMENT AUCUN EFFET sur les autres fichiers, et pourtant c’est sur ceux-lĂ  qu’est le gaspillage. »

      J’ai Ă©cris le contraire? Non il ne me semble pas. je ne parle pas des autres fichiers en ce qui concerne la compression. D’ailleurs le fichier que j’ai mis en Ă©vidence est le fichier HTML (entourĂ© de rouge sur les images).

      La bonne solution que tu cites est également en place sur mon serveur: Je compresse les scripts et CSS.Suffit de lire le billet en entier.

      • Répondre Citer #5 par ZeK le 4 juillet 2009 - 14:19

        Oui tu as écrit le contraire :
        « surtout sur le code HTML qui gagne près de 75% sur sa taille originale: »

        Si tu met « surtout », c’est que c’est pas le seul fichier qui gagne en taille. Et pourtant…

        • Citer #6 par Lionel Roux le 4 juillet 2009 - 17:06

          Ok j’ai insĂ©rĂ© un malheureux mot ne trop, mais je ne parle pas des CSS et JS, et j’exclu les images.

          Bref de toute façon ce billet n’est pas Ă  destination des pros, mais plutĂ´t Ă  destination des newbies comme moi.
          J’ai bookmarkĂ© l’article que tu cites et j’irais le lire.

          @+

    • Répondre Citer #7 par Effy le 4 juillet 2009 - 15:05

      Oki disons :)
      Je voulais pas dire que c’Ă©tait pas une bonne mĂ©thode ni que l’article n’Ă©tait pas interressant au contraire, c’est juste la systĂ©matisation sur toutes les elements du site que je me demande vraiment si elle est justifiĂ©e. Mais dans l’ensemble il est cler qu’il y a un gain :)

      Oui je suis un chipoteur ^^’ …

      • Répondre Citer #8 par Lionel Roux le 4 juillet 2009 - 17:03

        Non mais le truc c’est que c’est pas mon mĂ©tier. Je cherche des astuces et toute l’aide et la bienvenue, au contraire, je ne demande que ça. En fait, sauf erreur de ma part (ce qui est tout Ă  fait possible), la compression ne concerne que les pages HTML et comme elles ont Ă  peu prĂŞt toute la mĂŞme structure, je suppose que toute « gagnent » en taille.

        Tu crois que c’est pas bon de compresser toutes les pages ? Seules certaines pages devraient l’ĂŞtre ? Comment les choisir?

        @+

  3. Répondre Citer #9 par ZeK le 4 juillet 2009 - 17:24

    C’est un choix au final.
    Google, par exemple, a activĂ© la compression gzip sur son moteur de recherche. Mais il y a très peu d’images et de javascripts Ă  charger sur Google, donc le gain de traffic est très important. Voici la seule image que l’on charge quand on fait une recherche sur google :
    http://www.google.fr/images/nav_logo6.png

    Mais sur ton blog, tu utilises beaucoup d’images et de javascript et compagnie. Le traffic dĂ» aux fichiers HTML est donc minime comparĂ© aux images. Le gain de traffic est tout petit comparĂ© Ă  la surconsommation de ressources sur le serveur. Voici une mauvaise expĂ©rience :
    http://www.llaumgui.com/post/Montee-en-charge-et-compression-Gzip-des-pages-servies

    Si tu veux vraiment accélérer le chargement des pages, essaie plutôt les conseils de Yslow qui donne une note D sur cette page.
    http://developer.yahoo.com/yslow/

    • Répondre Citer #10 par Lionel Roux le 5 juillet 2009 - 01:02

      A vrai dire j’ai dĂ©jĂ  passĂ© les tests YSlow; PageSpeed et d’autre. En mode « blog », je n’obtient pas D mais A. Effectivement en mode site classique j’obtient D. Mais je ne suis pas dupe, il me reste bcp de boulot.

      J’ai d’ailleurs essayĂ© de construire un système me permettant de crĂ©er un sprite de mes images dynamiquement (avec un cache remis Ă  jour Ă  chaque nouvelle publication). Mais c’est compliquĂ©. (trop pour moi).

      Je suis en train de faire en sorte de concatĂ©ner mes 3 JS et certaines CSS (avec cache aussi, rĂ©gĂ©nĂ©rĂ© Ă  chaque modification de l’un des fichiers et changement de nom pour qu’il soit re-tĂ©lĂ©chargĂ©).

      Penses-tu que crĂ©er un sous domaines spĂ©cifique pour les images (style images.websourcing.fr) permettrait de mieux parallĂ©liser les DL d’images? (avec un lookup DNS sup malgrĂ© tout).

  4. Répondre Citer #11 par ZeK le 5 juillet 2009 - 01:06

    Aucune idée pour le sous domaine, fait des test mais je ne suis pas bien convaincu que ça accélère le tout.

    Ne te prends pas trop la tête non plus, ça charge déjà bien vite.

  5. Répondre Citer #12 par Des Geeks et des lettres le 10 dĂ©cembre 2009 - 20:09

    Article intéressant ! Le mien, sur les css sprites, pourra être utile aussi (http://bit.ly/6c5cZT). Bonne continuation !

(Ne sera pas publié)
  1. Sur Jean-Marie Gall.com le 5 juillet 2009 - 00:57

    [...] [Webdesign] Compression efficace des pages web de Wordpress en PHP by Lionel de Websourcing.fr [...]

  2. Sur Vent des blogs #43 | Fredzone le 7 juillet 2009 - 13:21

    [...] Web Sourcing : Optimiser son blog, c’est un peu une Ă©tape obligatoire pour tous ceux qui veulent devenir riches, cĂ©lèbres et respectĂ©s. Avec Lionel, vous allez apprendre Ă  compresser vos pages Wordpress très facilement. [...]