Vor- und Nachteile von gehosteten Skripten [geschlossen]

Ich habe gesehen, dass einige Entwickler gehostete Skripte verwenden, um ihre Bibliotheken zu verknüpfen.

cdn.jquerytools.org ist ein Beispiel.

Ich habe auch Leute gesehen, die sich darüber beklagten, dass ein gehosteter Skriptlink gekapert wurde.

Wie sicher ist die Verwendung von gehosteten Skripten in der Realität? Werden die Skripte automatisch aktualisiert? Wenn zum Beispiel jQuery 5 auf 6 wechselt, erhalte ich automatisch Version 6 oder muss ich meinen Link aktualisieren?

Ich sehe auch, dass Google einen großen Satz dieser Skripte für das Hosting eingerichtet hat.

Was sind die Vor- und Nachteile?

Vorteile

• Ihre Skripte werden schneller geladen . Wenn Sie über eine Fülle von Ressourcen verfügen, die von einer einzelnen Domain geladen werden müssen, besteht in der Regel ein Engpass in Ihrem Browser, sodass Sie nur eine Handvoll paralleler Anforderungen an denselben Host haben. Wenn Sie also 16 separate Skripte, mehrere Bilder und mehrere CSS-Dokumente laden, wird eine Warteschlange eingerichtet, da jede Ressource darauf wartet, dass sie geladen wird. (Sehen Sie sich unbedingt die Verkettung Ihrer CSS- und Javascript-Dateien an - das Laden von nur zwei Skriptressourcen ist bedeutend schneller).
• Wenn Sie diese Ressourcen in eine separate Domäne auslagern, kann Ihr Browser jedoch problemlos zusätzliche Verbindungen zu diesem Server herstellen. Dies bedeutet, dass mehr Ressourcen gleichzeitig geladen werden, was zu einer schnelleren Seitenausführung führt. Sie lassen auch einen anderen Server einen Teil Ihrer Seite laden, was gut für Ihren Server ist, der wahrscheinlich so wie er ist an mehreren Skriptausführungsanforderungen arbeitet.
• Darüber hinaus sind diese CDN-Server (Content Devivery Networks) für den Betrieb als CDNs konfiguriert. Sie sind in der Regel ohne Cookies (für kleinere Paketgrößen) und mit einem extrem leichten Server ausgestattet, der sich ausschließlich mit dem Bereitstellen von Ressourcen und dem Zwischenspeichern häufig verwendeter Ressourcen befasst, und nicht so sehr mit dem alltäglichen Heben von Ressourcen, wie es ein Moorstandard ist Der Apache-Server wird ausgeführt.
• Die Verwendung eines CDN wie Google oder Akami hat auch andere Vorteile: Google verfügt über Server auf der ganzen Welt und seine Routing-Systeme sind intelligent genug, um eine Anforderung für eine Ressource mit der nächsten vorhandenen geografischen Kopie zu koppeln. Ihr Server versucht möglicherweise, jQuery.js an Vladimir in Russland zu liefern. Google verfügt wahrscheinlich über dieselbe Ressource wie Vladimir, wodurch die Latenz verringert wird.
• Da auf so vielen Websites diese CDNs bereits verwendet werden, besteht eine hohe Wahrscheinlichkeit, dass die von Ihnen bereitgestellte Ressource bereits vom Benutzer zwischengespeichert wurde. jQuery.js von Ihrem Server und jQuery.js von Googles Server werden nicht als dieselbe Datei behandelt, unabhängig davon, ob sie exakt gleich sind. Wenn Sie von Google laden, kann die zwischengespeicherte Kopie der vorherigen Site verwendet werden der benutzer besucht.
• Die Dateien selbst ändern sich nicht, insbesondere bei Skriptressourcen wie Javascript-Frameworks. Wenn eine neue Version herauskommt, wird Google weiterhin die alte Version hosten (egal wie abscheulich die Fehler sind), damit das CDN weiterhin normal funktioniert und keine schlechten Anfragen bearbeitet. Aus diesem Grund wird jeder CDN-Datei die entsprechende Versionsnummer hinzugefügt.

Nachteile

1. Es besteht die Möglichkeit, dass Ihr CDN nicht verfügbar ist. Wahrscheinlich sind die Chancen jedoch geringer, als dass Ihre Website ausfällt. Größere CDNs wie Google und Akami verfügen über mehrere Failover-Ebenen.
2. Das Erstellen einer neuen Verbindung lohnt sich möglicherweise nicht, wenn Sie nur eine oder zwei Ressourcen von Ihrem eigenen Server laden müssen.
3. Sie haben keinerlei Kontrolle über die bereitgestellte Datei. Daher ist es nicht möglich, Ihre benutzerdefinierte Version von jQuery oder eine andere Version zu verwenden, die Sie laden möchten, es sei denn, Sie zahlen für Ihr eigenes CDN.

Sicherheit

Ich würde diesen El Stack-Beitrag plus eine gute Menge an Googeln des Themas empfehlen. Jedes CDN wird anders sein, obwohl ich in aller Kürze denke, dass dies ein kleines Problem wäre.

Was niemand erwähnte, ist eine weitere Tracking-Option für Google. Sie bieten nicht alle diese Dienste ohne Grund kostenlos an. AdSense und Analytics sind völlig ausreichend und können zumindest gefiltert werden. Das ist ein großer Nachteil in meinem Buch.

Vorteile:

• Sie müssen nicht für die Bandbreite im Zusammenhang mit der Bereitstellung der Dateien und im Allgemeinen bezahlen

Nachteile:

• Sie unterliegen der Verfügbarkeit des von Ihnen verwendeten Hosting-Anbieters (wenn sie aus irgendeinem Grund ausfallen, fallen Sie auch aus).
• Sie haben zu jeder Version der Skripte gezwungen, über die die Hosting-Anbieter verfügen

Die Verwendung eines CDN bietet weitere Vorteile, bezieht sich jedoch nicht direkt auf die Verwendung eines dritten Skript-Hosting-Dienstes.

Nach den bewährten Methoden besteht der übliche Ansatz zur Optimierung des Seitenladens darin, alle Ihre JS-Ressourcen zu bündeln, da die Anzahl der Verbindungen zu einer einzelnen Domäne, wie von Jarrod erwähnt, begrenzt ist, und in der Antwort einen Header für eine ferne Zukunft festzulegen.

Was CDNs zu einer solchen Mischung beitragen, insbesondere die populären, ist, wie Jarrod ebenfalls betonte, dass der Benutzer bereits zuvor auf die URL zugegriffen hätte und die JS-Ressource sofort aus dem Cache seines Clients abrufen kann, ohne dass eine Verbindung hergestellt werden muss.

Wenn wir alle CDNs verwenden und Best Practices anwenden, können wir dem Benutzer das Abrufen zusätzlicher ~ 10-50 KB ersparen, wenn er zum ersten Mal auf unsere URLs zugreift, und ihm ermöglichen, ihre Seiten schneller zu laden.

Ich würde die Verwendung von CDNs aus zwei Gründen dringend empfehlen : Die genannten Nachteile von Jarrod sind zwar vorhanden, aber völlig unbedeutend. Wenn Sie Ihre Quellen bereits in einem einzigen Dokument bündeln, werden Sie alle dazu zwingen, beispielsweise den statischen jQuery-Teil von abzurufen das Dokument (~ 33 KB) jedes Mal, wenn Sie eine der gebündelten Ressourcen aktualisieren.

Ich weiß nicht, wie wichtig das für Sie klingt, aber bei einer großen Anzahl von Nutzern führt dies zu einer erheblichen Reduzierung der Bandbreite und erheblichen Einsparungen, von denen wir auf dringendere Dinge wie das Streamen von Pornos und das Kaufen von Bier umsteigen können.

Tu es nicht

Persönlich würde ich mich nicht auf Skripte von Drittanbietern verlassen. Wenn Sie Skripte anderer Leute einsetzen, sind Sie ihrer Gnade ausgeliefert. Es gibt verschiedene Dinge zu beachten:

1. Wenn ihre Website ausfällt, tritt möglicherweise eine Zeitüberschreitung oder ein Fehler auf.
2. Wenn sie ihr Geschäft aufgeben und das Hosting ausschalten, haben Sie all diese Funktionen verloren
3. Wenn sie gehackt werden, können Sie auch gehackt werden.
4. Cross-Site-Scripting kann mit SSL-Zertifikaten verheerende Folgen haben
5. Die Ladezeiten von Seiten können sich dramatisch erhöhen
6. Wenn sich die Oberfläche ändert, müssen Sie alle Funktionsaufrufe ändern

Es ist sicherer, den Code auf Ihrer eigenen Site zu hosten. Vertrauen Sie mir. Sie müssen sich nur einmal verbrennen und 250 Websites, die Sie erstellt und gehostet haben, müssen sich lustig verhalten, weil Sie sich auf ein gehostetes Skript eines dritten Teils verlassen haben, das nicht mehr funktioniert.