Dans cet article, nous examinerons comment vue, React et Angular se comparent en termes de performances et ce qui peut être fait pour optimiser les SPA de commerce électronique exécutés sur ces frameworks frontend pour la meilleure expérience utilisateur.
Comment Angular, React et vue se comparent-ils en termes de performances
Gérer un site rapide conduit à une croissance des résultats grâce à un meilleur classement SEO, plus de visiteurs, des sessions plus longues et, par conséquent, plus de revenus. De nombreux leaders du commerce électronique qui comprennent le rôle de la vitesse se sont déjà tournés vers une architecture de commerce sans tête, permettant l’adoption de frontaux modernes, tels que les applications Web progressives et les SPA. Les frontaux SPA légers gagnent en popularité car ils constituent un moyen infaillible de résoudre divers problèmes de performances inhérents aux plates-formes de commerce électronique modernes afin que les opérateurs puissent fournir des vitrines ultra-rapides.
Eh bien, c’est la théorie. Pour vérifier ces nobles réclamations, nous avons effectué une petite analyse interne des performances. À cette fin, nous avons testé près de 2 000 sites Web de commerce électronique populaires fonctionnant sur les principaux frameworks frontend et évalué leurs performances en fonction des scores de Lighthouse 6. Les résultats étaient surprenants : le score Lighthouse moyen pour les frontaux SPA testés était seulement de 24, avec une médiane de 19 (sur 100)! Aussi faible que cela puisse paraître, ce chiffre était encore de 26 % supérieur au score moyen des 500 principaux détaillants Internet américains en termes de chiffre d’affaires.
Les sites vue.js ont été les plus rapides, avec un score moyen de 27 avec une médiane de 20. Les sites Web angulaires ont vu une moyenne de 23 ; cependant, leurs scores de performance étaient plus dispersés, avec une médiane de seulement 18. Les sites Web React ont été les plus lents testés, avec un score Lighthouse moyen de 22 et une médiane de 18. C’était surprenant, d’autant plus que le framework est utilisé par certains des plus grands acteurs, y compris des sites comme PayPal, Grammarly et Vimeo, pour n’en nommer que quelques-uns.
La conclusion du test était plutôt claire : bien que les SPA soient considérés comme plus rapides que les sites Web traditionnels, il y a encore place à des améliorations. De plus, Google Crux et d’autres outils de mesure ne suivent pas les transitions de page des applications Single-page (SPA), les présentant à tort comme étant beaucoup plus lents qu’ils ne le sont et pénalisant leurs scores. Nous écrivons plus sur cette question dans un autre article sur le blog.
Impact du temps de démarrage et des performances d’exécution sur les scores Lighthouse
Les performances des applications sont définies par deux mesures : le temps de démarrage et les performances d’exécution . La taille du bundle de code influence principalement le premier, c’est-à-dire, le code de l’application et le code du framework combinés. Les performances d’exécution dépendent des fonctionnalités d’optimisation spécifiques du framework et de la façon dont il gère la manipulation et la mise à jour DOM.
Taille du faisceau
Les trois frameworks ont des paquets de code minimaux de taille similaire. Bien que la taille du bundle du framework ait un impact sur le temps de démarrage, la mesure ne devrait pas être la cible principale lors de la comparaison des performances d’Angular, React et vue.
Plus précisément, la taille des faisceaux Angular est légèrement supérieure à celle des faisceaux vue et React, les faisceaux vue étant un peu plus petits que les faisceaux React. En outre, il est intéressant de noter que l’équipe de développement Angular optimise constamment la taille de leurs paquets de code (source).
Voir le tableau ci-dessous pour les chiffres approximatifs.
Métriques TTI et LCP de Lighthouse
Lighthouse est un excellent outil de test qui renvoie des informations précieuses sur la vitesse. Il identifie les problèmes de performances possibles et aide à optimiser les différents aspects d’un site. Un score phare est calculé en fonction d’une moyenne pondérée de plusieurs mesures (allez ici pour un récapitulatif complet). Pourtant, la plus grande peinture Contentful Paint (LCP), Time to Interactive (TTI) et Cumulative Layout Shift (CLS) sont très probablement les plus importants du point de vue de l’utilisateur. TTI et LCP sont directement liés à la vitesse de charge perçue. TTI est une bonne représentation de l’impact de la taille du bundle d’un framework sur la vitesse du SPA, car le bundle doit être entièrement évalué avant qu’un utilisateur puisse interagir avec l’application. Les sites avec un TTI long montreront différentes parties du site pendant le chargement, mais ne permettront pas aux utilisateurs d’interagir avec lui, ce qui peut finalement conduire à la frustration. La métrique LCP, quant à elle, mesure le temps nécessaire pour que le plus grand élément du contenu de la page soit rendu à l’écran.Lighthouse vs Crux données de navigation réelles
Il est à noter que les outils synthétiques de mesure de vitesse (comme Lighthouse) ne racontent pas toute l’histoire. La vitesse du site est plus sur la façon dont le site « se sent » lorsque les utilisateurs le parcourent. Un score de performance Lighthouse est un bon point de référence, mais il est quelque peu arbitraire et difficile à corréler avec une expérience du monde réel. Par exemple, il est difficile de traduire à quel point un score de performance de 60 serait meilleur, en termes d’expérience utilisateur, par rapport à un score de 50. Les tests synthétiques ont également tendance à simuler des appareils et des connexions plus anciens (par exemple, Lighthouse simule des connexions 3G), alors qu’en réalité, la plupart des utilisateurs mobiles utilisent des réseaux LTE rapides ou même 5G. Un site fonctionnant sur un framework spécifique peut « se sentir » plus rapide mais perdre face aux autres sites en ce qui concerne son score de performance brut et vice versa. Cela est principalement dû à des astuces spécifiques (par exemple, le chargement paresseux) que chaque framework emploie pour améliorer la rapidité avec laquelle le site « se sent » pour les utilisateurs. Dans les sections suivantes, nous examinerons les possibilités que chacun de ces cadres offre pour améliorer le rendement du site Web.Angulaire
Angular étend le code HTML avec de nouvelles balises et de nouveaux attributs et interprète les attributs pour effectuer la liaison de données. En raison de ses fonctionnalités riches, l’application de travail peut être beaucoup plus grande (environ 500 Ko) par rapport à vue ou React, ce qui peut avoir un impact léger sur les performances.
Abstraction MVC d’Angular (source)
Voici un résumé rapide des principaux avantages d’Angular.
- Génération de code. Angular génère un code hautement optimisé pour les machines virtuelles JavaScript, offrant ainsi les avantages du code écrit à la main. Les modèles HTML combinés avec JavaScript ouvrent la porte à des optimisations impossibles dans d’autres frameworks, par exemple React.
- Fractionnement du code. Grâce à Component Router, les applications Angular se chargent rapidement, offrant un fractionnement automatique du code. De cette façon, les utilisateurs chargent le code requis pour afficher la vue qu’ils demandent.
- Véritable DOM. Angular utilise le DOM réel ; par conséquent, il est mieux adapté aux applications monopage où le contenu est mis à jour seulement de temps en temps, pas ceux qui changent fréquemment, comme la plupart des sites de commerce électronique. Manipuler le DOM virtuel est beaucoup plus rapide car rien n’est dessiné à l’écran.
Réagissez
Créé et développé par Facebook, React est l’un des frameworks d’applications mobiles open source les plus populaires. Il ne fournit pas un large éventail de bibliothèques ; ainsi, sa taille est significativement plus petite que celle d’Angular.
Avec des données unidirectionnelles, React permet un meilleur contrôle sur le projet. Lors de la conception d’une application, les développeurs React peuvent imbriquer des composants enfants dans des composants parents d’ordre supérieur.
React offre quelques fonctionnalités intéressantes, notamment:
- DOM virtuel : les nœuds sont rendus à nouveau uniquement si nécessaire. React compare les nouvelles données avec le DOM d’origine et met à jour la vue automatiquement. Cela améliore les performances des applications de toutes tailles qui nécessitent des mises à jour régulières de contenu.
- Liaison de données unidirectionnelle : React utilise la liaison de données unidirectionnelle avec l’architecture d’application flux Controls. ReactJS aide à mettre à jour la vue pour l’utilisateur, et flux contrôle le flux de travail de l’application. Virtual DOM ajoute des avantages car il compare les nouvelles données avec le DOM original et met à jour la vue automatiquement.
- Prise en charge du regroupement et de l’arborescence : minimise la charge de ressources de l’utilisateur final.
- Prise en charge du rendu côté serveur (SSR) : offrant des gains de vitesse dans des implémentations spécifiques.
Dans une plus large mesure qu’Angular et vue, React utilise certaines techniques qui rendent la page plus rapide pour les utilisateurs finaux. Par exemple, le cadre hiérarchise l’entrée utilisateur par rapport au rendu du contenu sur la page.
Vue
Le vue est rapide et très petit avec à peine 30 Ko (gzippé), ce qui se traduit par des premiers chargements plus rapides. Cela en fait le plus petit des trois frameworks et accélère considérablement les performances des sites Web fonctionnant sur vue.
Le vue offre :
- Rendu côté serveur (SSR)
- Arbre secoué
- Regroupement
- DOM virtuel : les modifications au sein d’un projet n’affectent pas correctement le DOM. La modification du DOM réel est une tâche gourmande en ressources, de sorte que les mises à jour sont d’abord appliquées au DOM virtuel.
Consultez ce rapport de banc d’essai détaillé pour comparer les temps de démarrage, l’allocation de mémoire et la durée d’opérations spécifiques sur les principaux frameworks et bibliothèques JavaScript. Comparé à React, vue est légèrement meilleur en termes d’allocation de mémoire et de temps de démarrage, bien que React soit un peu plus rapide en termes d’exécution.
Angular et vue utilisent des modèles HTML combinés avec JavaScript. Cela leur donne plus de place pour l’optimisation que React n’offre pas. Par exemple, vue assure le suivi des dépendances empêchant les rendus inutiles des composants enfants.
Vue vs React vs optimisation angulaire du SPA
Nous savons que les benchmarks et les scores de performance ne racontent pas toute l’histoire. La vitesse du site Web peut varier en fonction de la taille de l’application et de vos efforts d’optimisation. Voici quelques idées pour optimiser la vitesse des SPA vue, React et Angular.
1. Rendu côté serveur (SSR)
Globalement, l’utilisation de SSR avec les sites SPA présente quatre avantages clés :
- SSR vous permet de charger rapidement un modèle SPA et d’afficher le contenu à l’utilisateur (bien que l’utilisateur ne puisse pas interagir immédiatement avec lui). Sans SSR, les utilisateurs fixeraient un écran vide, attendant que le contenu se charge et s’affiche dans le navigateur.
- SSR réduit la charge sur la machine de l’utilisateur final.
- Étant donné que Google peut maintenant crawler correctement le contenu SPA, le rendu côté serveur peut ne pas être aussi important pour le SEO qu’il l’était auparavant. Mais l’avantage de l’utilisation de SSR est que de nombreux autres moteurs de recherche ne comprennent toujours pas JavaScript et ne peuvent pas crawler correctement les sites lourds en JavaScript.
- Les réseaux sociaux ne peuvent souvent pas afficher correctement le contenu partagé à partir de sites SPA rendus par les clients. Par exemple, Facebook scraper se base uniquement sur les balises méta définies par le serveur et ne fonctionne pas avec les balises méta rendues côté client. Pour mieux contrôler l’apparence de votre site SPA lorsqu’il est partagé via Open Graph, SSR est un must.
- AMP accélère les premiers chargements sur les appareils mobiles mais ne vous permet pas d’utiliser JavaScript. Il est impossible de rendre AMP à partir de React sur le client, cela doit être fait sur le serveur. Cependant, même avec SSR en place, il y a beaucoup de cerceaux à franchir pour convertir une application React en une application AMP valide. Heureusement, certains frameworks frontend, comme React Storefront, peuvent tout gérer pour vous.
SSR fonctionne mieux pour les sites statiques, mais les sites Web eCommerce SPA sont toujours en cache, avec la bonne infrastructure. Avec Layer0, le contenu est rendu côté serveur à la volée, puis mis en cache à la périphérie avec notre CDN-as-JavaScript. De cette façon, les sites Web à grande échelle basés sur des bases de données, tels que les SPA de commerce électronique avec des milliers, voire des millions de pages, la personnalisation, l’inventaire en temps réel, et plus encore, peuvent ravir les utilisateurs avec des chargements de pages en moins de seconde, de l’arrivée à la caisse.
CDN-as-JavaScript service worker (appelé Layer0 workers) récupère intelligemment les données dynamiques à partir de la périphérie avant que votre visiteur ne tape sur un lien et le diffuse dans le navigateur, en fonction de ce qu’il va probablement toucher.
Les outils de réseau et de surveillance Layer0 garantissent que les données dynamiques sont mises en cache au moins 95 % du temps, protégeant ainsi votre base de données des requêtes supplémentaires créées par le préchargement. De cette façon, vous pouvez fournir des chargements de page en moins de seconde, offrant à vos visiteurs une expérience transparente de l’atterrissage à la caisse.
Réseau Layer0 et outils de surveillance
Globalement, en ce qui concerne les capacités SSR et la documentation détaillée, vue est supérieur à React, qui a besoin de bibliothèques tierces (par exemple Next.js) pour afficher les pages côté serveur.
2. AMP
AMP crée de meilleures expériences plus rapides sur le Web mobile en simplifiant le HTML et en appliquant des limitations strictes sur CSS et JavaScript. Ces pages sont ensuite mises en cache et pré-rendues sur le serveur Google, ce qui rend la transition vers votre application quasi instantanée.
L’inconvénient est qu’elle est différente de la façon dont vous écrivez une PWA/SPA et signifie une réécriture complète de l’application, sauf si vous utilisez un framework dédié avec support AMP intégré, tel que React Storefront.
Les pages AMP ont des charges de page médianes de 500 ms pour le trafic provenant du SERP de Google. Ces vitesses sont possibles parce que les serveurs Google préchargent et préchargent le contenu AMP dans le navigateur d’un utilisateur avant de cliquer sur le lien de la page AMP. Le site de commerce électronique moyen obtient une grande partie de son trafic de recherche Google (à la fois organique et payant), de sorte que ces gains peuvent avoir un impact massif.
Les sites qui utilisent AMP voient également des taux de rebond réduits, car les utilisateurs qui peuvent généralement rebondir en attendant le chargement d’une page bénéficieront désormais d’une expérience ultra-rapide.
3. Fractionnement du code
Votre application monopage se développera au fil du temps à mesure que vous continuerez à ajouter des fonctionnalités. Mais nous savons que chaque application a des fonctionnalités qui ne sont presque jamais utilisées et ralentissent inutilement. Vous devez implémenter le fractionnement de code pour garder votre application aussi rapide que possible.
Le fractionnement du code implique la création de bundles distincts pour chaque composant de niveau supérieur de votre application. Dans le cas d’un SPA eCommerce, il y aura des offres groupées distinctes pour la page d’accueil, les listes de produits et les pages de description des produits. De cette façon, lorsqu’un utilisateur arrive sur votre application via un lien vers un produit spécifique, le navigateur n’a pas besoin de télécharger et d’exécuter le code pour toutes les pages précédentes, réduisant ainsi les temps TTI et FID.
Avec le fractionnement du code, l’application peut « charger en paresseux » d’autres composants de page en arrière-plan et les utiliser si l’utilisateur décide de les parcourir. Cela économise de la bande passante et diminue le délai de première entrée ou FID (notez que FID est souvent approximé par rapport au temps de la métrique interactive ou TTI), améliorant ainsi la vitesse de votre site Web et le classement dans les moteurs de recherche.
4. Chargement paresseux
Vue, React et Angular prennent tous en charge le Lazy Load, qui, combiné au SSR, peut améliorer considérablement la vitesse.
Le Lazy Loading présente un défi lors de la mise en œuvre de SSR. Le serveur doit savoir quels composants ont été utilisés pour afficher le code HTML sortant et envoyer le code pour ces composants en même temps que le code HTML. Sinon, l’application devra monter dans le navigateur et exécuter deux cycles de rendu avant d’être prête à être interactive, ce qui augmentera le FID (et le TTI), ce qui peut conduire au flash ou au jank de contenu.
Lazy Loading et SSR sont connectés. La bibliothèque que vous choisissez pour le chargement différé (par exemple, React loadable) affectera la façon dont vous générez le HTML final renvoyé dans la réponse. Pour capturer les bundles qui doivent être chargés pour hydrater le code HTML qui a été rendu sur le serveur, vous devrez ajouter <loadable.capture></loadable.capture> à votre code SSR, puis utilisez la fonction getBundles de React loadable pour déterminer quel <script><>les balises /script doivent être ajoutées au corps du document.
Comme les conseils de client Lazy Load ne sont pas encore pris en charge globalement par tous les navigateurs, il existe quelques solutions de contournement pour implémenter le Lazy Load de manière transparente.
Solution n°1
Au lieu de rendre les images côté serveur, vous pouvez les laisser remplir côté client lors du montage de l’application.
Solution n°2
Utilisez uniquement le chargement paresseux pour les images « sous le pli », c’est-à-dire celles que vous connaissez ne seront pas visibles immédiatement après le chargement. Ceci est difficile car la ligne de pliage peut se déplacer vers le haut et vers le bas en fonction de l’appareil de l’utilisateur et de la taille de l’écran. Cependant, certaines heuristiques aident. Par exemple, sur une page de catégorie eCommerce, vous pouvez désactiver le chargement paresseux pour le premier ensemble d’images de produits (elles sont susceptibles d’être « au-dessus du pli »). Et pour les articles que vous savez être constamment au-dessus du pli (par exemple, les en-têtes, les logos de société, les icônes de panier), vous ne devriez pas activer le Lazy Load de toute façon et pouvez toujours les afficher côté serveur.
Solution n°3
La détection de l’agent utilisateur peut aider à fournir une version appropriée de la page rendue SSR. La détection de l’agent utilisateur n’est généralement pas recommandée pour la mise en œuvre d’améliorations progressives, mais elle fait l’affaire comme solution temporaire pendant que les navigateurs rattrapent et mettent en œuvre des conseils client.
Cette solution nécessite que vous normalisiez vos clés de cache de manière appropriée ; sinon, vous risquez de fragmenter votre cache de manière significative.
5. CDN moderne
Optimiser votre SPA pour la vitesse et utiliser un bon CDN en plus de cela stimulera votre site, mais cela ne suffit pas pour atteindre des vitesses inférieures à la seconde. C’est parce que la plupart des CDN traditionnels ne sont bons que pour la mise en cache des fichiers statiques, mais globalement ils ne gèrent pas aussi bien les données JSON/HTML/SSR, alors que c’est exactement de cela que les sites SPA de commerce électronique sont faits. Rendre ces sites plus rapides nécessite plusieurs technologies Web fonctionnant efficacement à l’unisson. Contrairement aux autres CDN, le CDN orienté application Layer0 fonctionne bien avec les SPA de commerce électronique. Il optimise les taux de réussite du cache à des niveaux inédits et apporte l’intelligence à la périphérie. Cela aide les propriétaires d’entreprise à déchiffrer les tendances et les opportunités d’optimisation en catégorisant les pages similaires en tant que telles (par exemple, PDP, PLP et Cart) au lieu de simplement afficher une liste infinie d’URL. Cela vous permet de prendre des mesures et de voir une différence dans les temps de chargement du site Web.
Mais surtout, CDN-as-JavaScript utilise des techniques avancées de préchargement prédictif pour diffuser les données mises en cache depuis la périphérie vers les navigateurs des utilisateurs avant qu’ils n’accèdent à quoi que ce soit. Cela garde les sites Web 5 secondes d’avance sur les robinets des acheteurs, ce qui leur permet de ravir les utilisateurs avec une expérience de navigation instantanée.
6. Outillage mobile
Angular est idéal pour créer des applications mobiles. Vous pouvez utiliser le framework pour créer une application Web qui s’exécute sur n’importe quel appareil ou développer des applications natives iOS et Android en combinant Angular avec NativeScrip. Cela vous permet de réutiliser des concepts Angular tels que la liaison de données, l’injection de dépendances, les services et le routage.
React Native est considéré comme le roi du développement multiplateforme. Il permet aux développeurs de réutiliser jusqu’à 99% du code JavaScript entre Android et iOS avec des composants de type React. Cela signifie que les développeurs peuvent créer des widgets 100% natifs qui contrôlent leur propre style. Le framework gère la couche View comme une sortie d’état pur, ce qui facilite la création d’applications compagnons pour iOS/Android avec un aspect et des performances natifs.
Bien que vue soit à la traîne par rapport à React, il offre toujours plusieurs solutions précieuses pour le développement mobile. Par exemple, NativeScript vous permet d’écrire des applications vue et de les compiler en applications iOS/Android natives.
Vient ensuite vue Native. Le framework combine les avantages des écosystèmes vue et RN, le rendu déclaratif, la liaison bidirectionnelle et un ensemble de composants de base pour créer une application native multiplateforme.
Les spas sont plus rapides mais ont toujours des problèmes de vitesse
L’attrait original d’une application d’une seule page est que les pages suivantes ne se rechargent pas pendant la navigation, ce qui conduit à une expérience de navigation plus rapide et sans friction. Mais les terminaux SPA modernes ne sont qu’une partie de la solution de vitesse du site, et quelques problèmes doivent encore être résolus :
- Les bancs d’essai et les tests de vitesse synthétiques ne racontent pas nécessairement toute l’histoire. La vitesse de ces frameworks peut varier en fonction de la taille de l’application et de vos efforts d’optimisation.
- Alors que diverses technologies frontend de pointe, y compris les applications Web progressives, les SPA et les AMP, peuvent considérablement améliorer l’expérience client, la vitesse du site Web est un problème de pile complète. Il couvre le navigateur, la périphérie et le serveur. C’est pourquoi une solution full-stack est nécessaire pour accélérer tout site Web, SPA et application multipage.
- Toutes ces technologies peuvent améliorer les vitesses mais fonctionnent mieux lorsqu’elles sont appliquées à l’unisson. Faire fonctionner toutes ces technologies ensemble est une tâche complexe que les équipes internes peuvent ne pas être en mesure de gérer (par exemple, il faut créer une couche Node.js).
Layer0 : rendre le Web instantané et simple
Layer0 est une solution complète pour rendre les sites Web de commerce électronique plus rapides et plus faciles à développer. Il combine des techniques d’optimisation avancées pour accélérer les sites Web à grande échelle, pilotés par des bases de données, tels que les SPA de commerce électronique, ainsi que des outils puissants qui redonnent aux développeurs un jour par semaine en plaçant le code au centre de leurs flux de travail. Layer0 apporte essentiellement JAMstack aux grands sites Web de commerce électronique.
Instantané : en combinant des frontaux modernes avec un CDN-as-JavaScript avec un taux de réussite de cache de 95% pour le contenu dynamique à la périphérie et un backend Node.js pour frontend, Layer0 aide les sites Web complexes à optimiser la vitesse sur l’ensemble de la pile. C’est la seule plate-forme garantissant des temps médians inférieurs à la deuxième plus grande de peinture de contenu (LCP) pour les sites Web de commerce électronique à grande échelle.
Simple : Layer0 (maintenant Edgio) est votre plate-forme tout-en-un pour développer, déployer, prévisualiser, expérimenter, surveiller et exécuter le frontend qui vous permet de:
- Utilisez JAMstack pour le commerce électronique via le rendu pré et juste à temps
- Activez la mise en réseau sans latence via la prélecture des données à partir des API de votre catalogue de produits
- Configurez Edge nativement dans votre application (CDN-as-JavaScript)
- Exécutez les règles d’arête localement et en pré-prod
- Créez des URL de prévisualisation à partir de GitHub, GitLab ou Bitbucket avec chaque nouvelle branche et push
- Exécutez des divisions à la périphérie pour des tests A/B performants, des déploiements canary et des personnalisations
- JavaScript sans serveur beaucoup plus facile et fiable qu’AWS Lambda
Conclusion
Exécuter un site plus rapide n’est pas seulement un gadget de fantaisie. En fin de compte, vous n’essayez pas seulement d’impressionner vos utilisateurs, mais aussi de plaire au plus grand moteur de recherche au monde. Puisque le classement de Google sera bientôt déterminé, en partie, par la vitesse de page, il ne peut pas être pris à la légère. Un site rapide signifie augmenter votre classement SEO et vos conversions, ce qui, à son tour, génère plus de revenus.
Bien que l’on puisse dire beaucoup sur la performance de chaque cadre, il y a trois points à retenir:
- Les différences réelles dans la performance du cadre peuvent être minuscules. La performance des sites SPA dépend de tellement de variables qu’il est impossible de comparer ces frameworks côte à côte de manière significative.
- Que vous soyez sur Angular, vue ou React, il y a encore beaucoup de place à améliorer.
Accélérer les SPA nécessite une combinaison de technologies Web avancées fonctionnant à l’unisson, et vos équipes internes risquent de ne pas être en mesure de les mettre en œuvre efficacement. Heureusement, quelques fournisseurs avant-gardistes, y compris Layer0, ont fait le travail lourd pour vous.
Layer0 combine le rendu côté serveur avec la prélecture prédictive avancée et la pré-mise en cache à la périphérie. Comme les données dynamiques sont mises en cache au moins 95 % du temps, votre base de données est protégée contre les requêtes supplémentaires créées par le préchargement. Layer0 CDN-as-JavaScript service worker récupère intelligemment vos pages dynamiques avant que votre visiteur n’appuie sur un lien. De cette façon, vous pouvez fournir des chargements de page inférieurs à la seconde sur les applications monopages, offrant à vos visiteurs une expérience transparente de l’arrivée à la caisse.
