Geschwindigkeitsvergleich - absolute und relative Pfadverknüpfungen

Angenommen, ich möchte http://example.com/library/aus einem Unterverzeichnis ( http://example.com/library/html/basics/) eine Verknüpfung zu einem übergeordneten Verzeichnis ( ) herstellen.

Der Link zum übergeordneten Verzeichnis kann sein:

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

Gibt es einen Geschwindigkeitsunterschied basierend darauf, wie ich den Link schreibe? Ich frage nicht nach der Ladegeschwindigkeit der Website, aber ob es beim Durchlaufen des Verzeichnisses einen merklichen Unterschied gibt.

— Jakub Kliský
quelle

Warum sollte es beim Durchlaufen der Verzeichnisse einen Unterschied geben? Was den Server angeht, es ist nur ein Hit, würde der Benutzer nicht wirklich sein „bewegen“ von einem Verzeichnis in ein anderes - sie sind nur eine andere Ressource anfordert. Ob jemand example.comzuerst und dann example.com/library/books/fiction/1984.htmlmit oder ohne "Durchqueren" geht, sollte irrelevant sein. Und denken Sie daran, dass Sie mehrere Benutzer haben - einer könnte das Basisverzeichnis anfordern, während ein anderer, ein tief verschachtelter, und der Server nur die gleiche Arbeit erledigen würden.

— VLAZ

Alle drei URLs sind identisch, wenn es um die HTTP-Anfrage geht. Für den Server besteht kein Unterschied. Der Browser muss die Anfrage http://example.com/library/in allen drei Fällen auflösen , da sie sonst einfach nicht gültig ist.

— MrWhite

Eine Sache, die bisher übersehen wurde, ist die Auswirkung auf die Pflege der Website. Die Verwendung /library/bietet gegenüber den anderen Optionen die folgenden Vorteile: Sie müssen nicht alle Links aktualisieren, wenn Sie Ihren Domain-Namen ändern oder überall auf SSL umsteigen. Wenn Sie den Ordnernamen ändern oder den untergeordneten Ordner verschieben, können Sie den Pfad leicht finden und ersetzen und herausfinden, was von ../ .. usw.

— geändert werden muss

Antworten:

Effekt für den Browser:

Dies scheint zwar ein bisschen Arbeit für den Webbrowser zu sein, macht aber technisch gesehen keinen großen Unterschied. Die Browser sind zu schnell, um diese relative URL-Struktur zu verarbeiten und den Anwendungsserver aufzurufen

Effekt für Anwendungsserver:

Keine, da die angeforderte Datei zurückgegeben werden muss (relativer / absoluter Link wird letztendlich einem Webpfad zugeordnet)

Auswirkung auf die Seitengröße:

Ja, es würde eine gewisse Größenreduzierung geben (auch hier würde dies keinen großen Unterschied für die Leistung Ihrer Seite bedeuten, der beispielsweise durch die Codierung von gzip oder die Minimierung von Ressourcen erreicht werden könnte).

Ich denke also, dass die absoluten / relativen URLs technisch keinen großen Unterschied in Bezug auf die Seitengeschwindigkeit / jede gewichtbare Matrix machen .

Ja, es macht einen großen Unterschied bei der Verwaltung mehrerer Umgebungen wie dev, pp, prodpp usw.

Beispiel: In Ihrer lokalen Entwicklung haben Sie möglicherweise dev.example.com in der Vorproduktion: pp.example.com. .

In diesen Szenarien wäre es also relativ einfach, Code mit relativen URLs zu verwalten (kann aber auch über die Umgebungseinstellungen verwaltet werden).

— abhinsit
quelle

Relativ auf HTML / CSS basierende Pfade sind für die Servergeschwindigkeit immer schneller. Dies liegt daran, dass der Server weniger Code zum Senden hat. Relative Pfade in HTML- oder CSS-Form werden vom Browser des Endbenutzers und nicht vom Server übersetzt.

Technisch gesehen ist es für den Server schneller und für den Endbenutzer langsamer, aber der Endbenutzer würde den Unterschied nie bemerken, da die erforderliche Verarbeitung weniger als Nano-Sekunden beträgt. Daher ist es für Endbenutzer weitaus wahrscheinlicher, den Unterschied zu erkennen relativ, weil der Server sie besser bedienen kann.

— Simon Hayter
quelle

"Auf HTML / CSS relativ basierende Pfade sind für die Servergeschwindigkeit immer schneller. Dies liegt daran, dass der Server weniger Code zum Senden hat." Das glaube ich nicht wirklich. Es http://example.com/category/cats.htmlist zwar länger als /category/cats.html, aber ich kann nicht sehen, dass dies einen ausreichenden Einfluss auf die Leistung hat, um überhaupt berücksichtigt zu werden. Das Komprimieren der gesendeten Daten, das Bruchteile einer Sekunde dauert, würde sowohl die "Größenineffizienz" als auch die damit verbundene "Geschwindigkeitsstrafe" abdecken.

— VLAZ

Ich habe technisch schneller gesagt ... und Sie wählen Saiten. Selbst bei der zwischengespeicherten Komprimierung mit gzip ist eine HTML-Seite mit absolutem vs relativ etwas größer (gz relativ vs gz absolut), daher muss der Endbenutzer dieses gzip technisch dekompilieren und das relative auflösen. Dies ist langsamer der Endbenutzer ... aber das ist so minimal, dass der Endbenutzer es nicht bemerken wird, wieder ist dies eine Tatsache. Selbst mit serverseitigen Technologien wie GZIP, einer komprimierten HTML-Datei oder einer CSS-Datei, die relative Pfade im Vergleich zu absoluten verwendet, ist relative in einer komprimierten Datei immer kleiner. Versuchen Sie es erneut.

— Simon Hayter

Während der Unterschied nur wenige Bytes oder wenige KB auf größeren Seiten betragen kann, sind die Einsparungen für einen Besucher nicht wesentlich, sondern bei den Millionen von Benutzern, die sich deutlicher bemerkbar machen ... daher technisch schneller. Wenn Sie sich fragen, ob es sich lohnt, für eine durchschnittliche Website mit nur wenigen hundert Besuchen pro Tag Relative oder Absolute zu verwenden? Die Antwort ist wahrscheinlich nein ... aber das war nicht die Frage, die gestellt wurde.

— Simon Hayter

Der Leistungseinbruch wird bestenfalls vernachlässigbar sein. Es könnte auch völlig nicht existieren. Server sind im Allgemeinen in einer Sache gut. Es ist in ihrem Namen - dient Inhalt. Ich denke nicht, dass wenige Bytes oder eine KB ein Problem wären. Am Ende ist es nur zufrieden. Wenn die Größe ein Problem wäre, würde der von uns geschriebene HTML-Code sehr unterschiedlich aussehen. Das ist nicht der Fall. Die Minimierung des Inhalts dient lediglich der Benutzerfreundlichkeit, falls die Bandbreite gering ist. Ich bin zuversichtlich, dass die Verarbeitung und Beantwortung der Anfrage dort erfolgt, wo die Leistung erbracht wird, und nicht beim eigentlichen Senden der Daten.

— VLAZ

"Relativ basierte Pfade sind für die Servergeschwindigkeit immer schneller" - aber das OP gibt an, "Ich frage nicht nach der Ladegeschwindigkeit der Website" - dies ist der einzige Ort, an dem die Website möglicherweise schneller sein könnte. (Um ehrlich zu sein, bin ich mir nicht sicher, von welcher "Geschwindigkeit" das OP spricht?)

— MrWhite