Développement propre VS optimisation du code

Mathieu Chartier Programmation 15 commentaires

La problématique du billet est posée d'entrée et se veut à la fois naïve et critique. En effet, si nous vous demandions de développer des pages web, nul doute que vous souhaiteriez coder à la fois proprement et en optimisant le code source au maximum. Néanmoins, la tendance actuelle semble de plus en plus négative envers le code et tend à se dégrader à l'avenir.

Tout ceux qui comme moi sont passés par des écoles sérieuses et disciplinées savent qu'il ne faut pas coder dans tous les sens et avec n'importe quoi. Le choix du langage, de la technologie ou des outils intégrés est donc primordial et requiert généralement un savoir-faire pour éviter de se retrouver rapidement avec un code illisible voire imbuvable. Pour les autodidactes, je nuance bien entendu puisque beaucoup d'entre eux programment comme de réels génies et sans fausse note apparente. Par conséquent, nous sommes tout d'accord sur le fait qu'avoir un code lisible, aéré et commenté est un point fort !

L'art du développement web se tient dans la conception et la structure des pages web, mêlant plusieurs langages avec l'HTML en maître. Tout part donc d'une bonne intégration web (CSS compris) puis s'ajoute à cela les besoins complémentaires selon vos envies (PHP, Javascript, XML, Ajax, ASP, etc.). Cet ensemble doit être harmonieux, logique et surtout compréhensible. C'est d'ailleurs en ce sens que la programmation orientée objet (POO pour les intimes) a connu son heure de gloire. En terme de performance, elle n'apporte pas nécessairement de meilleurs résultats (contrairement aux idées préconçues), mais sa lisibilité est facilitée par la création de classes et objets modifiables, etc. En résumé, nous codons théoriquement des pages avec un code indenté, commenté et optimisé pour l'avenir.

L'objectif des bons développeurs (je ne me considère pas comme tel) est de créer un code qui pourra être repris et surtout compris par un tiers. C'est sur ce principe que fonctionne l'open source et la plupart des CMS que nous aimons utiliser. D'ailleurs, lorsqu'un CMS comme Magento pointe le bout de son nez avec un code riche et technique à souhait, la communauté se fait moins forte (mais de qualité néanmoins). La simplicité et la compréhension restent les points essentiels d'un code d'avenir.

Un code optimisé à quelle fin ?

L'optimisation est entrée dans le coeur des développeurs depuis quelques mois. Non pas qu'elle n'intéressait personne avant, elle s'est réellement démocratisée depuis peu, avec en ligne de mire l'idée d'un chargement plus rapide et un code plus "Google friendly"... Le paradoxe de ces optimisations tient au fait que nous bénéficions dorénavant de connexions agréables et rapides, mais malgré cela, nous souhaitons optimiser à 100% nos pages web. Pourquoi ne le faisions-nous pas avant ? Préférions-nous nos images non compressées, nos codes lourds, nos bases de données mal agencées (...) ? J'en doute fortement, mais la problématique du PageSpeed de Google et du web-mobile a fortement accru la sensibilité envers l'optimisation du code source.

Nous voilà donc dans une nouvelle ère. Avec le web-mobile et l'optimisation de masse pour convaincre Google que nous sommes les plus beaux et les plus forts, nous nous retrouvons avec des codes frôlant le ridicule. Il suffit de voir les critères imposés par le PageSpeed notamment qui prêtent parfois à sourire. Je me rappelle d'un web pas si ancien dans lequel les développeurs n'aimaient pas spécialement les mises en cache. Maintenant, tous vont dans le même sens et donneraient monts et merveilles pour mettre en cache leurs pages. J'avoue être parfois étonné et amusé par les réactions dans le monde du web. J'attends avec impatience que Google nous demande de sauter dans un trou pour que nos pages soient dans le trio de tête, ça va faire du ménage sur Terre... (rire)

Plus sérieusement, les optimisations demandées ne sont pas nécessairement à l'avantage des développeurs et me tracassent un peu pour l'avenir. Prenons plusieurs exemples. Les fichiers CSS, HTML, Javascript doivent être compressés au maximum pour améliorer la vitesse de chargement, nous nous retrouvons donc avec des codes en prose (au revoir jolie indentation...) dont les commentaires ont été retirés pour gagner quelques octets. Les fichiers externalisés n'étant pas modifiables directement, nous nous retrouvons donc à préférer télécharger les codes et les optimiser (il n'y a pas si longtemps, on préférait externaliser). Le sprite CSS devient ridicule car les outils demandent de lier beaucoup d'images, même des fichiers sans rapport direct... Sur le principe, je comprends ces critères, mais à ce rythme, où allons-nous ? Reprendrons-nous innerhtml avec l'Ajax même s'il est déprécié (pour gagner quelques lignes de code) ? Allons-nous supprimer toutes les lignes de code "évitables" pour faire la chasse aux octets ? Arrêterons-nous d'utiliser des CMS pratiques parce que certains objectifs peuvent difficilement être atteints ?

Bien sûr, ce billet de blog se veut critique envers le "toujours plus" imposé par le chargement des pages (vivement la fibre optique nationalisée alors ?) et les développeurs qui appliquent tout et son contraire au gré du vent. Je n'en veux à personne, mais la crainte d'un web moins lisible, moins clair et pas forcément meilleur en terme de résultats me dérange et m'inquiète. Continuons de coder proprement en optimisant le maximum de points, mais évitons la chasse aux octets hypocrites parce qu'un des critères de l'algorithme de Google ou le web-mobile l'ont demandé (avec la 3G minimum, nous sommes bien loin du 56Ko d'antan quand même...).

15 commentaires

  • Tu as raison de dire qu'il s'agit seulement de quelques octets, car en vérité chaque code du web (quel que soit le langage) est écrit de manière "interprétée". La totalité du code est traitée directement et ce même code est en fait une simple chaine de caractères ... donc les commentaires sont balayés à l'execution (de l'ordre du millième de seconde à peine), et l'indentation ne ralentit en rien l'execution (puisque les caractères sont collés les uns aux autres au moment de l'interpétation du code) ...
    A la vérité cette fausse évolution (je me souviens de CSS abominables pour les yeux) n'est là que pour masquer le fait que les programmeurs sont de plus en plus brouillons ... et ne font aucun effort pour que d'autres puissent reprendre leurs codes.

  • RaphSEO dit :

    Bonjour, je suis seo et ce que vous décrivez fait partie entre autre de mes recommandations; Sauf que je pense aussi aux dev ou tout autre personne susceptible de passer derrière. C'est pourquoi je demande qu'une version normale (indentée, commentée...) soit conservée en copie afin de pouvoir travailler correctement dessus, et mettre ensuite la version allégée (compressée, décommentée...) en ligne.
    ça demande certes un petit peu de gymnastique mais ainsi tout le monde y gagne

    • En effet, l'idéal est d'avoir un doublon propre en sauvegarde bien évidemment, j'ai procédé ainsi sur certains sites avec mes Javascript et CSS notamment, mais j'avoue ne pas encore me préoccuper de l'HTML, du PHP, etc. Moi-même passionné de référencement depuis des années, je fais le maximum pour suivre les recommandations de Google, mais jusqu'à une certaine limite.

      Récemment, Google Penguin et les nombreux critères du PageSpeed m'ont un peu fâché avec le domaine et ce que j'entends à ce propos me fait vraiment penser que Google a le pouvoir puisque tout le monde suit comme des moutons (parfois à juste titre, je nuance). Je ne vais pas refaire des ancres de liens pourries au cas où Penguin serait fâché, je ne vais pas compresser tout sous peine de gagner de mini-octets qui en revanche me feront perdre un temps fou en réinterprétation du code et en développement, etc. Disons qu'une grande majorité des critères a un intérêt mais lorsque ces derniers sont noyés dans la masse, ils présentent chacun avantages et inconvénients.
      Selon moi, l'impact du PageSpeed dans le positionnement serait visible si on se retrouvait avec deux sites égaux (même poids, etc.). Le site compressé serait devant dans ce cas. Hormis ce cas là, le poids des pages étant bien différent d'un site à l'autre, les optimisations sont à nuancer (je défie quelqu'un d'être hyper rapide en chargement sur le très lourd Magento par exemple, un site sous Prestashop le battra par défaut).

  • Pour le chargement des pages utilisons l'Instant Page de Google xD

    C'est vrai que quand je vois les codes CSS qui ressortent après compression, ca devient illisible :s

  • Olivier dit :

    Bonjour,

    Article intéressant dont je partage partiellement le point de vue. Je crois qu'il faut éviter les comportements intégristes et vouloir tomber à tout prix dans les extrêmes de l'optimisation, comme en SEO.

    Par exemple, j'utilise assez peu les sprites sauf dans quelques cas précis.
    En revanche, je développe mes projets sur un CMS perso qui par défaut compresse les css et le code source et place le tout en cache.
    Il parallélisme les requêtes http pour tous les fichiers statiques et respecte de nombreuses règles de ce type.

    C'est implémenté au départ, pas besoin de perdre du temps avec ça, c'est intégré de façon native et pour le coup c'est très pratique.

    Pour le reste, je respecte les principales règles de bon sens, ce qui donne des sites performants sans pour autant verser dans la prise de tête systématique et contre productive.

    • Tout à fait d'accord. Si l'outil ou le CMS perso gère par défaut certains critères de compression et de mise en cache, il ne faut pas non plus tout "casser" pour obtenir un code hyper propre. L'important est de savoir coder proprement et de conserver un tantinet de rigueur plutôt que de suivre des tendances mouvantes et lunatiques...

      Dès que la SEO entre en compte, ça devient la folie en revanche, et j'ai beau adorer ce sujet et le partager avec beaucoup de personnes, je lutte contre cette bêtise humaine qui résulte du suivi de règles approximatives tels des moutons (je suis un peu sévère, je l'avoue, mais c'est purement volontaire dans ce cas). Je me rappelle du "nofollow" notamment, je disais sur ce blog depuis des mois qu'ils étaient suivis par Google, etc. Comme le moteur ne l'avait pas confirmé, je me suis fait traiter de tous les noms sur certains "grands forums" (je ne cite pas de noms...) et le jour où Matt Cutts a révélé que les nofollow étaient parfois suivis, tout le monde en a parlé en héros comme si c'était évident. Ces comportements m'agacent et montrent bien à quel point nous suivons bêtement les recommandations des critères SEO sans réflexion.

  • Olivier dit :

    Oui, je citais surtout le SEO comme une activité où l'optimisation est omniprésente.

    Pour en revenir au code, c'est certain qu'en dessous d'un seuil critique, il n'est pas nécessaire de passer ses journées à optimiser du code PHP ou HTML pour gagner quelques millisecondes.

    C'est sur que des services comme Google et Facebook, avec des milliards de visiteurs chaque mois, voir chaque jour, le moindre octet revêt une importance capitale.

    Mais pour le site de madame Michu, il faut respecter les bonnes pratiques et c'est amplement suffisant, sans y passer des jours entiers.

    D'où l'utilisation d'outils perso développés spécifiquement. 2 ans de travail pour optimiser l'outil au maximum, et ensuite, lors de l'usage quotidien, c'est du gâteau car tout est déjà implémenté et se met en place tout seul.

    Résultat, le site de Madame Michu est un avion de chasse, il est développé en quelques heures / jour selon le projet et sans se prendre la tête.

    C'est à ce niveau je pense qu'il est intéressant de travailler l'optimisation ou sur des gros projets. Je raisonne en terme de plateforme en partant du principe que ce qui n'est pas rentable pour 1 site l'est sans doute pour 100 ou 200 sites.

    Il faut atteindre une taille critique en dessous de laquelle l'optimisation à tout crin n'est pas intéressante financièrement.

  • Bonjour,

    Votre billet, semble-t-il, part d'une méprise ou à défaut d'une méconnaissance des mécanismes de génération de page web.

    Ce que vous appelez le code source HTML (visible depuis la navigateur) n'est en aucun cas le code sur lequel les développeurs travaillent.

    Le véritable code source est épargné par ces modifications, qui n'interviennent qu'après traitement par le langage serveur (PHP, par exemple) chargé de rapatrier les différents codes demandés (HTML, CSS, JS), de les optimiser en post-processing, de conserver -si elle n'existe pas- une copie du code optimisé en cache pour le prochain client (Memcached), puis de servir le code optimisé au client qui l'a demandé.

    Ces optimisations, si correctement appliquées, sont loin d'être négligeables et peuvent atteindre -d'après mes expérimentations- 20% du poids de la page (protocol relative urls, suppression des quotes / espaces, suppression des sélecteurs CSS inutiles, gestion des 304, pas de cookie pour les images, images parallélisées sur des sous domaines multiples...etc.)

    En tout état de cause, le client qui possède les bons plug-ins (Firebug, ...etc.) et autres beautifiers peut inspecter le code HTML / CSS / JS sans soucis majeur de lisibilité.

    Pas de panique donc, si Google recommande ces pratiques, c'est qu'il a une bonne raison.

    Pour ma part, avec un score compris entre 94% et 99% selon les pages de mon labo / site de test http://www.skeetmeet.com/, je peux vous garantir qu'elles ont été testées... et approuvées.

    Pour répondre aux personnes qui pensent qu'il n'est pas important d'optimiser les pages web car votre site n'a pas le trafic de Google, comprenez que votre raisonnement est faux car effectué à l'envers.

    Ce n'est pas parce que vous avez beaucoup (ou non) de visiteurs que vous devez optimiser vos pages web.

    Vous devez accorder de l'importance au temps de réponse des pages web dans une optique d'expérience utilisateur.

    Plus votre site est rapide, meilleure est l'expérience utilisateur. Si l'expérience utilisateur est bonne (mesurée par GoogleBot et vos visiteurs), alors le trafic va suivre.

    C'est dans ce sens que se passent les choses, et pas dans l'autre.

    A méditer :)

    • Je ne suis pas convaincu que vous ayez lu mon billet dans son entier pour être sincère, puisque certaines des choses sur lesquelles vous me reprenez, je les ai dites, mais de manière différente...

      Peut-être utilisez-vous mon blog seulement pour poster deux backlinks après tout, je ne vous en tiens pas rigueur car votre commentaire a du bon bien entendu.

      En aucun cas je n'ai dit qu'il ne fallait pas améliorer l'expérience utilisateur ou même la vitesse de chargement des pages (par leur poids ou pour le traitement serveur notamment). Je dis juste que je trouve cela ironique qu'avant que Google ne mette en avant cet aspect, la grande majorité des développeurs codaient un peu n'importe comment et se moquaient un peu de ces problématiques là. Maintenant, tout le monde s'accorde à dire qu'il faudrait à peine laisser un espace vide pour améliorer l'expérience utilisateur au maximum. Nous n'avons jamais eu des serveurs aussi puissants et une bande passante aussi forte mais c'est maintenant que les développeurs tiltent à ce propos ? Laissez-moi rire quelques minutes...
      Bien sûr, dans la masse, de super développeurs ont toujours pensé à cette problématique et je ne remets pas en cause ces réactions. Je suis plutôt pour l'optimisation, mais pas à tout prix. Qu'on compresse tout nos fichiers pour quelques octets et quelques millisecondes de traitement (car en réalité, il s'agit bien de ça dans 80% des cas), je dis juste que c'est un peu trop. En me donnant une leçon ici, vous prouvez d'ailleurs l'intérêt du billet puisque j'attendais de telles réactions et je reste convaincu que dans vos premiers sites conçus il y a quelques années, ça ne vous traversait même pas l'esprit de compresser (...), et pourtant c'était déjà compatible, lisible et traitable par les serveurs...

      Enfin, l'article voulait juste insister sur le fait que le critère était relatif à chaque site. Je vais prendre un exemple simple et concret : ce blog contre mon site web d'entreprise. Ce blog est fait sous WordPress et pèse à lui seul près de 30Mo avec une base de données liées bien entendu, pour une cinquantaine de pages à tout casser. Mon site professionnel perso pèse 17Mo (PDF compris, représentant actuellement 7Mo à 8Mo) pour près de 80 pages, sans base de données liée. Vous allez me dire que le poids ne compte pas mais c'est faux, il n'y a pas que le traitement serveur, le poids compte également. En conclusion, tous les sites réalisés sous WordPress (ou autre CMS) par des soi-disant professionnels qui vantent dorénavant le PageSpeed et l'optimisation sont finalement plus lourds qu'une majorité de sites "fait main". Bien sûr, tout est une question de relativité et chaque cas est à prendre à part, mais au fond, je vous défie de me contredire sur ce point.

      Je peux vous présenter de nombreux développeurs qui corroborent mes thèses, et non des moindres, je vous l'assure (je n'ai pas écrit cet article sur un coup de tête...). Certes il y a un minimum de gain (sauf dans des cas extrêmes ou lorsqu'il y a beaucoup de traitement de code) mais à quel prix ? Firebug ou WebDevelopper ne feront pas oublier la laideur du code ou les erreurs qui le composent, mais ce sera tellement illisible qu'on ne préfèrera même pas savoir. D'ailleurs, votre site-test skeetmeet contient 27 erreurs W3C avec un DOCTYPE HTML 5 qui ne sert qu'à faire joli (puisque vous n'utilisez à juste titre aucune balise de ce langage). En outre, vous utilisez bon nombre de meta obsolètes qui alourdissent votre page et le traitement serveur.
      A méditer... :D

  • fabian martin dit :

    Je suis assez daccord avec Raph SEO le mieux est de travailler avec deux versions : une version light pour que la page contiennent le moins d'octets et une version complète détaillé et documenté pour faciliter la reprise du code par ou une autre personnes.
    un developpeur multimédia
    Un article avec une réflexion derrière :)
    A méditer comme j'ai pu lire sur d'autres commentaires ^^

    • Ah un ami qui vient soutenir l'autre personne, c'est normal, j'attendais une réaction à la suite de ma provocation volontaire.
      Encore un commentaire blog uniquement SEO. Vous voyez, je suis tellement méchant que je ne les supprime pas, même quand on voit vraiment que vous n'écrivez que pour obtenir un backlink avec une ancre que Google Penguin vous fera sûrement payer à terme. :D

      Bonne méditation aussi ! ^^

  • Cordeline dit :

    «Nous n’avons jamais eu des serveurs aussi puissants et une bande passante aussi forte mais c’est maintenant que les développeurs tiltent à ce propos ?»
    Nous n’avons jamais eu de véhicules aussi rapides ni de routes aussi larges mais nous passons 3 heures par jour pour nous rendre à notre travail...

    À l’apparition de chaques nouvelles normes ou recommandations, on trouve des fanatiques, ceux qui ont gaspiller leur temps à bidouiller du JavaScript pour optenir du xhtml ou du css conformes.
    Le résultat n’était qu’apparence masquant un code farfelu.

    L’optimisation doit faire partie du développement mais de manière sobre, on ne peut pas compter sur la puissance de la machine pour compenser un code pernicieux.

    L’optimisation c’est aussi la simplification, donc un code plus facile à maintenir.

    Je pense que PageSpeed est un bon outil qui sait indiquer les optimisations nécessaires et celles qui sont plus futiles.
    Je ne pense pas que Google va pénaliser ceux qui n’obtiennent pas un score parfait, mais ceux qui conservent un code sale et pénible pour les utilisateurs.

    • Normalement Google ne va punir ni les uns ni les autres, car Matt Cutts a déclaré que le code source n'était pas leur affaire. Le PageSpeed se base juste sur la vitesse de chargement et quelques aspects qui tiennent à coeur à la firme. En gros, si le code source est dégueulasse mais que les quelques critères de Google sont respectés, le moteur est content...

      Autre point de détail que j'ai peu mentionné dans mon article, la mise en cache. Partant d'un bon principe, j'ose rappeler que la mise en cache n'était vraiment pas appréciée jadis pour des raisons de sécurité, tout comme les cookies, etc. Désormais, la mise en cache est obligatoire dans les recommandations du PageSpeed, donc là encore, nous ne faisons que contredire tout ce qui s'est fait pour de bonnes raisons.

      Selon moi, le PageSpeed n'a été lancé que pour améliorer la vitesse de chargement des sites sur les mobiles car c'est la grande folie actuelle, et comme les réseaux mobiles 3G et 3G+ ne valent pas nos connexions classiques, il faut absolument gagner du temps en mettant des zones en cache, en limitant le poids des fichiers, etc. Très honnêtement, un serveur ne souffre pas tant que ça lorsqu'un PNG pèse 500 octets de plus (je parle bien d'octets et pas de Ko), nous jouons vraiment sur des détails. Toutefois, si nous pouvons le faire et économiser toute cette bande passante, c'est un bon point, mais je pense qu'il ne faut pas le pousser à l'extrême au point de rendre un code illisible, etc.

      N.B. : je précise que je ne suis pas du tout contre le PageSpeed, loin de là, mais je trouve cela très drôle de voir les gens faire tout et son contraire à chaque mise à jour de Google, comme si de rien n'était et sans se poser la moindre question...

  • stephane dit :

    Très bon article je partage entièrement votre point de vue,lorsque que l on est professionnel en informatique et que l on vend des sites web ou un service de référencement il est indispensable que votre site soit totalement irréprochable.

    stephane

  • Déposer un commentaire

    L'adresse de messagerie ne sera pas publiée.* Champs obligatoires