Toute entreprise dans le monde doit avoir une présence en ligne pour transmettre la valeur de ses produits ou services. Les sites Web, les applications et les applications Web sont les supports par lesquels on peut présenter ses produits devant des clients potentiels (collectivement appelés l’extrémité avant). Par conséquent, un frontal performant est la chose la plus importante pour les entreprises modernes.
Chez Kommunicate, nous utilisons React JS avec certains plugins tels que Webpack et Redux. Un développeur NodeJS bon et expérimenté possède une solide base de connaissances sur divers outils et bibliothèques. Aujourd’hui, nous partagerons les connaissances/expériences que nous avons menées pour améliorer considérablement les performances du site Web React JS.
Avant de plonger plus profondément, assurons-nous que nous sommes sur la même page. Tout d’abord, nous discuterons du flux de données de base de la façon dont votre code frontal est servi aux utilisateurs.
Chaque fois que quelqu’un ouvre un site Web, le flux de base est :
- Dans le navigateur, l’utilisateur entre l’URL du site Web et l’ouvre.
- Le navigateur interagit avec le serveur du site Web spécifié avec certains protocoles standard.
- Le serveur renvoie des réponses compréhensibles par le navigateur (dans ce cas, il s’agit de tout le code requis pour afficher les pages Web, c’est-à-dire les fichiers HTML + CSS + JS).
- Le navigateur prend cette réponse, la traite et l’affiche dans la fenêtre/l’onglet dédié.
Le schéma ci-dessous illustre la même chose.
Il faut cibler plusieurs phases/niveaux individuellement pour améliorer les performances du site Web. Dans le workflow ci-dessus, lorsque l’utilisateur accède au site Web, il y a deux phases :
- Le navigateur obtient le code du serveur — temps de téléchargement du code.
- Le navigateur exécute ce code et génère des éléments d’interface utilisateur – temps d’exécution du code.
Améliorer la phase 1 est plus facile que la 2ème car elle ne change pas avec le langage de programmation utilisé pour développer le front-end.
Dans ce blog, nous aborderons la phase 1, c’est-à-dire comment servir votre code plus rapidement.
Pour rendre votre code accessible publiquement (ou pour déployer le code), il existe plusieurs solutions :
- Utilisez une machine hébergée dans le cloud comme AWS EC2 ou tout autre service cloud et déployez-y le code.
- Créez un réseau de diffusion de contenu (CDN) et hébergez-le (par exemple, Cloud front + AWS S3)
- Utilisez un service qui gère tous les efforts humains de maintenance et de mise à l’échelle du système.
Discutons-en en détail.
Héberger le code sur le cloud
À partir de l’image ci-dessus, vous devez avoir une idée de la façon dont le code frontal est servi, n’est-ce pas ? Sinon, j’expliquerai plus loin.
Cela ressemble plus à un concept de la vieille école et à une approche assez simple. Tout ce dont vous avez besoin est une machine pour construire votre projet, exécuter un serveur, puis héberger la construction. Habituellement, aucune autre complexité n’est impliquée dans cela. Avec cela, vous pouvez mettre en place vos serveurs frontaux et servir du code sous forme d’interface utilisateur aux clients.
En gros, il existe deux façons d’héberger le code sur un serveur cloud.
Écrivez votre propre code de serveur
Écrivez du code pour exécuter le serveur et servir votre dossier de construction avec. En JavaScript, cela pourrait ressembler à ceci.
const express = require('express');
const path = require('path');
const app = express();
app.use(express.static(path.join(__dirname, 'build')));
app.get('/*', function(req, res) {
// index.html is entry point for most of the frameworks e.g. react, angular.
res.sendFile(path.join(__dirname, 'build', 'index.html'));
});
app.listen(3000, () => console.log("Example app listening on port 3000!"));Mais ce n’est pas le seul moyen. Avec le choix des langages de programmation, le code peut varier.
Utiliser des packages JavaScript
Il existe de nombreux forfaits disponibles pour le faire. L’un des plus populaires dans JS est Serve.
Avantages et inconvénients de cette approche
Parlons maintenant des avantages et des inconvénients de cette approche.
Avantages
- Plus facile de faire avancer les choses.
- Peu d’efforts sont nécessaires.
- Le coût de la mise en place des choses pourrait être moindre.
- Chaque phase de service du code aux utilisateurs est entre vos mains – tous les petits détails sont entre vos mains.
Les inconvénients
- La mise à l’échelle est difficile. La capacité du code de service dépend du nombre de machines que vous utilisez. De plus, il y aura un moment où la puissance de traitement de votre serveur deviendra un goulot d’étranglement et les demandes seront traitées lentement, c’est-à-dire le taux de demandes entrantes > le taux d’achèvement. À ce stade, vous aurez deux options pour mettre à l’échelle. Voyons les deux :
- Mise à l’échelle verticale — Augmente la puissance de traitement des machines et ajoute plus de cœurs au processeur. Le goulot d’étranglement sera toujours là dans le traitement de la machine.
- Mise à l’échelle horizontale – augmentez le nombre de machines impliquées. Vous pourriez penser que cette approche est meilleure, car vous pouvez toujours acheter plus de machines dès que vous atteignez le goulot d’étranglement. Mais le travail humain peut devenir le goulot d’étranglement, car, à un moment donné, vous aurez 4 à 5 machines. Et avec chaque version, déployer du code sur celles-ci sans affecter l’expérience utilisateur sera difficile.
- Nous disons tous qu’une machine est un cloud, mais au niveau du sol, tout cloud n’est que le PC de quelqu’un d’autre (du moins pour un professionnel de l’informatique). C’est pourquoi cette machine aura un emplacement géographique. Supposons donc que vous ayez hébergé votre code sur certaines instances AWS EC2 de la région des États-Unis. Maintenant, le problème est que, quel que soit l’emplacement de votre utilisateur (États-Unis, Royaume-Uni, IN, etc.), le code sera servi à partir d’un seul endroit. Étant donné que la distance géographique varie pour chaque utilisateur, prenez le temps de télécharger le code. Le temps d’exécution du code est une autre histoire.
Pour conclure, ce n’est pas une approche complètement fausse ; ce n’est qu’un compromis. Comme le dit notre CTO (Adarsh Kumar), tout est un compromis. Vous devez choisir parmi les options disponibles avec l’approche la mieux adaptée. Par exemple, pour une startup avec un petit budget, vous devrez peut-être optimiser le coût des ressources, humaines et machines.
Il y a de fortes chances que vous n’ayez pas une bonne équipe DevOps pour gérer tous les processus de déploiement. Vous ne pourrez peut-être vous permettre qu’une seule instance où vous devrez exécuter l’intégralité de votre système (à la fois back-end et front-end). Dans ce cas, cela pourrait être la meilleure option, car il n’y a pas beaucoup de maux de tête par rapport aux autres approches. Tout ce que vous avez à faire est d’acheter une instance de machine cloud et un domaine et d’exécuter votre code.
Le problème que nous avons rencontré avec cette approche
Nous utilisions un module tiers pour héberger notre projet React. Nous utilisions cette approche avec du code déployé sur deux instances. Au bout d’un moment, les réponses de la machine arrivaient lentement. Pour une solution temporaire, nous avons redémarré la machine. Maintenant, nous devions trouver la cause première et la réparer définitivement.
Après avoir examiné le système et les journaux et l’avoir débogué davantage, nous savions qu’il y avait un problème avec les descripteurs de fichiers. Lorsqu’un navigateur demande au serveur un fichier (fichier de code groupé), le serveur doit lire le fichier à partir du stockage local de la machine et renvoyer ces données en réponse à la demande. Comme nous utilisions le module tiers, qui gère toutes ces choses en interne, nous savions qu’il se cassait en raison d’une charge élevée ou d’une version de package inférieure.
Nous avons décidé de déplacer notre front-end vers un autre service où nous n’avons pas à faire plus d’efforts. L’équipe peut se concentrer davantage sur le développement de la logique métier plutôt que de consacrer du temps à ces frais généraux. Par conséquent, nous avons commencé à explorer quelles autres options existent et laquelle peut nous convenir le mieux.
Héberger sur un réseau de diffusion de contenu (CDN)
Celui-ci est intéressant, très performant et un peu difficile à démarrer. Avec cette approche, nous résoudrons les deux problèmes rencontrés dans la première approche.
Comme mentionné sur MDN, « Un CDN (Content Delivery Network) est un groupe de serveurs répartis sur de nombreux sites. Ces serveurs stockent des copies de données en double pour répondre aux demandes de données en fonction des serveurs les plus proches des utilisateurs finaux respectifs. Les CDN permettent un service rapide moins affecté par un trafic élevé. »
Ainsi, l’idée derrière cette approche est d’utiliser un ensemble de machines sur différents emplacements géographiques pour héberger les mêmes copies de vos actifs (dans notre cas, il s’agit de notre code frontal). Comme votre code est présent sur tous les sites principaux, le temps de téléchargement de votre site Web sera similaire pour tous les utilisateurs en fonction de leur vitesse Internet.
Mais comme toute autre approche, elle présente également des inconvénients. Bien qu’il existe de nombreux tutoriels/blogs disponibles, la configuration peut être un peu difficile. Pour en savoir plus sur la configuration à l’aide d’Amazon CloudFront et S3, vous pouvez consulter la documentation officielle d’Amazon ici.
Automatisez la maintenance et la mise à l’échelle du système
Techniquement, c’est la même chose que l’approche précédente. La seule différence est que les efforts de configuration sont déplacés vers certains services tiers. Il existe de nombreux services disponibles sur le marché, vous pouvez les essayer et voir lequel vous convient le mieux. Parlons donc de l’expérience que nous avons faite à Kommunicate dans le cadre de cette approche.
À ce stade, nous étions sûrs des choses que nous recherchions :
- Hébergement CDN.
- Meilleur mécanisme de cache.
- Facile à automatiser et à entretenir avec un minimum d’efforts humains.
Les services dans notre esprit étaient Netlify et Amplify. Nous décidons de tester les deux et de comparer les résultats des deux. Ici, je vais montrer quelques statistiques sur le fonctionnement de notre tableau de bord de production sur Netlify et Amplify.
Les services dans notre esprit étaient Netlify et Amplify. Nous décidons donc de tester les deux et de comparer les résultats des deux. Ici, je vais montrer quelques statistiques sur le fonctionnement de notre tableau de bord de production sur Netlify et Amplify.
La meilleure façon de décider ce qui fonctionne le mieux est de mener des expériences, de rassembler des faits, de mesurer des nombres, de les comparer et enfin de conclure.
Par conséquent, nous avons hébergé notre base de code sur les deux services avec la même configuration et la même version, notons le temps de téléchargement du code pour cinq fichiers, répétons cela trois fois, préparons les états moyens pour chaque fichier, puis comparons.
Matrice de comparaison du temps de service Amplify vs Netlify :
Note: Nous avons mené cette expérience en avril 2020. Après cela, de nombreuses améliorations ont été apportées par l’équipe Amplify, Netlify et Kommunicate elle-même. Ainsi, les résultats actuels pourraient être différents des données présentées ci-dessus.