Warum hosten große Websites ihre Bilder / CSS auf externen Domains?

Warum hosten Websites wie Facebook, Twitter und Google ihre Bilder und CSS auf externen Domains wie:

• Facebook: static.ak.fbcdn.net
• Twitter: a0.twimg.com
• Google: ssl.gstatic.com

Fragen):

• Ist es Leistung? oder Sicherheit?

@toomanyairmiles ist teilweise korrekt - der Zweck dieser Technik besteht darin, parallele Verbindungen vom Webbrowser zum Server zu ermöglichen. Webbrowser sollten mindestens zwei gleichzeitige Verbindungen zu einem einzelnen Host zulassen , aber viele neue Browser können bis zu 60 verwalten. Unabhängig davon ist die gleichzeitige Verbindung zwischen Browser und Webserver ein großer Geschwindigkeitsengpass.

Aus der Google-Ressource :

Die HTTP 1.1-Spezifikation (Abschnitt 8.1.4) besagt, dass Browser maximal zwei gleichzeitige Verbindungen pro Hostname zulassen sollten (neuere Browser bieten jedoch mehr als das: Eine Liste finden Sie unter Browserscope). Wenn ein HTML-Dokument Verweise auf mehr Ressourcen enthält (z. B. CSS, JavaScript, Bilder usw.) als auf einem Host maximal zulässig, fordert der Browser diese Anzahl von Ressourcen an und stellt den Rest in eine Warteschlange. Sobald einige der Anforderungen abgeschlossen sind, gibt der Browser Anforderungen für die nächste Anzahl von Ressourcen in der Warteschlange aus. Der Vorgang wird wiederholt, bis alle Ressourcen heruntergeladen wurden. Mit anderen Worten, wenn eine Seite auf mehr als X externe Ressourcen von einem einzelnen Host verweist, wobei X die maximal zulässige Anzahl von Verbindungen pro Host ist, muss der Browser diese nacheinander X auf einmal herunterladen, wobei für jede X-Ressource 1 RTT anfällt. Die gesamte Umlaufzeit beträgt N / X, wobei N die Anzahl der Ressourcen ist, die von einem Host abgerufen werden sollen. Wenn ein Browser beispielsweise 4 gleichzeitige Verbindungen pro Hostname zulässt und eine Seite auf 100 Ressourcen in derselben Domäne verweist, fallen 1 RTT pro 4 Ressourcen und eine Gesamtdownloadzeit von 25 RTTs an.

Um dies zu umgehen, müssen die Anforderungen entweder an verschiedene Domänen oder Hosts gesendet werden:

Aus derselben Google-Ressource:

Verteilen Sie parallelisierbare Ressourcen auf mehrere Hostnamen. Anforderungen für die meisten statischen Ressourcen, einschließlich Bildern, CSS und anderen binären Objekten, können parallelisiert werden. Verteilen Sie Anforderungen auf alle diese Objekte so weit wie möglich über die Hostnamen hinweg. Wenn dies als Faustregel nicht möglich ist, stellen Sie sicher, dass kein Host mehr als 50% mehr als der Durchschnitt aller Hosts bedient. Wenn Sie beispielsweise über 40 Ressourcen und 4 Hosts verfügen, sollte jeder Host im Idealfall 10 Ressourcen bereitstellen. Im schlimmsten Fall sollte kein Host mehr als 15 Hosts bedienen. Wenn Sie 100 Ressourcen und 4 Hosts haben, sollte jeder Host 25 Ressourcen bedienen. Kein Host sollte mehr als 38 bedienen.

Aber es gibt noch ein weiteres Teil des Puzzles. Jede Anfrage hat normalerweise ihre eigenen Gemeinkosten, normalerweise in Form von Cookies. Bei statischen Elementen wie Bildern, CSS und JavaScript müssen keine Cookie-Daten übertragen werden. Daher kann das Bereitstellen dieser Daten aus (untergeordneten) Domänen ohne Cookies zu schnelleren Round Trips führen:

Statische Inhalte wie Bilder, JS- und CSS-Dateien müssen nicht von Cookies begleitet werden, da keine Benutzerinteraktion mit diesen Ressourcen stattfindet. Sie können die Anforderungslatenz verringern, indem Sie statische Ressourcen von einer Domain bereitstellen, die keine Cookies bereitstellt. Diese Technik ist besonders nützlich für Seiten, die auf große Volumina selten zwischengespeicherter statischer Inhalte verweisen, z. B. auf häufig wechselnde Bildminiaturen oder auf Bildarchive, auf die nur selten zugegriffen wird. Wir empfehlen diese Technik für alle Seiten, auf denen mehr als 5 statische Ressourcen bereitgestellt werden. (Für Seiten, auf denen weniger Ressourcen bereitgestellt werden, sind die Kosten für die Einrichtung einer zusätzlichen Domain nicht wert.)

Registrieren Sie einen neuen Domainnamen und konfigurieren Sie Ihre DNS-Datenbank mit einem CNAME-Eintrag, der die neue Domain auf Ihren vorhandenen Domain-A-Eintrag verweist, um eine cookielose Domain für die Bereitstellung statischer Inhalte zu reservieren. Konfigurieren Sie Ihren Webserver so, dass statische Ressourcen aus der neuen Domäne bereitgestellt werden, und lassen Sie zu, dass in dieser Domäne keine Cookies gesetzt werden. Verweisen Sie auf Ihren Webseiten auf den Domänennamen in den URLs für die statischen Ressourcen.

In der Vergangenheit konnten Webbrowser nur zwei Elemente gleichzeitig herunterladen (jetzt 6 oder mehr), sodass das Herunterladen von Ressourcen aus verschiedenen Domänen schneller ist als das Herunterladen einer einzelnen Domäne. Dies gilt für alles von Bildern bis zu Javascripten.

Viele Unternehmen verwenden auch ein CDN , ein Tool, mit dem sichergestellt wird, dass der Endbenutzer seine Daten von einem Server erhält, der sich in seiner Nähe befindet. Dadurch wird auch die Leistung der Site erhöht, indem die Roundtrip-Zeit für Ressourcenanforderungen verkürzt wird.

Große Websites verschieben ihren statischen Inhalt (Bilder, JS- und CSS-Dateien) in ein Content Delivery Network oder CDN, da die Bereitstellung Ihres Inhalts auf mehreren, geografisch verteilten Servern das Laden Ihrer Seiten aus Benutzersicht beschleunigt .

Da der CDN einen anderen Domainnamen hat, bietet er auch Vorteile beim Domain-Sharding .

Die 2-Artikel-Beschränkung ist kein Thema mehr. Obwohl dies eine Empfehlung der HTTP-Spezifikation ist, erlauben alle modernen Browser mindestens 6 gleichzeitige Verbindungen .

Dies wird weiterhin für unerwünschte Cookies benötigt, die während der Verwendung eines externen Domainnamens an den Header gesendet werden. Es sind keine Cookies festgelegt, sodass das Laden von Inhalten viel schneller erfolgt.

Also ja, es wird immer noch für Geschwindigkeitszwecke benötigt.