EcoConception Logicielle

Design

Préférer les CSS aux images

Minimiser la quantité d’octets utilisés en utilisant les capacités graphiques du navigateur plutot que de transférer des images.

Les images les plus simples, compressées et utilisant une palette de couleur minimum auront une taille de fichier dépassant largement le kilo-octets . Cette taille peut aller facilement à 10 voir plusieurs centaines de kilo-octets. Cette charge sera à transférer lors de la lecture de la page sur le poste client.

Les navigateurs possedent des capacités de création d’objets graphiques en interprétant des codes textes de mise en page (le CSS).
Ces objets graphiques vont des simples rectangles colorés et augmentés de bordure pour le css2 jusqu’à des objets arrondis, en 3D et avec des dégradés de couleurs pour le CSS3 désormais courrament interprété.

Utiliser des objets définis par CSS remplace plusieurs fichiers de plusieurs milliers d’octets par quelques lignes de codes de plusieurs dizaines (au plus centaines d’octets). Ce code étant rassemblé dans un seul fichier, l’économise s’étend aussi au cout du transfert HTTP pour chaque image.

Favoriser une intégration du design sémantique et efficace

Une architecture de code complexe ou une mise en page brouillonne augmentera la quantité de données transférées ainsi que la consommation électrique du site via son usage.

En effet, soit à cause du temps de calcul du navigateur soit à cause du temps de lecture par un utilisateur qui trouve difficilement ses informations, le poste client restera plus longtemps en activité et forcément, consommera davantage.

La notion de design couvre aussi à la fois celui du code html vu par le navigateur et la mise en page vue par l’utilisateur du site.

Le design du code, quand à lui, doit utiliser au mieux les recommandations des normes W3C.
Les balises html doivent être utilisées au minimum, dans un but de séparation sémantique des données et pas dans un but de mise en page.
La mise en page se fait uniquement dans les fichiers CSS, de manière indépendante.

En ce qui concerne le design de la mise en page,
La mise en page doit être cohérente sur tout le site afin que l’utilisateur trouve aisément les informations mises à sa disposition.

Favoriser les polices standard

Eviter de surcharger les téléchargements avec des fichiers de polices de caractères.

Le besoin d’un site d’une lecture fluide et d’une identité visuelle étant prise en compte, des chargements inutiles et répétés de polices de caractères à chaque page du site est une erreur à éviter.

Code (Serveur)

Mettre en cache le Bytecode

Optimiser le traitement par le serveur des scripts et programmes en langages interprétés.

Sur le serveur, les programmes en langages interprétés (php, perl, python, …) sont stockés sous leur forme originale (texte).
Le serveur doit, à chaque, exécution interpréter le langage avant son exécution.
Ceci donne du travail supplémentaire au serveur et ajoute du temps d’attente au poste client.

Minimiser le nombre de requêtes SQL

Une connexion à une base de données, quelle que soit son type (SGBD, système de fichier, …) est couteux en ressources processeurs, mémoires et réseau pour l’architecture du serveur.
Cette règle évite de trop nombreuses connexions à une base.

Si une boucle effectue une requête à chaque itération, ceci dégradra la performance et l’empreinte globale du site.

Il est donc nécessaire d’exclure toute requête de toute boucle itérative.

On pourra aussi par exemple utiliser des transactions

Utiliser un système de cache pour l’accès à la base de données

Une connexion à une base de données, quelle que soit son type (SGBD, système de fichier, …) est couteux en ressources processeurs, mémoires et réseau pour l’architecture du serveur.
Il est donc important de pouvoir éviter les connexions dès que cela est possible.

Plusieurs cas d’utilisations de données sont possibles : la recherche de données dans une page ou la recherche d’adresse de page ou de fichier (pour certains CMS).

Dans un premier temps, le choix du type de base doit s’adapter au besoin. Une base de données relationnelle ne sera efficace qu’au delà d’un millier de données. D’autre part il n’est pas avantageux d’utiliser un CMS incluant un SGBD pour, par exemple, simplement une dizaine de pages de présentation.

Ensuite, si une base est nécessaire, son utilisation doit se faire sous un controle maitrisé et justifié.

Préciser la colonne de recherche lors des requêtes

Minimiser la quantité de données lors de la réponse à une requête et minimiser le travail du serveur de base.

Le serveur de base de données consommera plus de CPU et de mémoire pour chercher lui-même la liste des champs d’un objets et à tous les renseigner que de traiter une liste de champs spécifiée.

Favoriser les pages statiques

La génération des sites de façon dynamique (via CMS, en PHP…) consomme plus de ressource qu’une simple page statique.

Il est nécessaire de favoriser les pages statiques dans la mesure du possible. Par exemple dans le cas d’une page dont le contenu ne change pas (présentation d’une société par exemple), on pourra utiliser une page statique.

Si l’on souhaite conserver un CMS, on peut utiliser des plugins qui générent le contenu de façon statique

Pour les sites à fort traffic et à contenu dynamique, on favorise l’utilisation de proxy web, qui génèrent des pages statistiques

Optimiser les conditions d’itération

Diminuer le nombre de traitements par le serveur lors d’une itération à l’intérieur d’un script.

Lors d’une itération, il est recommandé de calculer à l’avance toutes les variables utilisés dans la boucle et qui resteront stable.
Ceci évite de refaire, lors des conditions de sorties (ou même à l’intérieur de l’itération), des calculs inutiles car déjà connus.

Limiter le nombre de résultats des requetes base de données

Diminuer la taille des requêtes effectuées en base de données, accélérer le temps de génération d’une page.

Lors de l’utilisation de requête de sélection, la récupération d’un grand nombre de données entraine l’attente de la réponse de la part du serveur. Le contrôle du nombre de réponses obtenues permet de conttrôler le temps de génération d’une page.

Supprimer les javascript redondant

Les sites intégrent des codes javascripts soit directement dans le code HTML soit dans des fichiers externes. Il est possible dans certains cas que le code soit dupliqué plusieurs fois dans la page ou qu’un même fichier soit appelé de multiple fois.

Dans ce cas, le code dupliqué consomme des ressources inutiles (fichiers plus lourd, code interprété plusieurs fois…). Ceci apparait généralement dans le cas de CMS qui peuvent intégrer du code externe (code google analytics, code réseaux sociaux…).

La redondance arrive de plus généralement quand le même code est intégré dans chaque page du site (par exemple le code google analytics intégré).

Il est nécessaire de supprimer le code javascript redondant dans les sites :

– Eviter d’intégrer des codes similaires dans une même page. Regrouper pour cela le code redondant dans un fonction commune

– Eviter le code redondant entre les pages. Par exemple, il est utile d’externaliser le code javascript du code HTML pour rendre le code commun entre les pages.Ce fichier sera de plus mieux géré en cache.

– Vérifier les multiples inclusions de fichiers (par exemple jquery), en particulier les inclusions via des plugins dans les CMS.

Contenu

Optimiser les images

Les images, contiennent beaucoup plus d’octets que les textes mais sont utiles pour rendre un site lisible et attractif.
Il est donc demandé de diminuer par tous les moyens de réduire le poids des images.

Ll’image doit être compressée, si possible avec perte de données.
Il est possible, sans déceler de différence à l’oeil, de bénéficier d’un taux de compression jusqu’à 80%.
Seules ces images compressées doivent être archivées sur le serveur.

Mettre en cache le favicon.ico

Eviter une demande de téléchargement du favicon.ico systématique à chaque page et qui, de plus, peut générer une erreur.

Le favicon est recherché par les navigateurs ; il change peu, il doit donc être présent, et être l’objet de règles de cache pour ne pas être redemandé trop souvent.

Adapter les vidéos aux périphériques de visualisation

Diminuer la taille des vidéos servies en fonction de la taille de l’écran de l’utilisateur

Prévoir plusieurs formats et tailles de vidéos permet de fournir à l’utilisateur un média adapté à son périphérique, et diminuer ainsi la taille du fichier à charger pour l’utilisateur final.

Ne pas redimensionner les images dans le code HTML

Les images affichées doivent l’être à leur juste dimension afin d’éviter le chargement inutile d’une image plus grande et donc plus lourde que nécessaire

Préférer le texte brut au HTML lors de l’envoi des mails

Si le site prévoit des envois d’e-mail, et d’autant plus s’il s’agit d’envois fréquents ou nombreux, il est recommandé de ne transmettre que le minimum d’information nécessaire.
Ceci peut diviser en moyenne par 4 le poids des messages envoyés.

Appliquer une alternative textuelle aux images.

Les images doivent systématiquement posséder un attribut « alt ».

L’attribut alt doit vide si l’image est décorative, porteur de sens si l’image est informative. Un attribut alt absent, ou renseigné alors qu’il devrait être vide posera des problèmes de restitutions par les aides techniques (lecteur vocale, etc).

Hébergement

Utiliser un serveur avec une technologie non bloquante

Les serveurs web classique sont généralement basés sur des technologies « tread » (par exemple apache). Avec ces technologies, lorsuq’il y a des visiteurs concurrents, les ressources matériels sont allouées pour chaques utilisateurs tant que les données ne sont pas transmises. Enormement de mémoire est par exemple utilisée.

Les serveurs de type non bloquant permettent un usage plus efficient des ressources matérielles.

Il est nécessaire d’utiliser des technologies non bloquante et basée sur des événements pour les serveurs web.

Ajouter des entêtes Expires ou Cache-Control

Il est possible de diminuer la quantité de fichier transmise sur le réseau en forçant la mise en mémoire cache par le navigateur des fichiers du site.

Lors de sa première visite d’un site, le navigateur reçoit tous les fichiers nécessaires à l’affichage de la page.
La plupart de ces fichiers seront utilisés à nouveau, non seulement lors d’une consultation de cette même page mais lors de la consultation d’autres pages du site.

Il est donc très intéressant que le site demande une « mise en cache » de tous les fichiers qui resteront inchangés entre deux consultations du site.

Compresser la sortie HTML, CSS et JS

Diminuer la taille des pages générées en utilisant la compression fournie par les serveur web

L’activation de moteurs de compression (deflate/gzip sous apache, gzip sur ngnix…) permet de réduire le poids de la page en compression les données envoyées au navigateur.

Regrouper les javascripts et les CSS

Réduire la taille des fichiers CSS envoyés au navigateur

Les fichiers CSS controllent le style d’un page web ; lorsque plusieurs fichiers sont utilisés, ils peuvent être regroupés en 1 seul fichier afin d’éviter de multiples requêtes HTTP

Minifier les fichiers JavaScript

Réduire la taille des fichier javascript.

Le fichiers javascript écrit peuvent être optimisés en supprimant les commentaires et espaces inutiles à leur interprétation par le navigateur.

Supprimer les règles CSS inutilisées

Minimiser le poids des fichiers CSS en supprimant les règles ou les fichiers CSS qui ne correspondent pas aux objets du site consulté.

Les fichiers CSS tranférés avec la page ne doivent pas contenir de règles inutilisés dans le site (ou au mieux dans la page).
Il est important que les fichiers CSS, venant par exemple de démos ou importés d’autres sites, ne soient pas utilisés sans y supprimer toutes les règles non utilisés.

Minifier les fichiers CSS

Minimiser la quantité d’octets nécessaire pour un fichier CSS en supprimant des caractères inutiles ou en optimisant certains codes.

Les fichiers CSS peuvent être allégés de plusieurs manières :
– par des suppressions de caractères inutiles, par exemple
* en supprimant les sauts de ligne inutiles (ou tous les sauts de ligne)
* en supprimant les espaces et les commentaires
– en optimsant le code , par exemple
* supprimer les « ; » redondants ou de fin
* supprmier les déclaration vides (ou en commentaires)
* optimiser les déclarations des couleurs – #0 vaut mieux que rgb(00,00,00)

Désactiver les modules qui ne sont pas utilisés

Charger des modules (javascripts, CSS, ou autres librairies) augmente le poids total de la page. Or, ce poids joue sur la consommation du poste client et des équipements du réseau entre le serveur et chaque poste client.

En plus de diminuer le poids des images, des requêtes http inutiles et des javascripts redondants, le code peut être optimisé pour ne pas charger de librairies ou de codes CSS inutiles.

Code (Client)

Réduire la profondeur du DOM

Simplifier le DOM (Document Object Model) économisera du traitement (affichage, mise en forme, traitement javascript) par le navigateur client.

Le DOM doit être le plus simple possible.
Son arborescence doit être limité et ne pas développer de profondeurs inutiles.
Les éléments disponibles en HTML5 rendent possible un code html lisible et facile à mettre en forme en CSS sans créer des « boites » inutiles.

minimiser le nombre d’Iframes

Réduire le nombre d’iFrame dans le code source, voir s’en passer si possible

Une iFrame qui ne répond pas peut bloquer le site.
On ne peut contrôler le contenu de l’iFrame, il n’y a donc aucune action d’optimisation sur les images ou les scripts possibles ; une iFrame peut donc allonger les temps de chargement

Utiliser des timers les plus adéquates aux éxigences de performance

Les systèmes d’exploitation possèdent des timers périodiques qui séquencent les traitements. Par exemple, Microsoft Windows séquence ses tâches avec un timer de 15,6 ms. Si aucun traitement n’est nécessaire, le processeur se réveille puis entre dans un mode de veille. Certaines applications (comme les applications multimédias) diminuent ce timer pour avoir une performance plus importante.

Cela a un impact sur la consommation du processeur car il entre moins souvent en veille.

Il faut limiter l’usage de fonction qui augmente le timer des systèmes. Par exemple on évitera l’usage de settimout ou setInterval avec des variables inférieur à 10 ms.

Adapter le fonctionnement si l’utilisateur ne visualise pas la fenêtre

Ne pas rafraichir les pages

Il est possible de demander le rafraîchissement d’une page internet régulièrement via la balise metadata avec l’attribut Refresh : <META HTTP-EQUIV= »Refresh » CONTENT= »n »>.
Cela permet de mettre à jour la page (par exemple pour recharger des publicités…)

Cependant cela est couteux car toute la page est rechargée. Même si le cache est utilisé, il y aura des requêtes et des traitements.

L’utilisation de <META HTTP-EQUIV= »Refresh » CONTENT= »n »> devrait être interdite. Si un rafraîchissement est nécessaire, il est préférable d’utiliser des technologies comme AJAX.

De la même manière, l’utilisation de JavaScript doit être évitée afin de recharger la page.

Ne pas charger de données lourdes si elles ne sont pas visibles.

Le but est de diminuer le poids total des éléments téléchargés en se limitant aux données visibles.
Ceci n’a de sens que si le volume de données non visibles (images, graphiques) est important.

Dans les cas où la longeur de la page est bien supérieure à la hauteur de la fenêtre du navigateur et que la quantité de données à afficher est importante, il est possible de ne pas afficher les données (images) non visibles.

Ne pas lancer des contenus de type vidéo, sons sans action de l’utilisateur (dont le passage à la souris)

Eviter le lancement automatique de contenus multimédias sans action volontaire de l’utilisateur (clic par exemple)

Les contenus multimédias consomment de la bande passante et des ressources (CPU/GPU, RAM).
Un lancement non sollicité consommera donc de l’énergie sans utilité finale, car il n’y a pas de solliciation utilisateur.
De plus, le lancement automatique de contenus multimédias pose des problèmes d’accessibilité