Optimisation des sites web

Cela fait un moment que je me décidais à poster cet article, mais le sujet de la performance et de la rapidité d’affichage des sites web est très vaste.
C’est en lisant un article sur WDfriday introduction à la performance pour le web mobile par Raphaël Goetter que je me suis décidé à écrire cette page afin d’y apporter mes notes.

Je me pose ici en tant qu’Intégrateur, car dans la plupart des cas, une bonne conception de son site web permet d’éviter des problèmes récurrent, même si nos collègues peuvent aussi participer à mieux concevoir nos sites web.

The Performance Golden Rule

Les Integrateurs Web doivent rendre compatible l’affichage de leurs design avec un nombre toujours plus croissant d’appareils.
Globalement la tache semble se simplifier, les navigateurs sont plus prompt à respecter les Css. Il n’est plus vraiment question de supporter les caprices de internet explorer 6 et 7, la version 8 de ce navigateur apportant nombre de correction de bogue, et interprète enfin CSS2. De plus avec ie9 on a enfin le droit d’utiliser un peu de css3 et le support grandit avec l’arrivée de IE en version 10.

Je simplifie un peu, mais l’idée est là. En tant qu’intégrateur on savait que la principale contrainte serait de supporter des écrans de plus en plus grand. Ce qui n’est pas un problème, on a un peu plus d’espace pour afficher notre design. On se contrefiche des téléphones capable d’accéder à l’Internet, ils ne représentait pas grand chose. (les telephones sont capable de se connecter au net depuis très longtemps ).

Le principal problème est de contourner des différences d’interprétation entre navigateurs.
Avec l’apparition de l’iphone premier, tout les constructeurs se sont lancé dans ce marché, nous proposant des terminaux plus puissants et plus rapides.
Ils sont munis d’un navigateur plus récent, peuvent afficher des pages web comme un navigateur de bureau, grâce à des niveaux de zoom.

C’est partit, la révolution du web mobile. Les chiffres volent de partout, 4 milliard de mobinautes potentiels… Pourtant, ces terminaux ont quelques défauts.
Il y a des années que les écran cathodiques dépasse les 800×600 pixels, nous travaillons avec des largeurs de 1024px et même 1280px dans certains cas. Maintenant il faut faire face à des terminaux de 320pixels de large ! le pixel ne fait pas tout, les meilleurs terminaux restitue 800px et même 1024px pour certains. Mais pour autant la taille physique ne permet pas une navigation aisé. 3pouces – 3,5 – 4 et 4,8pouces et encore plus pour les tablettes … Alors la navigation en pâtit un peu.

Un autre point concernent leurs connexions au réseaux. La plupart du temps elle est catastrophique, bien sur il y a des exceptions. Mais avec les réseaux WIFI c’est mieux.

Que peut-on en déduire ?

Il faut comparer cela avec les connexion adsl de certaines zones en france. Hélas même en France, tout le monde ne possède pas le haut débit ! On doit donc penser à l’impact du temps de chargement, et du rendu à l’affichage.
Chaque détail doit donner une impression de vitesse !
On estime qu’une page ne doit pas mettre plus de dix secondes pour pouvoir être visionnable. Mieux que ça, certaines études donne comme résultats que la majorité des mobinautes quitteront votre site dans les 4 premières secondes si celle ci ne s’est pas encore affiché … Et je ne parle que des études les plus optimistes! ( ou les plus laxiste selon le coté ou l’on se place )
Amazon, Google, et d’autres grande entreprises du net ont mené des expériences en “ralentissant” volontairement certaines pages, et le constat était là, un ralentissement de 0,4 secondes fait considérablement chuter les taux de conversion, le nombre de page vu, le nombre de visites …

Bon alors que peut-on faire ?

En réalité ce soucis de vitesse et de rapidité n’est pas utile uniquement pour les taux de conversions.
Une navigation rapide, physiquement et psychologiquement, vous permettra de garder captif plus longtemps votre visiteur. Mais vous permettra aussi de consommer moins de ressources, utile pour les sites à fort trafic, ou pour les plus modestes, économiser les sommes investit dans des serveurs et les bandes passantes.

Lorsque vous mobilisez une ressources pendant 10 secondes, c’est autant de temps et d’effort perdu à ne pas faire autre chose. Votre réseau travail pendant 10 secondes, votre serveur aussi.

Imaginez, qu’un script php utilise un processus pendant 10 secondes. Si vous le réduisiez à 5 secondes ce serait magique, vous pourriez doubler votre productivité, ou alors diviser par deux votre consommation !
Il existe des bonnes pratiques de conception qui vous permettent d’utiliser le php dans le domaine ou il est le plus fort, puis de transférer les données à un autre processus plus adapté a l’envoi vers le navigateur, ainsi php libère les ressources plus rapidement, il n’est plus nécessaire pour cette requête et reste libre pour en traiter d’autres, au lieu d’attendre la fin du transfert.

A propos du transfert, du texte brute se compresse très bien ! en diminuant la quantité de donnée transitant sur le réseaux, vous accélérez le transfert!
Cependant, je contredit un peu ce que je viens de dire, puisqu’il faut bien qu’un processus s’acquitte de la compression des données … Il serait donc intéressant de trouver toutes les ressources statiques textuelles, comme les css, les fichiers javascript, xml , ect… , de les compresser une fois et de n’envoyer que la version compressé. On économise toute la partie compression !

Notre Objectif alors est de jouer à l’avare du mieux que l’on peut ! Supprimez toutes les requêtes superflue, que le navigateur et notre serveur ne travaillent pas pour rien !

Quelques pistes d’optimisations…

Pour commencer, reduisont le nombre de fichiers à envoyer.
Il n’est pas rare de voir des sites webs envoyer plusieurs feuilles de styles, et plusieurs scripts JavaScripts. Alors regroupons du mieux que l’on peut ces fichiers.
Reduire une dizaines de fichiers en un ou deux, reduira d’autant le nombre de requete au serveur et de téléchargement par le navigateur !
Quand au images, si elle font parties de votre design, même combat, avant d’en réduire le poids, utilisez la technique des “sprites”. Chaque fichier assemblé est une requête de moins, un fichier en moins à charger. On pense à tort que le fichier resultant sera plus lourd, mais si on fait l’addition de toutes les images à charger, le poids total sera à l’avantage du sprite. Si le fichier est vraiment trop lourd faites deux sprites, deux requêtes seront toujours moins nombreuses que des dizaines…
Pour de petites images, pensez aussi au DataURI, en l’integrant directement dans votre css.

Ensuite divisez vos fichiers en plusieurs catégories que l’on placera sur des domaines différents. C’est le principe des CDN pour Content Delivery Network.
L’intérêt de placer les fichiers statiques comme les images, css et js sur des domaines différents permet aux navigateurs de faire des chargement en parallèle, plus une meilleure gestion du cache.
Par exemple, prenons la librairie Javascript JQuery; vous avez le choix de la faire charger via les serveurs de google, économisant votre bande passante, réduisant le nombre de requête que votre serveur doit servir, et petit bonus si votre navigateur à visité un autre site qui utilise cette technique, il ne la chargera pas puisqu’il l’aura déjà en cache.

Puisqu’on parle de cache, les fichiers statiques par définitions ne change pas. Pourquoi les faire charger à nouveau si l’utilisateur les possèdent déjà ?
Quand au fichiers dynamiques, rares sont les applications qui change le contenu à chaques secondes. Une page consulté des dizaines de fois à chaque minute a-t-elle besoins d’être regenéré a chaque fois, alors que son contenu ne changera pas avant plusieurs heures ? Un système de cache serveur pourra vous éviter tout ce travail inutile.

Les serveurs ayant des limites, on peut tenter de l’alléger, par exemple sur apache il est possible de désactiver des modules inutilisés, ou alors en utiliser un autre comme NGinx. On peut aussi chercher à libérer des ressources aussi vite que possible. (D’ailleurs on peut aussi faire les trois à la fois…). Pour libérer les ressources le plus vite possible, le plus simple est de limiter la quantité de donné à envoyer, par exemple en compressant les données, avec Gzip pour les fichiers textes ( Js, Css, html, … ). Un avantage ici pour les DataURI, puisque sous forme de texte dans votre css la compression en sera amélioré.
N’oubliez pas de “minifier” vos fichiers ( supprimer tout les espaces, les retours a la ligne, les commentaires … tout le superflu …),  autant en compresser le moins possible …

Là l’essentiel est fait, je suppose que votre fichier html est déjà bien construit, conforme aux normes du W3C et exempt du superflu. Idem pour votre Css …
Peut être une chose à propos de votre Css, Il parait que certains sélecteurs sont moins performants. Il serait bête d’avoir fait tout ces efforts pour ralentir l’affichage du navigateur, d’ailleurs certains scripts Js aussi peuvent être amélioré sans trop batailler …

Et finalement, vous consommez moins l’électricité qui fait fonctionner l’ensemble serveur réseaux et navigateur. Ben oui au passage, améliorer la rapidité d’affichage vous rendra donc d’office “Green” !

Ne charger que le nécessaire

Là ou l’article que je cite en début, est intéressant est le rappel que certaines ressources mêmes optimisé peuvent rester des boulets gourmand en ressources, et qu’il peut être utile de ne pas les servir, ou a défaut de servir une autre version pour certains périphérique.

Pour certaines images ou vidéo, on se sentira plus a l’aise avec des versions basses qualité, moins lourdes, et visuellement sur des écran de 3 ou 4pouces on ne verra pas vraiment de différences. Pour les éléments de décors Css3 grâce aux media queries offres des solutions simples. C ‘est peut-être moins évident pour d’autres éléments qui requiert une surcouche javascript. Pour les exemples je vous laisse lire l’article original qui l’expliquera bien mieux que moi.

En conclusion,

Vouloir offrir une meilleure expérience à nos visiteurs, peut aussi rendre d’autres services.