Points clés dans le choix du rendu SSR, CSR et streaming

De nombreuses équipes discutent de SSR, CSR et de rendu en streaming, et la première chose qu’elles posent concerne les performances.

Quelle est la durée du premier temps d’écran, le LCP peut-il être supprimé, le référencement peut-il aider, les interfaces peuvent-elles être parallélisées et le streaming peut-il être squelettisé plus tôt. Bien sûr, ces éléments sont importants, mais lorsqu’il s’agit de projets, la première chose qui gâche la page est souvent le nombre de fois où les mêmes données ont été récupérées, à quelles couches elles sont mises en cache et qui les fermera en cas d’échec.

Mon jugement est le suivant : **La clé de la stratégie de rendu frontal n’est pas de savoir qui est le plus avancé, le rendu SSR, CSR ou en streaming, mais le fait que les mêmes données de page doivent passer par plusieurs fois de récupération, plusieurs fois d’hydratation et plusieurs séries d’annulations d’échec. Une fois qu’une page recherche simultanément le référencement, la vitesse d’interaction et l’accès au cache, les premières choses à échapper à tout contrôle sont généralement la cohérence des données, la couverture des erreurs et les coûts de dépannage. **

Ce qui gâche vraiment la page, ce n’est généralement pas la méthode de rendu elle-même.

J’ai vu de nombreuses pages, et au début, ce n’était qu’une page de détails de contenu très ordinaire :

• Cliquez sur la page de liste pour plus de détails ;
• Nous espérons que les moteurs de recherche pourront explorer le premier écran, nous avons donc besoin de SSR ;
• Il y a des interactions telles que des collections, des commentaires et des recommandations sur la page, le client doit donc continuer à faire des demandes ;
• Afin de rendre le premier écran plus rapide, l’interface est divisée en données principales et blocs secondaires ;
• Afin d’améliorer le taux de réussite, le serveur ajoute une mise en cache périphérique et le client ajoute une couche de mise en cache des requêtes.

Jusqu’à présent, chaque décision peut être justifiée.

Le problème est qu’une fois ces décisions empilées, il existe en réalité au moins quatre chemins permettant aux « données d’atteindre la scène » sur la page :

1. Les données obtenues lors du premier rendu du serveur ;
2. Les données supprimées lorsque le navigateur est hydraté ;
3. Une fois le client monté, il renvoie la demande pour obtenir les nouvelles données ;
4. Données dérivées mises à jour localement après l’interaction de l’utilisateur.

S’il n’y a pas de priorité claire entre ces quatre chemins, la page commencera à rencontrer d’étranges problèmes familiers :

• Ce que vous voyez en HTML est l’ancien prix, et il apparaîtra dans le nouveau prix après hydratation ;
• Le premier rendu d’écran affiche « Favoris », mais après que le client prend le relais, il revient à « Pas favori » ;
• Le bloc recommandé est en retard d’un pas et la page mise à jour est partiellement repoussée à l’ancienne valeur ;
• Lorsque le serveur signalait une erreur, il affichait un ensemble de détails et, après une nouvelle tentative du client, il affichait un autre ensemble de détails.

Ces problèmes sont dus au fait que le même statut de page est généré et écrasé plusieurs fois, mais personne ne définit qui a le dernier mot.

SSR résout la visibilité du premier écran, mais ne résout pas automatiquement la source de la vérité des données.

Une situation courante consiste à considérer SSR comme « cracher d’abord la bonne page », mais cette phrase n’est vraie que sous un principe très étroit : **Les données obtenues par le serveur sont les données finales que l’utilisateur devrait réellement voir cette fois. **

En réalité, cette prémisse n’est souvent pas vraie.

Par exemple, les informations sur le produit sur l’écran d’accueil de la page de détails sont restituées par le serveur, mais les informations suivantes ne le sont souvent pas :

• Si l’utilisateur a cliqué sur les favoris ;
• Quel ensemble de recommandations est actuellement concerné par la catégorie expérimentale ;
• Inventaire géographiquement pertinent ;
• Tarifs ou droits liés à la connexion ;
• Mises à jour asynchrones terminées juste après le montage de la page.

Pour le moment, SSR ne peut garantir que « d’abord cracher une version pour afficher les résultats », mais ne peut pas garantir que cette version des résultats sera la vérité finale de la page entière.

Une fois que l’équipe exige également que « le serveur produise d’abord du HTML, et que le client prenne le relais et ajoute ensuite la personnalisation », le système se divisera naturellement en deux ensembles de jugements :

• Le serveur détermine en premier à quoi doit ressembler la page ;
• Le client détermine à quoi la page devrait finalement ressembler.

Si les conditions d’accès, la synchronisation de la mise en cache et les stratégies de tolérance aux pannes des deux côtés ne sont pas complètement cohérentes, la page sera définitivement incohérente.

Ce que la RSS devrait donc réellement demander, c’est :

• Combien de temps les données sorties par le serveur peuvent-elles être conservées à jour cette fois-ci ;
• Quels champs peuvent être parcourus après hydratation ;
• Quels champs doivent être basés sur les derniers résultats du client ;
• Les pannes côté serveur et les pannes côté client correspondent-elles au même ensemble de sémantique ?

Sans clarifier ces problèmes au préalable, SSR n’enverra qu’une certaine version de la réponse à l’utilisateur à un moment antérieur, plutôt que de résoudre la cohérence à un niveau supérieur.

Le vrai problème avec la RSE est qu’il est facile d’écrire la sémantique d’actualisation de manière vague

La RSE est souvent critiquée pour sa lenteur, et à juste titre. Mais mon problème le plus courant est que les projets RSE ont tendance à écrire « réextraire les données » comme action par défaut sans contrainte.

La page est initialisée et extraite une fois ; Coupez la languette et tirez-la une fois ; Tirez à nouveau le focus de la fenêtre ; Une fois l’opération de l’utilisateur réussie, tirez-la à nouveau facilement ; La bibliothèque de requêtes réessaye automatiquement.

Le code semble naturel, mais l’effet final peut être :

• L’état de la page est écrasé plusieurs fois en peu de temps ;
• L’ancienne requête renvoyée ultérieurement remplacera la nouvelle requête renvoyée en premier ;
• La mise à jour optimiste vient de prendre effet et a été repoussée par une récupération complète ;
• Un certain composant local est actualisé séparément et le statut au niveau de la page est réassemblé dans une autre version du résultat.

Ce type de problème est particulièrement courant en matière de RSE, car le client considère naturellement « extraire à nouveau les données les plus récentes maintenant » comme une action peu coûteuse. Mais tant qu’une page contient à la fois une liste, un résumé et des commentaires interactifs, la récupération consiste à réévaluer l’état de la page entière.

S’il n’y a pas de règles claires, la RSE finira par devenir : peu importe qui obtient les données en premier, qui a le dernier mot, qui obtient finalement les données avec succès.

Bien entendu, la page est instable pour le moment. Cela a moins à voir avec le CSR lui-même qu’avec une ouverture trop large du chemin d’écriture.

Le coût du rendu en streaming le plus facilement sous-estimé est le coût de l’interprétation de l’état provoqué par « l’arrivée du lot »

Le rendu en streaming au cours des deux dernières années peut facilement être considéré comme un avantage net :

• Le squelette arrive plus tôt ;
• Le contenu clé sort en premier ;
• Peu importe si le bloc secondaire est postérieur ;
• L’expérience utilisateur sera plus fluide.

Tout cela est vrai. Mais il a un prix qui est rarement sérieusement pris en compte dans les revues de plans : la page ** n’a plus seulement deux états : « arrivé » ou « non arrivé », mais a à la place plusieurs blocs arrivant par lots, des erreurs par lots et des rollbacks par lots. **

Une fois la page divisée en fragments asynchrones tels que le contenu principal, les commentaires, les recommandations, les espaces publicitaires et les couches flottantes personnalisées, ce n’est pas seulement les performances qui doivent être traitées, mais aussi les problèmes d’ingénierie suivants :

• Si la version des données de base sur laquelle repose un certain bloc arrivant tardivement et la première version d’écran sont les mêmes ;
• Lorsque le bloc principal réussit et que le bloc secondaire échoue, si la page entière peut toujours être considérée comme réussie ;
• Si le contenu déjà émis dans le flux peut être renversé par des fragments ultérieurs ;
• L’utilisateur a déjà commencé l’opération après l’arrivée du premier fragment de page. Les fragments suivants écraseront-ils les résultats de l’interaction.

Ce coût n’est pas abstrait. J’ai vu une page qui extrait les informations principales et ajoute des recommandations associées et des droits d’utilisateur dans un format de streaming. Il s’avère que le bug le plus difficile à résoudre en ligne est “la copie des droits vue par certains utilisateurs changera deux fois en deux secondes”.

Finalement vérifié, c’est :

• Le premier segment du serveur utilise l’ancien instantané d’équité dans le cache public ;
• Les segments de streaming suivants utilisent une nouvelle interface avec le mode utilisateur ;
• Une fois le client hydraté, les champs d’affichage sont recalculés en fonction de l’état de connexion local.

Les trois ensembles de sources ont du sens, mais une fois réunies, la page ne ressemble pas à un système.

Ce qui doit être conçu en premier, c’est la ligne de données principale de la page.

À la fin de la discussion sur les stratégies de rendu, je me suis de plus en plus préoccupé de savoir si la page contenait une ligne principale de données claire.

Ce que l’on appelle l’axe principal des données consiste à déterminer à l’avance les éléments suivants :

1. Quelles données constituent la première référence d’écran ?

Lorsque le premier écran HTML apparaît, les champs qui peuvent déjà être considérés comme de vraies valeurs affichables et ceux qui ne sont que des résultats fictifs doivent être clairement indiqués.

Par exemple :

• Le texte de l’article peut être basé sur les résultats du SSR ;
• Le statut similaire de l’utilisateur ne peut être déterminé que par la demande de statut de connexion du client ;
• Le bloc recommandé est déclaré dès le début comme “achèvement asynchrone, ne participe pas à la vraie valeur du premier écran”.

Tant que cette couche n’est pas définie, chaque série de demandes ultérieure sera en concurrence avec la série précédente pour les droits d’interprétation.

2. Quels champs peuvent être écrasés et quels champs ne peuvent être remplis que de manière incrémentielle ?

De nombreuses pages sont écrites de manière encombrée, car toutes les données qui arrivent plus tard sont par défaut « les plus récentes et les plus fiables ». Pas vraiment.

Certains champs conviennent à la couverture, tels que l’inventaire, le prix et le nombre de personnes en ligne ; Certains champs ne peuvent être remplis que, comme la pagination des commentaires et la liste de recommandations ; Certains champs doivent être écrasés avec jugement de version, comme le statut de la collection que l’utilisateur vient d’exploiter.

S’il n’existe pas de règles de remplacement au niveau du champ, plus il y a de demandes ultérieures, plus la probabilité que l’ancienne valeur remplace la nouvelle valeur est grande.

3. L’échec côté serveur et l’échec côté client ont-ils la même sémantique ?

Ceci est facilement négligé.

Dans certains systèmes, lorsque la requête du serveur échoue, elle sera directement rétrogradée vers le module par défaut ; lorsque le client échoue, un bouton de nouvelle tentative d’erreur indépendant s’affiche. Le résultat que l’utilisateur voit est :

• Lors du rafraîchissement de la page, ce contenu disparaît tranquillement ;
• Une fois la page montée, ce contenu affiche soudainement un état d’erreur.

En effet, le système ne dispose pas d’une explication unifiée des « échecs ».

Dans un même bloc, si les sémantiques de panne du serveur et du client sont différentes, il sera difficile de répondre lors du dépannage : s’agit-il d’un downgrade normal ou d’un affichage anormal ?

Un malentendu courant : prendre “récupérer les dernières données” comme une assurance

Lorsque de nombreuses équipes rencontrent des problèmes de cohérence, leur première réaction est « alors le client extraira à nouveau les dernières données ».

Cette astuce est souvent efficace à court terme car elle actualise certaines des anciennes données SSR. Mais à long terme, le problème peut facilement passer de “le premier écran est parfois un peu vieux” à “la page entière est en compétition pour les droits d’interprétation finaux”.

Le lien défaillant le plus courant est le suivant :

1. Le serveur prend d’abord les données de la version A et affiche le premier écran ;
2. Une fois le navigateur monté, le client extrait automatiquement la version B ;
3. L’utilisateur a immédiatement cliqué sur la collection et la mise à jour optimiste locale est devenue C ;
4. La version B demande un retour tardif et repousse C ;
5. Revenez à l’interface de collecte et la page revient à D.

Techniquement, chaque étape est « bonne ».

Mais pour les utilisateurs, la page a changé de réponse quatre fois en trois secondes. A ce stade, il est difficile de dire si le cœur du problème est la SSR ou la RSE, car le vrai problème est le suivant : **La page ne précise pas quelle priorité doit être donnée à l’écriture interactive ou au rafraîchissement complet. **

Contre-exemple : toutes les pages ne sont pas dignes du SSR ou du streaming

Il existe également un malentendu bien réel, qui consiste à considérer la stratégie de rendu comme une liste de capacités de la plateforme.

Si le framework prend en charge le SSR, il s’agit généralement d’un SSR à l’échelle du site ; Prend en charge le rendu en streaming et commence à supprimer les blocs ; Si le référencement vous inquiète, utilisez par défaut le côté serveur pour toutes les pages de détails ; Si la lenteur vous inquiète, ajoutez une autre couche de cache client.

Finalement, les coûts d’interprétation du système ont grimpé en flèche.

Certaines pages ne valent tout simplement pas des stratégies de rendu complexes :

• Pages backend avec un statut de connexion fort, une forte personnalisation et une faible valeur pour les moteurs de recherche ;
• Une page de transaction dont les données en temps réel sont bien supérieures à la valeur d’un premier écran statique ;
• Une page d’opération avec peu de contenu sur le premier écran mais beaucoup d’interactions.

Si SSR est installé sur de telles pages, et qu’ensuite une extraction supplémentaire et un streaming partiel côté client sont ajoutés, les avantages ne sont souvent pas aussi bons que l’écriture honnête des données sous CSR.

Au contraire, les pages de détails basées sur le contenu, les pages de destination publiques et les pages d’informations avec une structure stable sont plus adaptées pour tirer le meilleur parti des revenus SSR ou streaming. Le principe est toujours de savoir si les limites des données de la page peuvent être clairement séparées**.

Pour choisir une méthode, regardez d’abord trois choses

Si vous voulez vraiment faire un jugement entre SSR, CSR et le rendu en streaming, je vous recommande de lire d’abord ces trois choses au lieu de lire d’abord la page promotionnelle du framework.

Tout d’abord, vérifiez si le contenu du premier écran a une vraie valeur stable.

Si la plupart du contenu du premier écran peut être obtenu côté serveur et que la différence de mode utilisateur est faible, SSR sera plus stable.

Si le premier écran dépend fortement de l’état de connexion, de l’état de l’appareil et de l’état en temps réel, et que le serveur n’obtient qu’une valeur approximative qui expire rapidement, alors les revenus SSR seront réduits car le client devra bientôt les recalculer.

Deuxièmement, vérifiez si la page permet une explication par lots

Si la page peut naturellement être accessible par blocs, comme le texte en premier, les commentaires en dernier et les recommandations en dernier, le rendu en streaming est plus précieux.

Si plusieurs blocs de la page partagent une grande quantité d’état et que l’arrivée tardive de l’un d’eux bouleverse les deux précédents, alors le rendu en streaming apportera non seulement une optimisation des performances, mais également des coûts de coordination de l’état.

Troisièmement, vérifiez si l’écriture interactive entre en conflit avec le chemin d’actualisation.

Tant qu’il y a des actions telles que des collections, des paniers d’achat, des formulaires et des changements d’autorisation sur la page qui changeront immédiatement le statut, il est nécessaire de se concentrer sur la question de savoir si le chemin d’écriture interactif et le chemin d’actualisation de la page se couvriront mutuellement.

Ce problème n’est pas résolu, quelle que soit la stratégie de rendu que vous choisissez, elle fera simplement des erreurs d’une autre manière.

Limites applicables

Cet article traite principalement :- Rechercher simultanément le référencement, une vitesse supérieure à la ligne de flottaison et des pages Web personnalisées ;

• La même page a à la fois un premier rendu côté serveur, un rendu supplémentaire côté client et des blocs asynchrones locaux ;
• Problèmes d’hydratation, de mise en cache et d’assemblage de streaming qui sont naturellement rencontrés lors de l’utilisation de frameworks frontaux modernes.

Si la page est très simple, qu’il s’agisse d’un affichage de contenu pur ou d’une opération en arrière-plan pure, la complexité de la stratégie de rendu ne sera pas si élevée. Le problème le plus susceptible de survenir est la page qui “ressemble à une simple page de détails, mais qui transporte en réalité à la fois la distribution de contenu, la conversion commerciale et l’interaction de l’utilisateur”.

Résumé

SSR, CSR et le rendu en streaming ne sont pas faux. Ce qui ne va pas, c’est de les considérer comme de purs commutateurs de performances.

Une fois qu’une page a à la fois des exigences de premier écran, des exigences de mise en cache et des exigences d’interaction, ce qui devient vraiment incontrôlable en premier est la version des données qui est prise en compte, qui sera responsable de l’échec et qui a la priorité dans les chemins d’écriture et d’actualisation interactifs.

Par conséquent, ce que la stratégie de rendu frontal devrait vraiment déterminer en premier est combien de fois cette page de données sera-t-elle générée, combien de fois sera-t-elle écrasée, combien de fois ne parviendra-t-elle pas à retomber et quelle couche la fermera finalement.

Cette question n’est pas claire. Plus le schéma de rendu est avancé, plus il semble que la page soit écrite simultanément par de nombreux ensembles de mécanismes raisonnables.