Quelles sont les différences entre le chargement d’une page via un CDN et quels types de fournisseurs utilisez-vous ?
J’ai des temps de chargement beaucoup plus longs en utilisant un CDN. Est-ce que je fais quelque chose de mal ou y a-t-il quelque chose que j’ignore ? Peut-être devrais-je encore configurer certains paramètres que je ne connais pas ?
Le CDN sera plus lent tant qu’il n’aura pas mis en cache les ressources. Vous devrez peut-être attendre un certain temps avant d’effectuer des tests.
Eh bien, le premier indice… grâce à .
Un peu. Combien ? On parle de jours, de semaines ?
Devons-nous forcer une charge utile en HTTPS ou plutôt en HTTP ? Je demande car il y a des différences de chargement. De quoi dépend le fait que la page soit entièrement chargée ou qu’elle ressemble à ce que l’on aurait si le JavaScript original n’avait pas été chargé ?
Le délai dépendra de la façon dont les utilisateurs interagissent avec le site. Les ressources les plus téléchargées seront chargées dans le cache du CDN et seront plus rapides si vous êtes plus proche du serveur CDN que du serveur d’origine.
Si vous avez le centre de données à proximité et que le serveur CDN se trouve à 1000 km, il sera toujours plus lent. L’idée du CDN est de mieux servir un public géographiquement diversifié, et non d’améliorer les visites centralisées.
Mais parlons-nous d’une situation où nous ajoutons l’adresse CDN à notre fichier app.yml ou non ?
Et quelle est la raison d’utiliser un sous-domaine pour l’adresse CDN ? Autrement dit, pourquoi ne peut-elle pas être DISCOURSE_CDN_URL: //637763234.cdn-provider.com et doit-elle être discourse-cdn.example.com ??
Oui, je le sais, mais je teste avec différents outils de test provenant de nombreuses régions du monde. Et le CDN est toujours plus lent !
Parlez-vous du TTFB sur quel chemin exactement ?
Le TTFB pour une ressource statique (comme un fichier JS ou une image JPG téléchargée par un utilisateur) sera toujours rapide avec un CDN, car la latence des multiples PoP contribue à l’améliorer.
En revanche, comparer le TTFB des routes dynamiques n’a pas de sens, car notre DISCOURSE_CDN_URL ne les couvre pas de toute façon.
Ce que vous observez est simplement une variation normale. Le CDN n’aura aucun impact sur le temps de premier octet à la racine de votre instance Discourse ou sur toute autre route dynamique. Un CDN ne servira que les ressources statiques.
Et y a-t-il une différence si ces ressources (actifs statiques) sont conservées dans S3 ?
Non, il n’y en a pas. Le CDN mettra en cache ces ressources depuis S3 au besoin.
Il s’agit simplement d’une adresse esthétique, elle n’est absolument pas nécessaire.
J’espérais que le CDN accélérerait le chargement de la page, mais je suppose que l’impact sera négligeable.
Existent-il d’autres moyens bien plus efficaces pour accélérer le chargement de la page dans différentes régions du monde, autres que l’augmentation des ressources RAM et CPU ?
Le TTFB correspond au temps nécessaire au serveur de l’application pour envoyer une réponse 200. Vous ne pouvez pas l’améliorer en utilisant un CDN, car ce dernier ne diffuse que des ressources statiques.
Vous accélérerez le chargement de la page, mais pas le temps de réponse du premier octet (First Byte). Vous accélérerez le chargement des éléments multimédias (images, PDF, vidéos) et du JavaScript. Cela améliorera la réactivité du site, mais tout le contenu dynamique devra être chargé depuis le serveur central.
Ainsi, par exemple, les avatars des utilisateurs s’afficheront plus rapidement, mais pas les titres des sujets.
Puisque Discourse bloque le rendu en attendant le JavaScript et le CSS, vous rendrez toujours la page interactive plus rapidement en utilisant un CDN.
Ce type d’analyse demande un peu plus que de lancer aveuglément Lighthouse et WebPageTest, de choisir un résultat et de s’obséder à ce sujet.
Si votre priorité est d’avoir une page avec un meilleur score sur ces outils, je recommande d’utiliser un blog propulsé par des outils comme https://jekyllrb.com/.
Comment suis-je censé l’analyser alors ?
