Minimiser sa présence par mail et sur les réseaux sociaux

Minimiser votre présence, pas votre communication !

Le taux de conversion de vos messages par mail ou via les réseaux sociaux doit ainsi être travaillé pour obtenir un pourcentage satisfaisant. Sans ça, cela reviendrait à couper l'herbe d'un stade de foot sans qu'il ne soit jamais utilisé.

Réduire la consommation énergetique de son application ou de son site

Avant de commencer, reprenons un peu la théorie.

Une appli, ou un site, fonctionne avec des requêtes. Grossièrement une requête est :

  1. émise par un client (tentative de téléchargement d’une page via son URL)
  2. les routeurs ainsi que tout les équipements participant au transport des données transportent ces informations jusqu’au serveur
  3. le serveur génère le code des pages que vous consultez
  4. les routeurs (bis) … transportent jusqu’au client.
  5. l’affichage chez le client entraîne alors de nombreuses sous-requêtes (images, assets, vidéos, ...).

Côté Serveur

Plus votre serveur réfléchit, plus il est amené à consommé de l'énergie. De même, plus le nombre de requêtes est important, plus il sera alors nécessaire de multiplier le nombre de serveur pour répondre à la demande.

Pourtant, une grande partie du web affiche du contenu statique ou semi-statique (pouvant s'afficher plusieurs milliers de fois avant une nouvelle génération). Malheuresement, le nombre de site internet propulser par des serveurs optimisés pour déliverer ces contenus est ridicule.

Votre site a-t-il besoin de l'hyper-réactivité de Twitter ou Facebook ou s'agit-il de transmettre une info tel un site vitrine voir un site presse ?

J'ai évalué qu'entre un wordpress optimisé (34% des sites en ligne) et un CMS générant des pages statiques (tel PiedWeb/CMS pour un site à un trafic faible (1000 requêtes/jour répartis sur 100 pages), les besoins en CPU sont réduits d'un quart (nouveau test à venir avec illustation).

De plus, il est complétement possible d'intégrer des modules dynamiques (formulaires) au coeur de sites statiques de façon quasi-transparente pour l'utilisateur (qui concernera peut-être 1 visiteur sur 100).

Côté Transport des données

Plus votre page contient d'annexes (images, fichiers de styles, fichiers javascript), plus celle-ci génèrera des sous-requêtes avec des éléments lourds à transférer. Réduire leurs nombres, c'est réduire les dépenses énergétiques sur ce poste (et accessoirement permettre à votre site de charger plus rapidement tout en utilisant moins de data).

Quelques conseils techniques (qui peuvent également être valable pour le côté client) :

Pour évaluer votre travail côté front-end, des outils tel ecoindex ou mieux ecometer (open source) permettent un premier bilan visuel.

Côté Client

Plus le navigateur a de javascript a interpréter, plus il sera consomateur d'énergie.

Ainsi, voici mes premiers conseils techniques :

Moins de requêtes, moins d'énergie

Ajoutons que plus de 50% et 80% des requêtes générés le sont par des robots Il y a ceux des moteurs de recherches et agrégateurs de contenus GoogleBot, Bingbot, ceux d’entreprises Marketing qui y sont lié SemrushBot, MozBot ou encore ceux répondant à d’autres besoins comme archive.org_bot (source: mes propres logs).

Sans discuter les services que rendent chacun de ces bots qui s’identifient (d’autres peuvent le faire de manière anonyme en utilisant des user-agents ordinaires), la plupart d’entre eux ne vous sont d’aucune utilité dans votre stratégie de communication bas-carbone. Vous avez alors tout intérez à surveiller vos logs et à les bloquer.

Un blocage simple pourra être ralisé sur l'user-agent, un plus complexe (nécessitant une veille humaine des logs) sur l'IP (exemple sur askapache.com)



A la recherche constante de solutions, cette page sera complétée au fur et à mesure de l'évolution de mes pratiques professionnelles.

Si vous cherchez un technicien en communication décroissante, je vous invite à me contacter.

» contact pbagnpg@cvrqjro.pbz

Lire ou relire :