CV
Datacenter

S'auto-heberger lorsqu'on a une connexion du 20eme siecle :

A l'heure ou le FTTH permet d'amener jusqu'au domicile des débits jusque la réservés aux datacenter. Certains - dont votre serviteur - se coltinent encore des bonnes vieilles connexion ADSL ... Et quand je parle d'ADSL ne je parle pas d'une connexion ADSL2+ mais bien d'une connexion du 20 eme siècle à l'upload ridicule, à peine 100ko/s ouille ...

Et pourtant ça tourne ...

Malgré tout ça j'arrive à héberger sur cette connexion, mon site Internet (celui sur lequel vous naviguer), mon espace cloud, mon git et divers services. Bon certes je suis encore loin de 30 000 visites mensuels mais pour l'instant ça tient la marée. Les temps de chargements - en ce qui concerne la partie uniquement du site - restent parfaitement utilisables pour les visiteurs.

Compte tenu des performances de ma connexion c'est excellent - 466ms pour charger la page qui fait au total 1.18MB, sur une connexion qui envoie à peine 100Ko/s en upload ... moins de 1Mpbs ...

Pour rappel Dieu Google déclassera votre site dans ses résultats, s'il considère que la connexion est trop longue pour lui.

En réalité il faut user de ruses et de souxieries pour économiser au maximum la bande passante.

Quelques moyens assez facile à mettre en place pour un premier plan d'action.

  • Héberger vos images chez un tiers :
    • C'est le premier point et le plus important, les images même optimisées pour le web pèsent lourds et par conséquent consomme un bon paquet de throughput. Donc héberger toutes vos images chez un hébergeur tiers plutôt que directement sur votre serveur, c'est indispensable si vous ne voulez pas donner une sensation de chargement 56Ko à vos visiteurs.
    • Attention en revanche le fait d'heberger les images chez un tiers cassera quelque peu le côté "responsive" de votre site notamment sur les smartphone ou les tout petits écrans.
  • Limiter les Javascripts préférer le full CSS : 
    • Javascript, en plus d'être un nid à bug, un trou à ressource, ce dernier consomme beaucoup de bande passante, car il faut que le serveur transmettre en plus de tout le code HTML l'intégralité des scripts JS nécessaire et parfois on peut se retrouver avec des situation complètement folles ou il y a plus lourd de code JS que de HTML, note je n'utilise pas une seule ligne de Javascript sur ce site ! D'ailleurs nous allons le voir plus tard, en réalité la partie HTML pure est ce qui représente le moins de volume dans les différents types de données, transmises. Le CSS transmis est bien plus lourd que le HTML.
    • Si vraiment vous ne pouvez pas limiter l'appels à des JS, utilisez leur version compressées, ou encore vérifier s'il n'est pas possible de l'utiliser en CDN
  • Activer la compression Gzip sur votre serveur web, la compression est indispensable puisqu'elle permet de diviser la taille des fichiers à envoyer notamment sur les document de type dom. Elle l’occurrence dans mon cas elle divise par 3 la taille de la page html.
  • Eviter au maximum les liens morts, les fichiers qui n'existent plus qui génère des code 404, ces deniers rajoutent énormément de temps dans le traitement d'une requête.

Gtmetrix vous donnera toute une liste d'axe d'amélioration et d'indicateurs pour vous aider en ce sens.

Analyse des flux :

Appuyons nous ensuite sur un relevé de test de chez gtmetrix pour analyser les axes d'améliorations. Il faut créer un compte pour pouvoir choisir le site géographique de test, sinon vous n'aurez accès qu'a un test depuis la côte est du Canada à Vancouver. Ca commence à faire loin et c'est peu significatif.

Une fois le tir effectué depuis Londres, décortiquons les résultats ensemble, ces derniers sont très instructifs :  

Resultat

La lecture se fait ainsi :

  • Première colonne, le type de requête (GET) ainsi que la ressource demandée par le navigateur, ce que ce dernier cherche à télécharger.
  • Seconde colonne, le code retour HTTP
  • Troisième colonne, l'url chez qui se trouve la ressource demandée + la taille de la ressource à télécharger
  • Quatrième colonne, le temps de chargement découpée en plusieurs partie chacune ayant une signification.

Le détaille des couleurs avec la dichotomie de la durée de la requête GET blog.aumont.fr sur la page http :

Un requête se découpe donc de cette façon :

  • D'abord le navigateur, cherche à résoudre l'URL via un DNS Lookup (Bleu turquoise) : 37ms mon registar est Gandi et le site est protégé via Cloudflare. La stack DNS mériterait d'être un poil optimisée.
  • Ensuite il effectue une négociation protocolaire (Vert) : Handshake http(s), échange de clé connexion TLS, gestion des cyphers, On s’aperçoit que sur une requête c'est ce qui consomme le plus de temps (97ms) D’où l'importance d'avoir un serveur web paramétré aux petits oignons sur toute la couche SSL/TLS avec des Ciphers rapides et à jour pour économiser les handshaking inutiles, un mauvais paramétrage aurait pour conséquence de faire exploser les temps de connexion ...
  • Puis en rouge, le navigateur web cause un peu au serveur, ça ne prend que ce 0.5ms, il doit lui envoyer un ack TCP ou des informations du même genre : je vous avouerai que je n'ai pas plus cherché.
  • Ensuite le navigateur attend (Waiting - rouge ), 89ms, il attend tout simplement que le serveur web exécute le traitement du fichier PHP dans mon cas (exécution du thread Nginx, temps d’exécution PHP / Connexion SQLlite), ce temps dépend directement de votre stack qui délivre le service web mais aussi des performances de votre infra.
  • Finalement le résultat (la page HTML) est envoyée vers le navigateur, le transfert est ultra rapide puisqu'il ne prends que 2.9ms ! Pour 5KB envoyé (la page non compressé fait 15KB), rappelez vous compression Gzip = yes ! On constate donc bien qu'en optimisant un peu la provenance des différentes ressource une connexion avec un upload à 100ko/s suffit très largement.

Vous constaterez également que très peu de données proviennent de mon serveur web, la plupart des requêtes GET (12 sur 14) viennent de sources extérieures.

Mon infra ne sert que le code HTML 5KB seulement (première ligne), une feuille CSS de 1KB (seconde ligne), ainsi qu'un logo PNG de 10KB (6 eme ligne que je vais externaliser pour encore plus de perf) soit au total à peine 16KB à uploader par ma machine ( moins en réalité puisque tout ceci est compressé avec Gzip), sur une page de 1.3Mb ! L'intégralité du reste des données est hébergée ailleurs sur Internet.

Une fois la page HTML réceptionnée ici à T=216ms, le navigateur commence à interpréter le contenu de cette derniere et constate que pour afficher le rendu il faut des ressources externes présente (css/image/js) notamment présent dans les balises :

<link rel='stylesheet' href=...>


Une fois ces éléments reçus, mon infrastructure n'est plus sollicitée, plus rien ne sort de ma box. Ce n'est plus ma bande passante qui est utilisée. Le navigateur se met alors à télécharger en parallèle l'ensemble de ses ressources sur chacune des plateformes concernées.

En bas des indicateurs plus ou intéressant comme la consommation de mémoire nécessaire pour afficher votre page, la vitesse de téléchargement globale de tout les composants, et l'usage CPU (honnêtement j'ai du mal à interpréter cet indicateur). Mais pour la RAM moins ça en consomme mieux c'est évidemment.

Analysons désormais un get sur une des images :

casimage-time

J'utilise à ce propose casimage hébergeur d'image français.

  • Plus de 89ms de "blocking" - Praline- : c'est énorme 1 quart du temps de la requête : A cet instant j'ignore de quoi il s'agit ... après quelques recherches je constate qu'il peut s'agir de problème de paramétrage CSS, ou bien d'un serveur web occupé, une protection anti Ddos DNS .. bref le navigateur attend ... c'est problématique car cela prend près d'un quart du temps de la requête !!
  • 10ms pour la résolution casimage.com depuis Gtmetrix.
  • 42 ms de "Connecting" - Vert - il s'agit là les négociation HTTP/HTTP(S) entre le navigateur et les serveurs web de casimage notez que j'ai fait plusieurs essais à des heures différentes de la journée et là ou le temps de "Connecting" peu monter jusqu'a 150ms, le temps de blocking lui peut descend à 50ms.
  • 7.9 ms de "Waiting" durée ou le navigateur attend que le serveur web traite la requête (exécution du PHP, JSP, ASP...), comme quoi mon infra n'a pas à rougir compte tenue des perfs affichées par un site pro comme casimage.
  • Puis vient finalement le téléchargement de l'image à proprement parlé, on constate d'ailleurs que ce n'est pas ce qui prend le plus de temps dans la requête, à peine 31ms pour télécharger une image de + de 300KB

Piste d'amélioration :

  • Voir cet aspect blocking qui retarde presque de 10% le temps de chargement.
  • Optimiser un peu plus la taille des images.
  • Régler les quelques Warning levé par gmetrix, je ne pourrais intervenir que sur les " (ETags)" je pouvant pas utiliser de CDN pour mon CSS perso.

Conclusion :

Nul besoin d'avoir la fibre optique pour d’auto-heberger et faire tourner un blog, quelques pages HTML, des services nécessitant peu de bande passante. Avec un peu d'optimisation, nous venons de voir que l'opération était parfaitement réalisable. Surtout vue le volume de visiteurs / jours rencontré (à vrai dire pas grand monde :D)

En revanche ça devient plus compliqué il est vrai, pour s’héberger une instance Nextcloud ou si vous désirez envoyer recevoir du fichier.