Die neue Umfrage ist online (in der Seitenleiste der eigentlichen Website, RSS-Leser) und lautet
Würden Sie lieber eine 200 KB große Datei auf einem großen CDN hosten oder eine 20 KB große Datei selbst hosten?
Dies erfordert eine kleine Erklärung. Nehmen wir an, die betreffende Datei ist jQuery UI. Auf Ihrer Website benötigen Sie sie nur für die Tabs-Funktionalität. Sie könnten eine Kopie davon von Googles CDN laden, so wie hier:
<script src="http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.14/jquery-ui.min.js"></script>Diese Datei ist buchstäblich 205 KB groß, da es die komplette jQuery UI Bibliothek ist. Aber sie liegt auf dem wahrscheinlich größten/schnellsten/meistgenutzten CDN (Content Delivery Network) der Welt. Viele Websites verwenden jQuery UI und beziehen es wahrscheinlich von dort, sodass die Wahrscheinlichkeit hoch ist, dass diese Datei bereits im Cache liegt, wenn ein Benutzer auf Ihre Website gelangt.
Oder Sie könnten eine benutzerdefinierte Kopie von jQuery UI herunterladen.
<script src="/js/jquery-ui-1.8.14.custom.min.js"></script>Diese Datei könnte nur 20 KB groß sein, da sie so zugeschnitten ist, dass sie nur das Nötigste enthält, um die Tabs-Funktionalität zu ermöglichen. Die Datei ist zehnmal kleiner, aber die Wahrscheinlichkeit, dass sie für einen Benutzer, der Ihre Website zum ersten Mal besucht, im Cache liegt, ist gleich null.
Wenn also alle anderen Dinge gleich sind, wofür entscheiden Sie sich?
Ich werde eine kleine Datei auf dem eigenen Server wählen. Der Besucher muss Inhalte von unserem eigenen Server laden. Das Laden einer 20 KB großen Datei vom selben Server mit der heutigen Internetverbindung wird sich in keiner Weise auswirken.
Du Idiot. Die Bandbreite der heutigen Internetverbindungen hat zugenommen, aber die Latenz hat überhaupt nicht Schritt gehalten. Der Unterschied zwischen dem Laden eines Assets aus dem lokalen Cache und dem Senden einer zusätzlichen HTTP-Anforderung ist eher eine Frage der Latenz als der Bandbreite. Die Verwendung eines CDN erhöht die Wahrscheinlichkeit, einen Cache-Treffer zu erzielen und die Datei überhaupt nicht herunterladen zu müssen.
Ich habe mich für CDN entschieden.
200 KB, die sich bereits im Cache des Benutzers befinden, schlagen jede HTTP-Anforderung, es ist mir egal, selbst wenn die Datei nur 1 Byte groß ist.
Das Hinzufügen eines CDN bringt eine zusätzliche DNS-Lookup-Zeit mit sich. :-(
DNS-Lookups werden jedoch auch zwischengespeichert, und die Wahrscheinlichkeit ist hoch, dass ajax.googleapis.com bereits zwischengespeichert ist.
Du verwendest DNS Manual Prefetching, oder? Oder?
James, ich glaube nicht, dass du das verstehst. Prefetching ist NICHT Caching.
Ich schlage vor, du liest ein oder zwei Bücher, bevor du Schlagworte wie ein idiotischer Personalberater zitierst.
Jon, ich glaube nicht, dass DU das verstehst.
Ich bezog mich auf den Kommentar "Das Hinzufügen eines CDN bringt eine zusätzliche DNS-Lookup-Zeit mit sich". Wenn du DNS Manual Prefetching verwendest, ruft es das DNS des CDN ab, wenn das HTML geladen wird, und wartet nicht auf die nachfolgenden JS-Aufrufe am Ende deiner Seite ... Wenn dann die JavaScript-Bibliothek schließlich angefordert wird, ist das DNS bereits im Browser zwischengespeichert ....
Wenn du wirklich glaubst, dass ich dachte, DNS Manual Prefetching würde tatsächlich das JavaScript zwischenspeichern, solltest du vielleicht deinen eigenen Rat befolgen.
Netter Versuch aber!
Ich wähle auch CDN, Cache gewinnt immer :D
Ich bevorzuge CDN mit Fallbacks für den Fall von Verfügbarkeitsproblemen.
Abgesehen von technischen/Sicherheitsproblemen frage ich mich, ob diese Bibliotheken eines Tages über den Browser selbst verfügbar sein könnten ... aber das könnte seine eigenen Fallstricke haben, wie z. B. veraltete Browser, die veraltete Bibliotheken verwenden usw. CDN ist derzeit die beste Option.
Das ist tatsächlich eine großartige Idee. Ich würde noch einen Schritt weiter gehen und sagen, dass der Browser die Bibliothek sowohl vorinstalliert haben sollte, in den 3 neuesten Versionen, als auch einen Auto-Update-Prozess haben sollte, der regelmäßig nach neuen Versionen des Frameworks sucht, es herunterlädt und die Datei für den Benutzer vorab in den Cache lädt.
Ja, in html5 boilerplate sieht man einen Aufruf des jQuery CDN mit einem lokalen Fallback
Ich wähle auch CDN und verwende dieselbe Methode.
Wenn es etwas anderes als document.write gäbe, um dies zu handhaben, wäre es eine gute Idee, aber der Grund, warum wir uns überhaupt davon distanziert haben, ist, dass es so ressourcenhungrig ist. document.write ist nie eine gute Idee; wir verwenden das Google CDN für die Geschwindigkeit und ein Fallback auf etwas, das so langsam ist, ist völlig kontraproduktiv.
Gute Idee ... übrigens, HTML5 Boilerplate enthält dies auch ... ich denke, es ist ein großartiges Tool
HTML5 Boilerplate ist ein Stück Scheiße.
Kann diese Technik so modifiziert werden, dass sie auf WordPress funktioniert?
Ich wähle CDN an erster Stelle, aber mit einem lokalen Fallback. Könnte das vielleicht eine weitere Option in der Umfrage sein?
Hier genauso. Vor ein paar Tagen habe ich eine Funktionserweiterung für WordPress eingereicht, um einen optionalen Parameter zu wp_register_script hinzuzufügen, um ein lokales Fallback zuzuweisen, wenn ein CDN-Skript geladen wird.
Alle Websites, die bestimmte CDN-Dienste nutzen, laden in meinem Land wie Schlamm, weil bestimmte IPs (zensiert) blockiert zu sein scheinen. Immer wenn ich auf eine Website stoße, die 5 Minuten oder länger zum Laden braucht (ohne CSS oder JS), weiß ich einfach, dass es ein CDN-Problem ist.
Ich glaube nicht, dass der eigentliche CDN-Dienst blockiert ist, sondern nur bestimmte IPs, die aus mir unbekannten Gründen damit verbunden sind. Und im Grunde ist das ärgerlich, aber es hat mich auch etwas gelehrt. Möchte ich, dass meine Besucher (die im Durchschnitt eine 2 Mbit ADSL-Verbindung nutzen) 2 Sekunden länger warten müssen, bis eine Datei geladen ist, oder das Risiko eingehen, dass meine Website aus irgendeinem Grund kaputt geht, weil ich keine Kontrolle über den Inhalt habe?
Deshalb lasse ich lieber alle Dateien auf meinem eigenen Server.
Absolut richtig.
Und ich hasse wirklich Websites, die von überall her ziehen. Ich verwende NoScript. Ich mag es, wenn alle Inhalte von einem Ort stammen.
Das ist schon seit einiger Zeit meine Denkweise. Ich mag die *Idee* von CDN, aber ich denke, es führt ein unnötiges Stabilitätsrisiko ein. Und ich weiß, dass jeder gerne denkt, dass Google unangreifbar ist, aber sie werden wahrscheinlich eines Tages erfolgreich gehackt. Wenn das passiert und jemand bösartigen Passwort-Hacking-Code in die verteilte Kopie von jQuery einschleust, geht die Bombe hoch.
CDN ist auch für mich, sie sind im Allgemeinen schneller für meine Zwecke und ermöglichen die Verwendung von immer aktuellen Releases, was immer schön ist, wenn man Software für die Öffentlichkeit freigibt.
Wenn Sie automatisch die aktuellste Version einer Bibliothek verwenden, müssen Sie sich beeilen, um Schritt zu halten, wenn die API aktualisiert wird. Ich würde es viel lieber vorziehen, die neueste Version zuerst in einer Entwicklungs-/QS-/Staging-Umgebung zu testen, bevor ich dem Wort des Entwicklungsteams zustimme, dass sie "abwärtskompatibel" ist.
Definitiv die 20 KB Datei.
CDN den ganzen Tag, jeden Tag... es spart mir Bandbreite und die Wahrscheinlichkeit ist hoch, dass es sowieso schon im Cache liegt.
Weniger Dateigröße – weniger Code für den Browser zum Parsen und Ausführen. Also wähle ich definitiv die lokale kleine Datei.
Aber die Größe spielt wirklich eine Rolle. Wenn der Unterschied 10-mal so groß ist, wie du sagst, dann lohnt es sich.
Ich stimme zu. Ich möchte keine unnötigen Bibliotheken, CSS, JS laden ... der Traffic ist kein Problem, aber Client-Speicher, Browser-Parsing ist wichtig.
Ich bevorzuge optimierten Code anstelle von "flexiblem" Code, der einen Haufen ungenutzten Code lädt.
Kleine lokale Datei, bisher.
Der Grund für die Entscheidung ist, dass die Wahrscheinlichkeit, dass die CDN-Datei zwischengespeichert wird, meiner Meinung nach sehr gering ist – die Standard-Browser-Cache-Größen sind WIRKLICH klein (50 MB in Firefox, automatisch in IE8 – aber schwankt zwischen 50-250 MB, 20 MB in Opera) – und das muss alle Youtube-SWFs, Bilder, CSS und oft auch HTML für alle Websites umfassen, die der Benutzer besucht. Wenn Sie also nicht dieselben Bibliotheken UND dasselbe CDN UND dieselbe Bibliotheksversion wie einige der wirklich beliebten Websites (z. B. Facebook, NYTimes) verwenden, ist die Wahrscheinlichkeit groß, dass die Datei nicht zwischengespeichert wird.
Ich hatte vor, Nachforschungen zu dieser Frage anzustellen ... Firefox hat einige Cache-Viewer-Plugins – man muss nur einen Blick (nachdem man die Erlaubnis eingeholt hat) in den Cache mehrerer _normaler_ Leute werfen (Ihre Mutter, Ihr Buchhalter, ein zufälliger Nicht-Geek-Typ in Starbucks usw.) und sehen, wie oft die CDN-Dateien dort vorhanden sind.
Aus offensichtlichen Gründen ist das CDN der bessere Weg. Der Benutzer wird höchstwahrscheinlich eine Verbesserung der Ladezeit feststellen und es nimmt die Last des Auslieferns dieser Datei von Ihrem lokalen Server. Win-Win.
Natürlich könnten die Recherchen mich auch einfach widerlegen :) Habe meinen Opera-Cache überprüft – der auf 400 MB eingestellt ist und über 20.000 Dateien enthält (die älteste wurde im August 2010 abgerufen) – ich habe alle Versionen von jQuery zwischengespeichert. Aber andererseits sind die Websites, die ich besuche, wahrscheinlich nicht dieselben wie mein Publikum, und ich habe die maximale Cache-Größe explizit festgelegt.
Ist Ihnen bewusst, wie hoch die Wahrscheinlichkeit ist, dass jQuery UI Version x.x.xx bereits im Cache liegt?
Hier sind die Variablen
Website, die jQuery verwendet
Website, die jQuery UI verwendet
Website, die jQuery UI x.x.xx verwendet
Website, die jQuery UI x.x.xx von einem CDN verwendet
Website, die jQuery UI x.x.xx von einem CDN verwendet, das Google ist
Ich behaupte, die Wahrscheinlichkeit ist hoch, dass 80 % Ihrer Benutzer beim Besuch Ihrer Website eine 200 KB große Datei herunterladen. Denken Sie außerdem daran, dass 200 KB JavaScript im Browserspeicher liegen und dadurch das gesamte Erlebnis "verlangsamen".
Ich wähle das 20 KB Skript auf einem kostenlosen CDN, und das sollten Sie auch tun.
Ich stimme Frederico zu. Auch wenn jQuery beliebt ist, ist jQuery UI weniger beliebt. Wenn Sie glauben, dass die Statistiken zur Nutzung von jQuery UI annähernd so hoch sind wie die von jQuery selbst, werden Sie einen Schock erleben.
Die antwortenden Personen verstehen meiner Meinung nach die Frage nicht richtig. Sie antworten: Ich nehme Cache. Aber die Frage handelt genauer von Risikominderung
1. Der Benutzer hat jQuery UI möglicherweise zwischengespeichert, möglicherweise aber auch nicht. Ist Ihnen das Risiko für den größeren potenziellen Download wert?
2. Der Benutzer wird Ihre benutzerdefinierte Version beim ersten Besuch fast sicher nicht haben. Aber er wird auch einen viel kleineren Download haben. Bevorzugen Sie dieses Risiko?
Ich wähle #2, bis die Statistiken zeigen, dass Besucher der Website, die ich erstelle, eine hohe Wahrscheinlichkeit haben, dass jQuery UI zwischengespeichert wird. Ich müsste zuerst die Statistiken sehen, die besagen, dass eine Wahrscheinlichkeit von 80-90 % besteht, dass sie jQuery UI von der Website, von der ich es bereitstelle, zwischengespeichert haben. Dann werde ich meine Meinung ändern.
Ich stimme Greg und Federico vollkommen zu, die Wahrscheinlichkeit, eine 200 KB große, spezifische Version einer Datei von Google CDN zu laden, ist für den Besucher höher, also würde ich mich für die 20 KB Datei entscheiden, über die ich auch die Kontrolle habe.
Hier sind auch einige Statistiken über die Popularität von jQuery vs. jQuery UI
http://trends.builtwith.com/javascript
Ich stimme der 20 KB Datei zu. Um die Anfragen zu reduzieren, könnten Sie diese Datei zusätzlich mit all Ihren anderen JavaScript-Dateien zu einem "script"-Tag kombinieren, also einer einzigen Anfrage. Sie können ein Google-Tool namens "minify" verwenden, um dies zu tun, oder einfach Ihr eigenes erstellen (wie ich es getan habe, weil ich ASP verwende ... gäh)
Die Leute sagen "ohh Caching", aber es ist nur beim ersten Mal ein Problem. Also ein 20 KB Download und dann wird es jedes Mal zwischengespeichert, wenn der Benutzer Ihre Website besucht. Caching ist keine alleinige Eigenschaft von CDN.
jQuery sollte mit Browsern vorinstalliert (enthalten) sein.
Genau wie ein Beilagensalat, der zum Essen gehört.
Wäre es nicht unmöglich, das auf dem neuesten Stand zu halten?
Jedes Mal, wenn das Framework aktualisiert wird, müssen Sie Ihren Browser aktualisieren, und ich schätze, wir alle wissen, wie gut die Leute ihre Browser aktualisieren ... Nein danke, ich denke, ich würde es vorziehen, die zwischengespeicherte Version auf dem CDN zu verwenden. Wie andere sagten, ist die Wahrscheinlichkeit groß, dass die Leute bereits eine zwischengespeicherte Version des Frameworks zur Verfügung haben.
Die Versionsverwaltung ist handhabbar
jQuery in Browsern sollte separat vom Browser selbst aktualisiert werden, auf die gleiche Weise wie 'Adobe Flash', Sie müssen den Browser nicht aktualisieren, um eine neue Version von Flash zu erhalten.
JavaScript ist eine clientseitige Sache, oder?
Warum also nicht mit Browsern bündeln?
Denken Sie daran, dass ALLE Websites, die jQ verwenden, ständig aktualisiert werden müssten – einige Änderungen zwischen den Versionen sind ziemlich groß und erfordern ein kleines (aber wichtiges) Code-Update.
Sehen Sie sich jQ 1.4 (immer noch ziemlich beliebt) und jQ 1.6 an
Ich stimme zu, dass es standardmäßig enthalten sein sollte, da es Open Source und extrem beliebt ist, und was das ständige Aktualisieren Ihres Browsers angeht, sollte dies im Hintergrund geschehen, wie es Chrome derzeit tut.
Denken Sie daran, dass Google Chrome dies bereits mit Flash tut, es standardmäßig einschließt und still im Hintergrund aktualisiert.
Ich weiß, dass Chrome das sehr gut macht, aber wir leben nicht in einer idealen Welt, wir alle wissen, wie gut Internet Explorer auf den meisten PCs der Benutzer (ganz zu schweigen von großen Unternehmen) aktualisiert wird. Ein bestimmter Kunde von uns geht sogar noch weiter und blockiert viel eingehenden Traffic, was automatische Updates fast unmöglich macht, und ich bin mir ziemlich sicher, dass es mehr Unternehmen gibt, die das tun.
Außerdem denke ich darüber nach, wie das implementiert werden sollte. Das standardmäßige Laden würde dazu führen, dass sich andere Frameworks oder selbst geschriebener Code möglicherweise anders verhalten, als die Entwickler beabsichtigt haben.
Der X-Faktor ist, wie viele wiederkehrende Besucher ich auf meiner eigenen Website habe. In Anbetracht des TCP Slowstart-Algorithmus wird eine 20 KB große Datei in 3 Fenstern (3 + 5 + 7) Segmenten heruntergeladen. Das wird für die meisten Benutzer in einer angemessenen Zeit heruntergeladen.
Natürlich ist der Cache schneller, insbesondere wenn er von einer SSD abgerufen wird, aber angesichts der Tatsache, dass die größere Bibliothek langsamer geparst und ausgeführt wird und mehr Speicher verbraucht, würde ich mich für die 20 KB selbst gehostete Option auf jeder Website entscheiden, auf der Besucher bei etwa 50 Prozent aller Besuche als wiederkehrende Besucher erwartet werden können.
Die allgemeine Internetverbindung für Heimanwender hat in Holland eine Bandbreite von 8 Mbit/Sek. Das entspricht 1 MB für das gesamte Netzwerk zu Hause. Wenn man bedenkt, dass mindestens jemand Skype benutzt, jemand YouTube öffnet und man versucht, eine Website zu öffnen, kann man davon ausgehen, dass er oder sie nur noch 200 KB/Sek. Bandbreite übrig hat. Das macht die Wahl zu einer geografisch unterschiedlichen Entscheidung. Wenn mein Kunde in den USA lebt, würde ich definitiv die 200 KB Datei auf dem CDN wählen, aber da die meisten niederländischen Websites keine guten Webstandards befolgen, ist die Wahrscheinlichkeit ziemlich hoch, dass ich der erste bin, der ihnen den CDN-Link anbietet. Das verschafft mir einen vollen Nachteil von einer Sekunde Ladezeit. Das ist enorm!
Ich bin als Entwickler ziemlich selbstbewusst, daher neige ich oft dazu, die jQuery UI-Bibliotheken einfach neu zu schreiben, um sie "nativ" in mein anderes JS zu integrieren, und dann liefere ich einfach eine <20 KB Datei mit all meinem JS kombiniert. Es hängt wirklich von der Situation ab, aber das ist meistens die Art, wie wir arbeiten. /ich hasse die Bandbreitenprobleme.
*Chancen
Warum dort aufhören? Warum nicht weitere unnötige Skripte vom Google CDN hinzufügen, da sie zwischengespeichert werden? Steht YAGNI nicht für "You're always gonna need it"? ;)
Wenn Sie möchten, könnten Sie tun, was Yahoo vor Jahren getan hat, und einige echte Metriken darüber erhalten, wie viele Ihrer Besucher mit einem vollen Cache vs. einem leeren Cache-Erlebnis surfen.
Yahoo fand heraus, dass 40-60 % ihrer eigenen Benutzer einen leeren Cache hatten, und etwa 20 % aller Seitenaufrufe waren mit einem leeren Cache.
### Kommentar Ende
Sidebar
Persönlich ziehe ich es vor, meine Skripte prägnant zu halten und auf das zu reduzieren, was ich wirklich brauche, und eine einzige, kombinierte und minifizierte Datei zu liefern. Mir ist klar, dass die "Tabs"-Funktionalität hier nur ein Beispiel ist, aber es verwirrt mich, warum jemand jQueryUI nur für Tabs verwenden sollte, wenn sie einfach genug mit jQuery selbst oder – Gott bewahre – Vanilla JavaScript zu implementieren sind.
Wir haben eine Weile versucht, das Google CDN zu verwenden, aber in der Praxis war es langsamer. Die "theoretischen" Vorteile haben sich nie materialisiert, und dennoch werden Sie dies überall auf einer Liste der Best Practices und Empfehlungen sehen. Ich denke, es ist einfach gängige Meinung. Die Leute müssen Artikel über die Top 10 Dinge schreiben, die Sie jetzt tun können, weil es ihr Job ist. Aber sie verwenden nur Ideen aus anderen Artikeln wieder, die Ratschläge aus anderen Artikeln erhalten haben usw. Niemand misst es wirklich. Wir haben es getan, und es war langsamer. Wir bündeln jQuery mit unserem anderen standortspezifischen JavaScript in einem einzigen minifizierten Paket für die Bereitstellung.
Ich bin daran interessiert, wie Sie die Leistung von Google CDN gemessen haben. Haben Sie es lokal auf Ihren Maschinen oder über Analysen getestet?
Bei der Verwendung von CDN DÜRFEN Sie nicht vergessen, die VOLLSTÄNDIGE Version zu verwenden.
http://ajax.googleapis.com/ajax/libs/jqueryui/1.8/jquery-ui.min.js -> Zwischengespeichert 1h
http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.14/jquery-ui.min.js -> Cache 1 Jahr
Ich würde mich für das CDN entscheiden, nur weil es auf diese Weise möglicherweise bereits im Cache liegt, und selbst wenn nicht, was geht beim Laden verloren?... Tabs-Funktionalität. Ich glaube nicht, dass das das Ende der Welt bedeuten würde.
Ich würde CDN wählen, da das Web ein offenes Ökosystem ist und solche Entscheidungen dazu beitragen, dass es so bleibt. Und da Chris bereits einen sehr starken Vorteil der Verwendung von CDN zur Pflege von Bibliotheken erwähnt hat, warum eine lokale Kopie verwenden?
Es ist bemerkenswert, wie stark die Argumente für eine lokale Datei gegen eine CDN-Version sind, während die CDN-Liebhaber Argumente vorbringen, die sie höchstwahrscheinlich für selbstverständlich halten und die nicht gemessen werden. Sicher, es gibt einen Vorteil beim parallelen Herunterladen über mehrere Domains (ein Argument, das ich nicht entdeckt habe), aber Sie könnten das leicht nachahmen, indem Sie Ihre eigene, cookie-freie Subdomain verwenden (der cookie-freie Teil ist wirklich wichtig, da er die Anfrage drastisch verbessert).
Ich habe mich für 20 KB lokal entschieden, weil dies am besten für kleine bis mittlere Websites mit lokalem Charakter zu funktionieren scheint. Außerdem können Sie diese 20 KB mit dem Rest des JS auf Ihrer Website zu einer einzigen JS-Datei zusammenfassen.
Ich tendiere immer noch dazu, lokale JS-Bibliotheken anstelle der jQuery-Bibliothek von Google zu verwenden, die Hälfte der Zeit.
Lokal. Denken Sie an mobile Geräte! Für 200 KB zu bezahlen ist mehr als für 20 KB zu bezahlen. Und dasselbe gilt für das Warten, wenn Sie sich an einem Ort ohne 3G befinden.
Ich stimme für 20 KB lokal, aus Gründen, die Dominykas und Frederico bereits gut zusammengefasst haben.
In der realen Welt, wenn Sie jQuery verwenden, fügen Sie auch Ihren eigenen Code hinzu, und möglicherweise einige jQuery-Plugins obendrauf. In den meisten Fällen ist es besser, eine einzige JavaScript-Datei bereitzustellen, als jQuery separat und dann auch Ihre eigene Datei bereitzustellen.
Antwort C: Implementieren Sie Metriken und führen Sie A/B-Tests durch, um herauszufinden, welche die Datei schneller liefert.
Die Resource Timing-Metriken, die in Browsern implementiert werden, werden bei dieser Art von Dingen sehr hilfreich sein: http://w3c-test.org/webperf/specs/ResourceTiming/
A/B-Tests wären interessant, aber ich sehe keine sehr zwingenden Gründe, warum Sie nicht einfach AWS oder ein anderes CDN einrichten sollten, um die 20 KB Datei bereitzustellen. Es ist sehr billig und einfach, selbst wenn Sie Millionen von Besuchern bedienen.
Irgendwelche Nachteile dieser Logik?
Paul hat Recht.
Eric: Für manche Leute vielleicht Kosten? Es wäre jedoch so winzig (zumindest in Europa und Nordamerika), dass man wahrscheinlich die Mittel dafür finden könnte, indem man auf den Bürgersteig schaut und etwas Kleingeld findet, das jemand fallen gelassen hat.
Oder auch wenn es relativ einfach ist, die kleine technische Barriere, die manche Leute beim Einrichten einer solchen Sache wahrnehmen könnten?
Benutzer-Traffic und Benutzerstandorte sind wichtige Faktoren.
Hier ist eine Diskussion, auf die ich auf Stackoverflow gestoßen bin: http://bit.ly/iXWBqQ
"Wenn ein Benutzer eine bestimmte Anfrage stellt, wird der Server, der diesem Benutzer am nächsten ist (in Bezug auf die minimale Anzahl von Knoten zwischen dem Server und dem Benutzer), dynamisch bestimmt. Dies optimiert die Geschwindigkeit, mit der der Inhalt an diesen Benutzer geliefert wird." - aus der Stack-Diskussion
Ich kann sehen, wie der Standort des Benutzers wichtig sein kann, ob der CDN-Anbieter die Ladezeit tatsächlich verbessert; obwohl ich mir sicher bin, dass Google für jQuery-Anforderungen gut abgedeckt ist.
Nehmen wir das Beispiel von jquery ui, die Sache mit 200 KB vs. 20 KB ist ziemlich irrelevant, da sie realistischerweise in beiden Fällen gzip-komprimiert werden. Nach der gzip-Komprimierung sind es 51 KB vs. 7 KB.
7 KB sind nicht viel, um sie in Ihr anderes JS zu bündeln.
"Nehmen wir an, die betreffende Datei ist jQuery UI. Auf Ihrer Website benötigen Sie sie nur für die Tabs-Funktionalität."
its*
Ich frage mich, wie viele Leute mit diesem Dilemma kämpfen, aber dann Websites mit Flash, funky "Lametta" und allen möglichen anderen visuellen Schnörkeln erstellen?
Ich sage nicht, dass man solche Überlegungen ignorieren sollte, aber es gibt andere Möglichkeiten, mehr Bandbreite zu sparen und ein paar Anfragen zu sparen, wenn es wichtig ist.
Ich würde einfach ein CDN verwenden, weil es aktuell ist, wahrscheinlicher im Cache liegt und es eine Sache weniger ist, die ich hochladen muss.
Eine praktische Seite von mir mag die 180 KB nicht, die ungenutzt bleiben. Warum dem Benutzer geben, wenn er es nicht benutzt? Es erscheint fast ... unsinnvoll. Der große Faktor ist meiner Meinung nach mobile Netzwerke – 180 KB sind nicht nur ein Netzwerkhog; der Cache-Vorteil ist ebenfalls verschwunden. Bei einer wachsenden Nutzung mobiler Geräte im Web ist dies eine Überlegung wert. Zugegeben, diese Geräte werden schneller, aber ich bin mir ziemlich sicher, dass 180 KB immer noch ein bisschen von der Datenquote abknabbern werden. Außerdem stimme ich zu, dass nicht so viele Benutzer den Artikel im Cache haben, wie erwartet, und der geografische Geschwindigkeitsgewinn durch das CDN durch die Dateigröße aufgewogen wird. Wie bereits erwähnt, wird der Benutzer wahrscheinlich zurückkehren, was zu einer zwischengespeicherten, aber kleineren Datei führt. Ich gebe zu, dass, wenn die "kleine" Datei eine ausreichend große Zeitspanne zur Seitenladezeit hinzufügt, die Verzögerung potenzielle Benutzer abschrecken könnte. Andererseits blockieren Firewalls oder andere Filter oft CDNs – ein noch größeres Problem als die Ladelatenz. Letztendlich ist es eine szenariospezifische Frage, zumindest noch für ein paar Jahre. Persönlich würde ich lokal gehen.
Immer lokal, egal welche Größe.
Angesichts der Bandbreite meines billigen virtuellen Shared Hostings und der eines CDN werde ich das CDN nehmen. Selbst 20 KB sind nach meinen Maßstäben eine große Datei, wenn ich das Hosten vermeiden kann, würde ich es wahrscheinlich tun.
Ein großes CDN wird architektonisch besser sein als meine selbst gehostete Lösung und es ist wahrscheinlicher, dass es auch weniger Netzwerk-Hops gibt (wenn das Hosten direkt beim ISP heutzutage noch üblich ist – und ich gehe davon aus, dass die meisten Benutzer auch die DNS-Server ihres ISPs verwenden).
Es ist großartig, Zeit damit zu verbringen, Ihren eigenen Download zu erstellen, der nur das enthält, was Sie verwenden, solange Sie bereit sind, dies erneut zu tun, wenn Sie Ihre Website erweitern und feststellen, dass Sie weitere Funktionen einbinden müssen.
Es gibt viele Gründe, kein CDN zu verwenden, und die Größe ist nur eine Überlegung. Wer möchte sein Portfolio an Websites aktualisieren, wenn das CDN beschließt, einige alte Versionen zu entfernen oder den Dienst ganz einzustellen?
Normalerweise würde ich den CDN-Weg gehen, um Bandbreite zu sparen und Caching zu nutzen. Allerdings ist das Versprechen einer erhöhten Geschwindigkeit meiner Erfahrung nach weit von der Wahrheit entfernt, wenn die Ressource nicht zwischengespeichert wird.
Ich messe sehr oft HTTP und stelle fest, dass einige CDNs wirklich eine große Vielfalt an Antwortzeiten haben. Einmal testen und in wenigen Millisekunden erhalten. Erneut testen, um einen Spitzenwert von 600 ms zu sehen. Es ist keine Konstante, auf die man sich verlassen kann. Es variiert auch stark je nach Standort.
Nehmen wir an, es wäre eine ziemlich leichte persönliche Website – in diesem Fall wäre es kein Problem, die 200 KB (ein paar Millisekunden mehr) von einem CDN mit unsicheren Antwortlatenzen abzurufen, wenn man unter Googles Schwelle bleibt usw.
Aber wenn Sie mehr inhaltslastig sind, ein paar zusätzliche Besucher pro Monat haben, dann wäre das Trimmen von Bytes und das Kombinieren (vielleicht das Einrichten eines eigenen CDN) wirklich ein Problem, das viel Aufwand wert ist.
Ich (fast) immer beginne mit der Entwicklung mit so vielen CDNs wie möglich und lokalen Fallbacks (ständig messend). Und am Ende, wenn der Bedarf steigt, trimme und kombiniere ich entsprechend.
Die Antwort auf diese Umfrage hängt also mehr oder weniger davon ab, um welche Website es sich handelt und wie viel Sie sparen müssen, um unter die individuellen Schwellenwerte für Ladezeit und Anzahl der Anfragen usw. der Website zu gelangen.
Ich bevorzuge lokal,
z.B. binde ich Ext JS nicht nur für grundlegende DOM-Aktionen ein. Ich meine, warum sollte ich Bytes laden, die ich nie benutze?!
Ressourcen werden zwischengespeichert, aber warum ist das notwendig?
Auch die Verbindungsgeschwindigkeit ist in einigen Ländern immer noch begrenzt ....
Ich würde mich für das CDN entscheiden, aus dem einfachen Grund der Bandbreite. Wenn Sie eine massive Menge an Traffic erhalten, zählt jedes gesparte Kilobyte, und die Tatsache, dass es sehr wahrscheinlich zwischengespeichert wird, zusammen mit der Tatsache, dass Google das Skript bereitstellt, bedeutet, dass es keine merkliche Erhöhung der Ladezeit geben wird.
Aber, wie andere gesagt haben, es hängt wirklich von der Website und Ihrer Infrastruktur ab.
Ich würde sagen ... Hoste es selbst. 20 KB sind nichts im Vergleich zu den heutigen Internetgeschwindigkeiten. Darüber hinaus haben Menschen mit langsameren Internetverbindungen meist alte Browser, sodass die Verwendung eines CDN nur bedeuten würde, die große Datei zu erhalten, und außerdem kann man sich nicht immer auf den Cache verlassen.
Wenn Sie jedoch keine große Datei hosten müssen, lassen Sie Google die Arbeit für sich erledigen
Browser-Cache ist immer besser. Der Zweck einer Website ist es, sowohl neue als auch wiederkehrende Besucher anzuziehen.
Und Google wird die Geschwindigkeit überprüfen, ohne eine große (und gängige) Datei auf einem CDN zu berücksichtigen ...
Ich halte gerne alles lokal. Ich mag es einfach, die Kontrolle darüber zu haben, was mit meinen Sachen passiert.
Ich würde mich für eine lokale kleine Datei entscheiden.
Dies ist keine Argumentation über HTTP-Anfrage vs. Browser-Cache – es geht um kleine Datei in langsamerem Netzwerk vs. große Datei in schnellerem Netzwerk.
Ich würde niemals davon ausgehen, dass ein Benutzer meiner Website etwas zwischengespeichert hat. Wenn sie sehen, dass die Seite langsam lädt, ist es ihnen wahrscheinlich egal, ob es sich um ein CDN oder lokal handelt, bevor sie sich entscheiden, zu meinen Konkurrenten zu gehen.
Ich werde beides laden, nur für den Fall :P
Ich gehe immer den lokalen Dateipfad. Meine Benutzer sollten auf keinen Fall ein 200 KB Skript laden müssen, wenn ich eine 20 KB Version habe. Sie können nicht davon ausgehen, dass es bereits zwischengespeichert ist. Benutzer mit langsameren Internetverbindungen (ja, Dial-Up existiert immer noch für eine große Anzahl von Menschen) können nicht auf den Download eines 200 KB Skripts warten.
Außerdem ist es zuverlässiger, es selbst zu hosten. Ganz zu schweigen davon, dass es ein großes Sicherheitsrisiko ist, Skripte von anderen Websites auszuführen. Das öffnet Tür und Tor für die Ausnutzung Ihrer Website. Selbst wenn die Quelle vertrauenswürdig ist, ist es eine schlechte Idee, da sie selbst kompromittiert werden könnten.
Okay, ich bin so faul, dass ich CDN wähle: Hier ist der Grund
1. Um lokal zu gehen, muss ich jQuery herunterladen, auf meinen Server laden, Code für die lokale Referenzierung einfügen. Igitt!
2. Um CDN zu verwenden, fügen Sie den Google-Code ein und fertig. Zur Hölle mit dem Benutzer, das hat mir ungefähr 30 Sekunden gespart und DAS ist alles, was zählt.
Das ist letztendlich ein Kampf zwischen "Äpfeln" und "Birnen". Der Kontext ist hier König. Ist Ihre Website ein massives, bekanntes Portal zum Internet? Ist es ein kleiner Fisch in einem großen Teich. Erstreckt sich Ihr Inhalt über einen breiten Bereich von Benutzerbereichen, oder ist Ihr Inhalt eher eine Nischendomäne? Handelt es sich um ein Unternehmens-Intranet?
Die Antwort auf die Frage hat weniger damit zu tun, wie Sie Ihre Daten bereitstellen, als vielmehr damit, wem Sie Ihre Daten bereitstellen.
Ich wollte gerade CDN sagen, aber dann sah ich den Kommentar, dass man eine lokale Datei als Fallback verwenden soll. Für die Umfrage stimme ich für CDN, aber ich stimme zu, dass die Fallback-Option hier ein wichtiger Teil ist.
Tolle Diskussion, ich stimme Jeremy zu und danke an @Da_n für den Hinweis und an @Paul Irish für seine Antwort C, Chris hat wieder einmal den Nagel auf den Kopf getroffen!
Ich wähle die kleine Datei selbst gehostet, sie wird mit meinen anderen Skripten kombiniert, einige 20 KB mehr oder weniger spielen keine Rolle
20 KB lokale Datei. Haben wir die mobilen Benutzer vergessen? Werden sie wahrscheinlich eine 200 KB große JavaScript-Datei zwischengespeichert haben? Wie viele Leute verwenden das CDN? Wollen wir Benutzer bestrafen, die diese Datei nicht zwischengespeichert haben, und sie möglicherweise verlieren? Es gibt zu viele Unbekannte bei der CDN-Option.
Ich würde (& verwende) Googles CDN für jQuery, weil ich glaube, dass die Vorteile (Caching) die Nachteile (zusätzliche HTTP-Anfrage, wenn Sie mehrere JS-Dateien haben, da Sie jQuery nicht verketten können) in diesem Fall überwiegen (wo die Dateigröße gleich ist)
Ganz zu schweigen von der zusätzlichen Zeit, die der Client für das Parsen und Ausführen dieser MASSIVEN JS-Datei aufwendet. Es ist ein Kinderspiel.
Ich würde hoffen, dass kein verantwortungsbewusster Front-End-Entwickler jQuery UI auf einer Website verwenden würde. Es ist ein JavaScript-Framework für Webanwendungen (für die Faulen)
Du hast gute und wichtige Punkte in deinen Kommentaren, und dann ruinierst du es einfach, indem du so trolligen Scheiß sagst. Warum? Es ist in Ordnung, dass du jQuery UI nicht magst, aber es ist nicht in Ordnung, andere Programmierer als unverantwortlich zu bezeichnen und es nicht zu belegen.
Ich dachte nicht, dass es für den Artikel relevant wäre, näher darauf einzugehen. Aber da du gefragt hast...
jQuery UI ist einfach zu schwer, um für die meisten Websites geeignet zu sein, wenn eine viel angemessenere Lösung darin bestünde, eigene Plugins zu schreiben. Während die Menge an Optionen, die in jedem Modul von jQuery UI verfügbar sind, beeindruckend ist, bedeutet dies eine Menge Ballast, den Sie nicht verwenden, was zu zusätzlicher Dateigröße und zusätzlichem JS-Parsing führt.
Ein verantwortungsbewusster Front-End-Entwickler würde diese Dinge bei der Architektur des JavaScripts einer Website berücksichtigen, und ich würde hoffen, dass er zu der Lösung kommt, die für den Benutzer am besten ist (das JS schlank halten), anstatt zu der Lösung, die für ihn am besten ist (eine vorgefertigte Lösung verwenden, die mit einigen integrierten Optionen größtenteils das tun kann, was sie wollen).
Stimme Jayphen vollkommen zu.
Cool, das ist eine faire Meinung. Ich bin immer noch anderer Meinung, dass jQuery UI zu schwerfällig oder aufgebläht ist. Sie bieten benutzerdefinierte Downloads nur für die Module an, die Sie benötigen, und ich finde nicht, dass einzelne Module aufgebläht sind. Sie sind funktionsreich, was eine enorme Zeitersparnis sein kann, wenn plötzlich festgestellt wird, dass Sie irgendwo einen Callback benötigen und sie das bereits abgedeckt haben.
Ich habe für Orte gearbeitet, an denen das Schreiben eigener Plugins von Grund auf viel unverantwortlicher gewesen wäre als die Verwendung von etwas, das bereits existiert. Es hängt total von der Situation ab.
Entschuldigen Sie, wenn das vorher kurz angebunden war. Aber sehen Sie diese Leute? http://jqueryui.com/about Ich habe viele von ihnen getroffen und mit ihnen zusammengearbeitet, und sie sind wirklich schlau und arbeiten an allen Arten von Projekten und verwenden jQuery UI.
Chris, ich zolle dir und jedem jQueryUI DEV Tribut! Ihr seid großartig!!!
Der Punkt ist ... ein PRO "wird" (wir sagen, er sollte) seinen eigenen und benutzerdefinierten Code ohne eine einzige zusätzliche Zeile schreiben, also wird er offensichtlich lokal geladen. Das ist, wie ich das Wort "verantwortungsbewusst" von Jayphen lese. Mehr: manchmal sind wir faul!!! LOL
Natürlich! Viele "vorgefertigte" Lösungen sind wirklich gut – wie jQueryUI. Ich würde nicht dasselbe für jQuery Tools sagen (meiner Meinung nach WAR es gut, TERO hat großartige Arbeit geleistet und vielleicht wird ALIBBY helfen, den Code wiederherzustellen – ich wünsche ihnen das Beste).
Zurück zu deiner Umfrage ... diejenigen, die in der Lage sind, benutzerdefinierten Code zu schreiben, werden lokal laden. Dieselben können ein jQuery-Plugin (vorgefertigt) verwenden und meiner Meinung nach werden sie dasselbe lokal laden.
Mein Englisch ist nicht SO gut, aber ich denke, du hast verstanden, was ich meine. Hast du? :)
20 KB Datei für JavaScript, jedes bisschen Leistung hilft, und eine 20 KB Datei wird schneller ausgeführt und initialisiert als eine 200 KB Datei. Das kippt jede Download-Geschwindigkeitsskala, die ich verwenden würde, um diese Entscheidung abzuwägen.
20 KB lokal: Fast 99,99 % der Benutzer müssen von Ihrem eigenen Host herunterladen.
200 KB CDN: Die Wahrscheinlichkeit ist groß (80 % oder höher), dass es bereits auf dem Computer des Benutzers zwischengespeichert ist. Der Download von Google CDN ist auch kein großes Problem im Vergleich zu Ihrem eigenen Host.
In der Wahrscheinlichkeit gewinnt 200 KB CDN.
Erfinden von Statistiken, um einen Punkt zu "beweisen": 55 % wahrscheinlich, um einen Mangel an tatsächlicher Forschung zu signalisieren
90 % der Statistiken werden spontan erfunden. Die anderen 10 % werden nur falsch interpretiert.
Ich würde sicherstellen, dass far-future expiration headers gesetzt sind und eine vor-gzip-komprimierte Version auf meinem eigenen Server unter einer cookie-freien Subdomain speziell für statische Inhalte gehostet wird. Ich habe einmal wget auf meinem Dreamhost Shared Server verwendet und es erreichte Geschwindigkeiten von 8-9 MB/s (ich schätze also eine 100 Mbit/s-Verbindung, es sei denn, der andere Dienst hat es begrenzt). Natürlich ist das Download und nicht Upload, aber Upload erreicht leicht 2 MB/s, was wahrscheinlich so schnell ist, wie eine so kleine Datei vor dem Abschluss erreichen wird.
Jetzt haben wir festgestellt, dass Google CDN-Caching und -Geschwindigkeit mit unserem eigenen Server übereinstimmen und die Bandbreite heutzutage auf Hosting-Konten normalerweise ziemlich groß ist. Wir müssen uns nur überlegen, ob es bereits zwischengespeichert ist.
Google CDN: 0,8 s Ladezeit bei 2 Mbit/s Verbindung
Selbst gehostet: 0,08 s Ladezeit bei 2 Mbit/s Verbindung
Natürlich müssen Sie auch eine bestimmte Version verwenden, um Googles Caching-Vorteile zu erhalten. Wenn Sie konfigurieren, dass die neueste Version verwendet wird, sinkt Ihre Cache-Zeit auf etwa 1 Stunde. Ich denke, die Verwendung einer Hauptversion beträgt etwa 2 Tage Caching. Sie benötigen eine bestimmte Version, um den vollen Vorteil zu nutzen.
Im Cache von Chromium von 8.000 Elementen, der vor ein paar Tagen geleert wurde, habe ich
1.7 (keine Cache-Vorteile)
1.7.2 (alt, aber im Cache)
Ich habe andererseits etwa 6-8 verschiedene zwischengespeicherte Versionen von jQuery.
Selbst in Firefox mit 56.000 zwischengespeicherten Elementen habe ich: (984 MB)
1.8.2
1.8.3
1.8.6
Keine davon stimmt mit der oben genannten Version überein. Google CDN mag eine gute Wahl sein, wenn Sie eine sehr gängige Version verwenden oder eine, die schon länger existiert, aber in diesem Fall würde es fehlschlagen. Ich verwende manchmal jQuery 1.2.6, wenn ich Web-Apps erstelle, wenn ich keine neuen Funktionen benötige, da die alte Version viel kleiner ist und bereits in meinem Cache erscheint.
Dies berücksichtigt nicht große Unternehmen mit eingerichteten Caching-Servern (ein Squid-Proxy mit 10-100 GB Speicherplatz zum Zwischenspeichern von Assets), die ein ganzes Gebäude von Leuten bedienen. In diesem Fall ist die Wahrscheinlichkeit, dass die Google CDN-Version sofort einsatzbereit ist, signifikant höher. Insgesamt würde ich mich für die kleinere Datei mit richtig eingestelltem Caching und Komprimierung entscheiden.
Ich stimme der 20 KB Datei zu, die vom kostenlosen CDN gehostet wird, natürlich mit kugelsicherem Fallback. Könnten Sie nicht einfach die CDN-Basis-JQuery-Bibliothek verwenden, auf den ganzen unnötigen Ballast verzichten, den Sie möglicherweise nicht benötigen, und zwei Fliegen mit einer Klappe schlagen, oder den Stein bergab rollen lassen und kein Moos sammeln, welchen Spatz Sie auch immer aus einem Busch pflücken möchten (Entschuldigung für all die Klischees?
Ich werde eine kleine Datei auf meinem Server wählen, mit anderem JS zu einer Datei verkettet, dann minifiziert.
Ich bin ein großer Fan der Verwendung eines CDN, aber ich liebe mein lokales Fallback, einer der Gründe, warum ich HMTL5 Boilerplate liebe. Vielleicht liegt es nur an mir, aber es scheint, als ob auf kleiner Ebene der Vergleich der beiden wie Haarspalterei ist. Was jQuery UI betrifft, wenn Sie eine nicht-benutzerdefinierte Version verwenden, dann CDN auf ganzer Linie. Aber am Ende des Tages würde ich vorschlagen, das zu verwenden, was für das Projekt am besten funktioniert.
Am Ende des Tages weniger OCD und mehr Arbeit erledigen :P
Ich habe die Datei auf meinem Server gehostet, aber diese Umfrage hat mich dazu gebracht, mich für CDN zu entscheiden.
Beiträge wie dieser machen mir Sorgen über die Art der Fehlinformationen, die durch solche Umfragen verbreitet werden ...
Wenn die Mehrheit der anderen Entwickler das Falsche tut, macht das die Sache nicht richtig.
Zwei Menschen können genau dieselbe Sache betrachten und zwei völlig unterschiedliche Dinge sehen. Ganz zu schweigen davon, dass man die andere Seite der Medaille betrachtet. und ja, machen Sie sich keine Sorgen.
Meine Stimme: 20 KB Lokal.
Zunächst einmal ist es möglich, dass das exakte Skript, das Sie von Googles CDN laden, nicht zwischengespeichert wird. Laden alle die neueste jQuery-Datei vom CDN? Nein. 1.4.2 scheint tatsächlich eine ziemlich beliebte Version zu sein. Ich wette auch, dass nicht viele Websites jQuery UI verwenden, sodass das gesamte Caching-Argument schwer zu belegen ist.
Zweitens, solange Sie nicht vollständig darauf vertrauen, dass die Datei bereits zwischengespeichert wird (ich tue es nicht), bin ich mir ziemlich sicher, dass es effizienter ist, eine viel kleinere Datei zu laden. Es ist mir wirklich egal, wie schnell Googles CDN ist, Sie werden wahrscheinlich sowieso andere Skripte von Ihrer Website laden, sodass das Laden eines 20 KB Skripts nicht zu lange dauern sollte (insbesondere da moderne Browser sehr gut mit parallelem Laden umgehen).
Anstatt sich auf ein CDN zu verlassen, denke ich persönlich, dass Sie Ihre Website im Allgemeinen optimieren sollten. Verwenden Sie Subdomains oder eine ganz andere Domain, um statische Dateien zu laden. Und wenn Ihre Website groß ist, sollten Sie wahrscheinlich sowieso Ihr eigenes CDN verwenden.
werde mich für CDN entscheiden.
Ich muss hier hinzufügen: Niemand, absolut niemand hier hat das Thema Datenschutz in Bezug auf das Hosting auf einem CDN angesprochen, insbesondere auf Googles CDN. Referrer-Strings geben Google die Browsing-Muster jedes Besuchers, der das CDN verwendet. Wenn man das zu all den anderen von Google gehosteten Diensten hinzufügt, kann ich, soweit ich das beurteilen kann, kaum eine Website besuchen, ohne dass sie davon wissen.
Ich bin etwas überrascht, wie leicht viele Entwickler ihre Verkehrsdaten ohne mit der Wimper zu zucken abgeben.
Kostenlos ist nicht immer kostenlos.
20 KB lokal, immer.
+1
+1 mir auch.
Sehr gut gesagt. Das ist einer der Gründe, warum ich "lokal" sage, unabhängig von der Größe.
100% einverstanden. Es ist wirklich ein Problem, dass so viele Leute und vor allem Webentwickler die Daten ihrer Benutzer (und manchmal Kunden) an Facebook, Google usw. weitergeben.
Leider zerschießt man heutzutage viele Seiten, indem man diese Domains lokal blockiert, weil unaufdringliches JavaScript (unobtrusive javascript) sehr unbeliebt zu sein scheint.
Man sollte Google für die Nutzung ihres CDN zur Kasse bitten. Die Daten, die man ihnen gibt, sind mehr wert als diese 200kb.
Egal welche Größe, lokal. Immer.
Ich würde wahrscheinlich zuerst CDN wählen, dann würde ich nach einer Weile in ein anständiges selbst gehostetes Setup investieren, das eine nicht abgespeckte Version von jQuery oder anderer Software verwendet.
Ich würde auch CDN wählen, denn wenn Ihre Website ausgefallen ist und jemand Ihre Website über die zwischengespeicherte Google-Version ansieht, erhält er eine funktionierende Version anstelle einer beschnittenen reinen HTML-Ansicht ... deshalb würde ich auch alle CSS-Dateien und Bilder in Amazon CDN legen ...
Nachteil bei CDN: Wenn Sie HTTPS verwenden, erhalten Sie eine Sicherheitswarnung für teilweise unsichere Inhalte ...
Die meisten CDNs wie das von Google unterstützen HTTP und HTTPS. Schreiben Sie Ihr Skript-Tag so und der Browser ruft das richtige ab, je nachdem, welches Protokoll auf der aktuellen Seite verwendet wird
Reduzieren Sie die Anfragen an den Server, indem Sie Ihr JS minimieren und zu einer Datei zusammenfassen. Ihr Benutzer benötigt sowieso all Ihr Javascript, also holen Sie sich die komprimierte jQuery UI-Bibliothek, fassen Sie sie mit dem JS Ihrer Site zu einer Datei zusammen, was die Latenz aufgrund mehrerer Anfragen reduziert.
Die meisten Leute, die das CDN wählen, argumentieren, dass der Cache schneller ist, was vollkommen richtig ist. Die Realität ist jedoch, dass sich die Datei erst im Cache des Benutzers befindet, nachdem sie mindestens einmal heruntergeladen wurde. Das Gleiche gilt natürlich auch für die 20K-Datei. Es sollte daher klar sein, dass die lokale Datei tatsächlich schneller ist, es sei denn, Ihr Webserver ist so langsam, dass er sowieso nutzlos wäre.
Ein zusätzlicher Grund, die Datei lokal zu hosten, ist einfach die Kontrolle. Das heißt, SIE entscheiden, was sich in dieser Datei befindet, nicht jemand anderes.
Wie Paul Irish sagt, ist es am besten zu testen, aber ich kann mir nicht vorstellen, dass die Anzahl der Benutzer, die jQuery UI vorab im Cache haben, groß genug ist, um einen zusätzlichen Download von 180 KB für alle anderen zu rechtfertigen, der dann vom Browser geparst und ausgeführt werden muss. Auch die Client-Caching ist alles andere als garantiert, insbesondere auf mobilen Geräten.
Stellen Sie die erforderlichen 20 KB bereit, minimiert und gzip-komprimiert, und stellen Sie sicher, dass sie nach Möglichkeit auf dem Client zwischengespeichert werden.
Die Diskussion darüber, ob Bibliotheken in Browsern enthalten sein sollten, ist interessant. Um gut zu funktionieren, müsste man wohl eine neue JavaScript-API haben, mit der man abfragen könnte, ob die Bibliothek enthalten ist, und sie dann ausführen, falls dies der Fall ist
oder vielleicht ein neues Attribut für das Skript-Tag
Denkanstoß.
Zwischen 40 % und 60 % der Tesco-Kunden kommen mit leerem Cache an.
10 % davon sind immer leer.
Es ist keine Frage, 20 KB lokal jedes Mal auf einer Hochleistungs-Website.
Ich werde mich für lokal entscheiden, aber nicht nur wegen des Größenunterschieds, sondern weil CDN externe Abhängigkeiten einführt. Ich weiß, dass CDNs die Datei nicht offline nehmen sollen, aber irgendwie mag ich es wirklich, alles in demselben Ordner gebündelt zu haben.
Ich habe CDN ausprobiert, bis ein Kunde die App nicht zum Laufen bringen konnte, da seine interne Sicherheitsrichtlinie jede Google-Subdomain blockierte ...
Konventionelle Weisheit besagt, dass man die gehostete Lösung wählen sollte, aber ich habe Probleme mit der Dateigröße von über 200 KB.
Ich versuche, meine Webseiten unter 100 KB zu halten, ist 20 KB so groß?
Ich würde eine lokale Datei verwenden und andere Möglichkeiten finden, den Download zu beschleunigen (vielleicht auf einer anderen Domain hosten oder einen besseren Host verwenden).
Kleine Datei, Amazon CDN!
Ich weiß, dass das Hauptargument hier die Dateigröße ist, aber Leistung besteht aus mehr als nur dem. Was ist mit dem Parsen? Jetzt sprechen wir davon, 10-mal mehr Code auf Ihrer Website zu haben, als Sie benötigen, den der Browser parsen muss ... also würde ich mich für die 20k-Datei entscheiden. Ja, der Benutzer muss sie möglicherweise beim ersten Besuch Ihrer Website herunterladen, aber sie wird von da an zwischengespeichert und der Browser muss viel weniger Code parsen und verwenden.
Nachdem ich diese Diskussion gelesen habe, ist meine Praxis, lokale Kopien zu verwenden, gerechtfertigt.
Lokale Datei, kleine Größe. Ein 20k-Ladevorgang, auch wenn er nicht parallel erfolgt, ist im Durchschnitt 10-mal schneller als der 200k-Ladevorgang, vorausgesetzt, es gibt keine Verzögerungszeit, die selbst bei den größten CDNs auftritt.
Ich werde keine blockierende JS-Datei laden, die zehnmal größer ist, als sie sein muss, auch wenn sie MÖGLICHERWEISE aufgrund einer Google CDN-URL zwischengespeichert wird. Ich würde den im Durchschnitt schnelleren Ladevorgang der kleineren blockierenden Datei vorziehen.
Wenn Sie außerdem etwas laden, das Funktionen dieser Art enthält, auf einer sicheren Seite, öffnen Sie sich für eine Menge Ärger, wenn es um domainübergreifende Sicherheitsprobleme geht.
Ich bevorzuge die Verwendung von
Ich verwende beides, da ich ein Neuling bin, möchte ich sicherstellen, dass es geladen wird, wenn der CDN-Server aus irgendeinem Grund ausgefallen ist. Vorsicht ist besser als Nachsicht.
Ist das keine gute Praxis?
Ja, das ist es, aber stellen Sie sicher, dass Sie nicht beide laden
Da_n sagte
!window.jQuery && document.write(unescape(‘%3Cscript src=”/assets/js/libs/jquery-1.5.1.min.js”%3E%3C/script%3E’))
Ich würde die 20k-Datei vorziehen, aber nicht wegen der Downloadzeit. Korrigieren Sie mich, wenn ich falsch liege
Der Overhead, 300 KB JS-Code bei jedem Seitenaufruf ausführen und parsen zu müssen, ist weitaus schlimmer als das Ausführen von 20 KB JS-Code. (Ich denke, so funktioniert es)
Versuchen Sie, ein voll funktionsfähiges jQuery, jQueryUI und andere schwere JS-Bibliotheken auf einer Seite zu laden. Der Browser speichert sie im Cache, aber ich bin mir ziemlich sicher, dass die Seite schneller ist, wenn Sie kürzeres JS laden oder überhaupt kein JS.
Ich würde immer das schnellste JS bevorzugen, damit die Seite reaktionsschnell bleibt.
Ich benutze tatsächlich beides
Ich habe einen Minifizierer, der die JS-Bibliotheken vom Google CDN abruft, sie zusammen mit meinen eigenen Skripten zu einer einzigen Datei komprimiert, die auf meinem Server zwischengespeichert wird. Auf diese Weise muss ich nur eine einzige (und komprimierte) JS-Datei bereitstellen und habe gleichzeitig den Vorteil eines einfacheren Versionsmanagements (ich muss nur die Versionsnummer in meiner Ansicht aktualisieren, anstatt die Dateien herunterzuladen und zu ersetzen)
Ich bevorzuge auch CDN.