Qu'est-ce que le rendu côté serveur vue.js ?

Le rendu côté serveur vue.js génère des composants Vue dans le navigateur pour générer et faire fonctionner le DOM. Cependant, le même composant peut également être rendu dans des chaînes HTML côté serveur et envoyé directement au processeur du navigateur. enfin "activer" ces balises statiques dans des applications entièrement interactives sur le client.

L'environnement d'exploitation de ce tutoriel : système windows10, vue2.9, cet article est applicable à toutes les marques d'ordinateurs.

【Articles connexes recommandés : vue.js】

Qu'est-ce que le rendu côté serveur (SSR) ?

Vue.js est un framework permettant de créer des applications côté client. Par défaut, les composants Vue peuvent être affichés dans le navigateur pour générer du DOM et manipuler le DOM. Cependant, il est également possible de restituer le même composant sous forme de chaînes HTML côté serveur, de les envoyer directement au navigateur, et enfin d'« activer » ces balises statiques dans une application entièrement interactive sur le client.

Les applications Vue.js rendues par le serveur peuvent également être considérées comme « isomorphes » ou « universelles » dans le sens où la plupart du code de l'application peut s'exécuter à la fois sur le serveur et sur le client.

Pourquoi utiliser le rendu côté serveur (SSR) ?

Par rapport au SPA (Single-Page Application) traditionnel, les principaux avantages du rendu côté serveur (SSR) sont :

• Un meilleur référencement, depuis la recherche Les robots d'exploration du moteur peuvent afficher directement les pages entièrement rendues.

• Veuillez noter qu'à partir de maintenant, Google et Bing indexent très bien les applications JavaScript synchrones. Ici, la synchronisation est la clé. Si votre application affiche initialement un chrysanthème de chargement, puis récupère le contenu via Ajax, le robot n'attendra pas la fin asynchrone avant d'explorer le contenu de la page. Cela dit, si le référencement est essentiel pour votre site et que vos pages récupèrent le contenu de manière asynchrone, vous aurez peut-être besoin d'un rendu côté serveur (SSR) pour résoudre ce problème.

• Délai d'accès au contenu plus rapide, en particulier pour les conditions de réseau lentes ou les appareils lents. Il n'est pas nécessaire d'attendre que tout le JavaScript soit téléchargé et exécuté avant d'afficher le balisage rendu par le serveur, de sorte que vos utilisateurs verront plus rapidement une page entièrement rendue. Cela se traduit généralement par une meilleure expérience utilisateur et est essentiel pour les applications où le temps d'accès au contenu est directement lié au taux de conversion.

Il existe certains compromis lors de l'utilisation du rendu côté serveur (SSR) :

• Conditions de développement limitées. Le code spécifique au navigateur ne peut être utilisé que dans certains hooks de cycle de vie ; certaines bibliothèques externes peuvent nécessiter un traitement spécial pour s'exécuter dans les applications rendues par le serveur.

• Plus d'exigences concernant la configuration et le déploiement de la build. Contrairement aux applications monopage (SPA) entièrement statiques, qui peuvent être déployées sur n'importe quel serveur de fichiers statiques, les applications rendues par le serveur nécessitent un environnement d'exécution de serveur Node.js.

• Plus de charge côté serveur. Le rendu d'une application complète dans Node.js nécessitera évidemment plus de ressources CPU (consommateurs en CPU) qu'un serveur qui ne sert que des fichiers statiques, donc si vous prévoyez de l'utiliser dans un environnement à fort trafic (trafic élevé), veuillez préparer les charges du serveur en conséquence et utilisez judicieusement les stratégies de mise en cache.

La première question que vous devez vous poser avant d'utiliser le rendu côté serveur (SSR) pour votre application est de savoir si vous en avez vraiment besoin. Cela dépend principalement de l’importance du délai de création du contenu pour l’application. Par exemple, si vous créez un tableau de bord interne, quelques centaines de millisecondes supplémentaires lors du chargement initial n'auront pas d'importance, et l'utilisation du rendu côté serveur (SSR) serait une évidence. Cependant, les exigences en matière de délai de mise en ligne du contenu constituent une mesure absolument critique et, dans ce cas, le rendu côté serveur (SSR) peut vous aider à obtenir des performances de chargement initiales optimales.

Rendu côté serveur vs pré-rendu (SSR vs pré-rendu)

Si vous étudiez, le rendu côté serveur (SSR) n'est utilisé que pour améliorer quelques pages marketing (telles que / , / à propos, /contact, etc.), vous devrez peut-être effectuer un pré-rendu. Au lieu d'utiliser un serveur Web pour compiler dynamiquement du HTML en temps réel, le pré-rendu génère simplement des fichiers HTML statiques pour des itinéraires spécifiques au moment de la construction. L’avantage est que la mise en place du prérendu est plus simple et vous permet de traiter votre frontend comme un site complètement statique.

Recommandations d'apprentissage gratuites associées : JavaScript(Vidéo)

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!