Comparaison de vitesse - liens de chemin absolus et relatifs

Disons que je veux créer un lien vers un répertoire parent ( http://example.com/library/) à partir d'un sous-répertoire ( http://example.com/library/html/basics/).

Le lien vers le répertoire parent peut être:

href="../../"
href="https://webmasters.stackexchange.com/library/"
href="http://example.com/library/"

Y a-t-il une différence de vitesse basée sur la façon dont j'écris le lien? Je ne demande pas la vitesse de chargement du site Web, mais s'il y a une différence notable lors de la traversée vers le répertoire.

— Jakub Kliský
source

Pourquoi pensez-vous qu'il y aurait une différence dans la traversée des répertoires? En ce qui concerne le serveur, c'est juste un succès, l'utilisateur ne se déplacerait pas réellement d'un répertoire à l'autre - il demande simplement une autre ressource. Que quelqu'un se rend d' example.comabord et ensuite example.com/library/books/fiction/1984.htmlavec ou sans "traversée", tout le chemin ne devrait pas être pertinent. Et rappelez-vous que vous aurez plusieurs utilisateurs - l'un pourrait demander le répertoire de base, tandis qu'un autre est profondément imbriqué et le serveur ferait simplement le même travail.

— VLAZ

Les 3 de ces URL sont identiques en ce qui concerne la demande HTTP, donc en ce qui concerne le serveur, il n'y a pas de différence - le navigateur doit résoudre la demande http://example.com/library/dans les 3 cas, sinon ce n'est tout simplement pas valide.

— MrWhite

Une chose manquée jusqu'à présent est l'effet sur la maintenance du site. L'utilisation /library/présente les avantages suivants par rapport aux autres options: vous n'avez pas besoin de mettre à jour tous vos liens si vous changez de nom de domaine ou passez à SSL partout; si vous changez le nom du dossier, ou déplacez le dossier enfant, vous pouvez trouver et remplacer le chemin facilement, en déterminant ce qui doit changer de ../ .. etc.

— Zhaph - Ben Duguid

Réponses:

Effet pour le navigateur:

Bien que cela ressemble à un peu de travail pour le navigateur Web, mais techniquement, cela ne fait pas beaucoup de différence. Les navigateurs sont trop rapides pour gérer cette structure d'URL relative et appeler le serveur d'applications

Effet pour le serveur d'applications:

Aucun, car il doit renvoyer le fichier demandé (le lien relatif / absolu correspond finalement à un chemin Web)

Effet sur la taille de la page:

Oui, il y aurait une certaine réduction de taille (encore une fois pas quelque chose qui ferait une énorme différence dans les performances de votre page qui pourrait être atteint par quelque chose comme le codage de contenu gzip ou la réduction de la ressource)

Donc, je pense que techniquement, les URL absolues / relatives ne font pas beaucoup de différence sur la vitesse de la page / toute matrice pondérée .

Oui, cela fait une énorme différence dans la gestion de plusieurs environnements tels que dev, pp, prodpp, etc.

Exemple: sur votre développement local, vous pourriez avoir dev.example.com sur la pré-production que vous pourriez avoir: pp.example.com. .

Donc, dans ces scénarios, il serait relativement facile de gérer le code avec des URL relatives (bien que cela puisse également être géré par les paramètres d'environnement)

— abhinsit
source

Les chemins basés sur HTML / CSS seront toujours plus rapides pour la vitesse du serveur, c'est parce que le serveur a moins de code à envoyer. Les chemins relatifs au format HTML ou CSS sont traduits par le navigateur de l'utilisateur final et non par le serveur.

Donc, techniquement, c'est plus rapide pour le serveur et plus lent pour l'utilisateur final, mais l'utilisateur final ne remarquerait jamais la différence, car le traitement requis est inférieur à nano-secondes, donc les utilisateurs finaux sont beaucoup plus susceptibles de voir la différence par rapport à relatif car le serveur va pouvoir mieux les servir.

— Simon Hayter
source

"Les chemins relatifs HTML / CSS seront toujours plus rapides pour la vitesse du serveur, c'est parce que le serveur a moins de code à envoyer." Je n'y crois pas vraiment. Bien que cela http://example.com/category/cats.htmlsoit plus long que /category/cats.html, je ne vois pas que cela ait un impact suffisamment important sur les performances pour être pris en compte. Gzipper les données envoyées, qui prend des fractions de seconde, couvrirait déjà à la fois «l'inefficacité de la taille» et la «pénalité de vitesse» qu'il impose.

— VLAZ

J'ai dit techniquement plus vite ... et vous choisissez des cordes. même avec une compression en cache utilisant gzip, une page html avec absolu vs relatif sera légèrement plus grande (gz relatif vs gz absolu), donc techniquement ... l'utilisateur final doit décompiler ce gzip et résoudre le relatif, c'est plus lent pour l'utilisateur final ... mais c'est tellement minime que l'utilisateur final ne va pas le remarquer, encore une fois c'est un fait. Même avec des technologies côté serveur telles que GZIP, un fichier HTML compressé ou un fichier CSS utilisant des chemins relatifs vs absolus, relatif sera toujours plus petit dans un fichier compressé, encore une fois, essayez-le.

— Simon Hayter

Bien que la différence ne soit que de quelques octets ou de quelques ko sur des pages plus grandes, les économies pour un visiteur ne sont pas importantes, mais pour les millions d'utilisateurs, cela devient plus perceptible ... donc, techniquement plus rapide. Maintenant, si vous demandez si cela vaut la peine d'utiliser relatif vs absolu pour le site Web moyen avec seulement quelques centaines de visites par jour? la réponse est probablement non ... mais ce n'était pas la question posée.

— Simon Hayter

La performance, au mieux, sera négligeable. Il pourrait également être entièrement inexistant. Les serveurs sont généralement bons à une chose. C'est en leur nom - au service du contenu. Je ne pense pas que quelques octets ou un Ko seraient un problème. C'est juste du contenu, à la fin. Si la taille était un problème, le code HTML que nous écrivons serait très différent. Ce n'est pas le cas. La minification du contenu est purement pour la commodité de l'utilisateur au cas où leur bande passante est petite. Je suis convaincu que le traitement de la demande et la réponse sont là où se trouvent les performances, et non dans l'acte réel d'envoyer les données.

— VLAZ

"les chemins d'accès relatifs seront toujours plus rapides pour la vitesse du serveur" - mais l'OP dit, "je ne pose pas de question sur la vitesse de chargement du site Web" - qui est le seul endroit où le site pourrait être plus rapide. (Pour être honnête, je ne suis pas vraiment sûr de la "vitesse" dont parle l'OP?)

— MrWhite