nicht angemeldet molily
molily
T-Rex
Der Martin
Der Martin
Der Martin
molily
molily
molily
Moin,
ich habe gerade in den untiefen des Webs folgendes Zitat gelesen:
Everybody has jQuery cached on their client from the Google CDN anyway
Wie seht ihr das, wenn man jQuery benutzt: Sollte man es vom eigenen Server mitliefern oder über ein CDN, wie das von Google, laden lassen? Der Gedanke, dass es auf vielen Clients "eh schon gecached" vorhanden ist, ist mir bisher noch nicht gekommen, scheint mit aber logisch.
Grüße Marco
Hallo,
Das wurde kürzlich hier diskutiert:
http://forum.de.selfhtml.org/archiv/2013/9/t215059/#m1472255
Mathias
Moin,
Das wurde kürzlich hier diskutiert:
http://forum.de.selfhtml.org/archiv/2013/9/t215059/#m1472255
Danke, das hatte ich nicht mitgekriegt.
Grüße Marco
Tag,
ich habe gerade in den untiefen des Webs folgendes Zitat gelesen:
Everybody has jQuery cached on their client from the Google CDN anyway
> Wie seht ihr das, wenn man jQuery benutzt: Sollte man es vom eigenen Server mitliefern oder über ein CDN, wie das von Google, laden lassen? Der Gedanke, dass es auf vielen Clients "eh schon gecached" vorhanden ist, ist mir bisher noch nicht gekommen, scheint mit aber logisch.
ich habe gerade folgendes Zitat gefunden.
"What if Google CDN is down? It is smart to use CDN but what if the CDN is down (rare possibility though) however, you don't know in this world as many things may happen."
Ich würde es nicht tun. Wenn Dein System down ist, ist auch Dein jQuery down, aber (großer Vorteil), wenn Dein System up ist, ist auch Dein jQuery up.
Grüße
- Steffen
Meine Herren,
Ich würde es nicht tun. Wenn Dein System down ist, ist auch Dein jQuery down, aber (großer Vorteil), wenn Dein System up ist, ist auch Dein jQuery up.
Doch, falls das CDN nicht erreichbar ist, kann man als Fallback auf eine lokale Version setzen, siehe: http://forum.de.selfhtml.org/archiv/2013/9/t215059/#m1472363
Moin Moin!
Moin,
ich habe gerade in den untiefen des Webs folgendes Zitat gelesen:
Everybody has jQuery cached on their client from the Google CDN anyway
Ich nicht. Wer mich zwingen will, Javascript zuzulassen, sieht mich in aller Regel nicht wieder, abgesehen von einigen wenigen Ausnahmen.
Wie seht ihr das, wenn man jQuery benutzt: Sollte man es vom eigenen Server mitliefern oder über ein CDN, wie das von Google, laden lassen? Der Gedanke, dass es auf vielen Clients "eh schon gecached" vorhanden ist, ist mir bisher noch nicht gekommen, scheint mit aber logisch.
Ich hab sowas lieber unter eigener Kontrolle. JQuery ist in der komprimierten Fassung unter 35k groß, das fällt bei typisch vollgemüllten Webseiten kaum weiter auf. Wer wirklich das Pech hat, mit einem 56k-Modem ins Internet gehen zu müssen, hat ohnehin entweder Javascript ausgeschaltet oder ist Leid gewohnt. 35.000 Bytes über eine Modemstrecke mit 56 kBit/s herunterzuladen dauert bei 2 Bit Overhead pro Byte (10 Bit auf der Leitung pro Byte Nutzdaten) 6,25 Sekunden, über ISDN mit Kanalbündelung (128 kBit/s) rund 2,7 Sekunden, über eine 2 MBit-DSL-Leitung gerade noch 0,175 Sekunden, über eine 16 MBit-Leitung unter 20 Millisekunden, und über 100 MBit/s unter 4 Millisekunden.
So what? Die 35k stören wirklich nicht mehr.
Aber was passiert, wenn jemand das jeweils benutzte CDN (sei es Google, Microsoft, oder JQuerys eigenes) angreift und jquery.js gegen eine Version mit Malware austauscht? Richtig, plötlich verteilen tausende Websites Malware über das CDN.
Meine eigenen Server habe ich unter Kontrolle. Und wenn nicht, sind wenigstens nur meine eigenen Websites betroffen.
Viele Dinge funktionieren übrigens auch prima ganz ohne Javascript oder mit ein paar Zeilen Javascript, ganz ohne JQuery. Das ist vielen Webseitenpfuschern mittlerweile leider völlig entfallen.
Alexander
Hallo,
Wer mich zwingen will, Javascript zuzulassen, sieht mich in aller Regel nicht wieder, abgesehen von einigen wenigen Ausnahmen.
Das ist schön für dich, aber warum meinst du es hier kundgeben zu müssen? Hinsichtlich der Fragestellung, ob Bibliotheken wie jQuery vom CDN geladen werden sollten, sind solche Aussagen wenig hilfreich.
Es geht hier um eine Maßnahme zur Performance-Verbesserung. Das Laden von einem CDN kann die Ladeperformance nachweislich verbessern, selbst hinsichtlich des Overheads für den DNS-Lookup und die zusätzliche TCP-Verbindung. Das ist alles hinreichend untersucht und der Stand der Forschung ist: Verwendet CDNs.
Das ist ein empirisches Faktum, das man für jede Site mit Tools wie webpagetest.org oder GTMetrix konkret überprüfen sollte (eine geeignete Metrik ist übrigens der Speed Index).
JQuery ist in der komprimierten Fassung unter 35k groß, das fällt bei typisch vollgemüllten Webseiten kaum weiter auf.
Was für eine seltsame Argumentation. Mit der Frage »CDN oder nicht« hat es nichts zu tun, wie sich die Größe der geladenen Bibliothek zur Gesamtgröße der Website verhält.
über eine 2 MBit-DSL-Leitung gerade noch 0,175 Sekunden, über eine 16 MBit-Leitung unter 20 Millisekunden, und über 100 MBit/s unter 4 Millisekunden.
Realistisch sind Mobilzugriffe. Der Mobilmarkt wächst rasant und die meisten Mobilverbindungen haben eine hohe Latenz, einen schlechten Durchsatz und hohe Verluste. Performance-Optimierung ist daher wichtiger als je zuvor.
So what? Die 35k stören wirklich nicht mehr.
Natürlich sind 35 KB entscheidend. So entscheidend, dass man sich über die Art des Ladens von JavaScripten und insbesondere externen Bibliotheken Gedanken machen muss. So entscheidend, dass man auch die Wahl von jQuery infrage stellen sollte. Ob eine Seite in 5 oder 10 Sekunden lädt, ist geschäftsentscheidend.
Aber was passiert, wenn jemand das jeweils benutzte CDN (sei es Google, Microsoft, oder JQuerys eigenes) angreift und jquery.js gegen eine Version mit Malware austauscht? Richtig, plötlich verteilen tausende Websites Malware über das CDN.
Ja, das ist eine bekannte Einschränkung, das sämtliche Fremdscripte betrifft (z.B. Facebook, Twitter, Google Analytics usw.). Wobei die Sicherheitsstandards bei Google vermutlich höher sind als bei $irgendeinemBilligenSharedHoster.
Meine eigenen Server habe ich unter Kontrolle.
Da vertraue ich eher Google als mir selbst, was das Absichern von Servern betrifft.
Viele Dinge funktionieren übrigens auch prima ganz ohne Javascript oder mit ein paar Zeilen Javascript, ganz ohne JQuery.
Das ist schön, es fragt sich nur, warum du es hier anführst. Es ist unnötig, dass hier manche jedes Mal, wenn der Begriff »jQuery« vorkommt, ihre Ablehnung kundgeben und gegen vermeintliche »Webseitenpfuscher« wettern. Traurig, dass das auch noch als »fachlich hilfreich« bewertet wird.
Ich rate jedem dazu, sich ernsthaft mit Website-Performance-Optimierung zu beschäftigen. Das Wissen dazu scheint hier eher spärlich gesät. Es gibt viele hochqualitative Websites und Bücher in den einschlägigen Fachverlagen dazu.
Grüße,
Mathias
Also ich möchte hier nur mal in den Ring werfen, dass Google auch selbst der Bösewicht sein könnte. Sie könnten mit dem jquery noch ein bisschen mehr code mitliefern und so wunderbar die Seite abhören.
Gruß
NSA geschädigter
T-Rex
Hallo,
Sie könnten mit dem jquery noch ein bisschen mehr code mitliefern und so wunderbar die Seite abhören.
Dazu brauchen sie nicht jQuery fälschen, dazu haben sie bereits Google Analytics oder den Plus-One-Button auf nahezu jeder Seite. Dasselbe gilt für Facebook und zunehmend für Twitter – habe ich ja auch erwähnt.
Mathias
Also ich möchte hier nur mal in den Ring werfen, dass Google auch selbst der Bösewicht sein könnte. Sie könnten mit dem jquery noch ein bisschen mehr code mitliefern und so wunderbar die Seite abhören.
Und du glaubst, das würde nicht auffallen? Ich schätze mal, 1-2 Stunden, nachdem so ein Script online ist, ist so ne manilpulation bekannt.
NSA geschädigter
Nein, bist du nicht, denn wenn dem so wäre, würdest du hier nicht in einem öffentlichen Forum im Internet posten.
Und du glaubst, das würde nicht auffallen? Ich schätze mal, 1-2 Stunden, nachdem so ein Script online ist, ist so ne manilpulation bekannt.
Sowas hab ich früher auch gedacht, bis zu dem Zeitpunkt als Apple irgendwelche Spionage Dinger in seine Handys eingebaut hat und das erst zwei Jahre später durch Zufall aufgeflogen ist.
Nehmen wir mal an du wärst der größte Nerd auf dieser Welt, sitzt in deinem Keller lässt dir von Mama Plätzchen backen und baust die geilsten Webseiten die je ein Mensch gesehen hat. Guckst du jeden Tag nach dem jquery Code, denn dir Google so freundlich bereitstellt?
Oder anders, hast du dir jemals den Code von Google angeguckt?
Nur eine Quelle zu haben ist was feines. Man verbessert dort etwas und überall auf der Welt ist es auch verbessert. Aber das birgt auch gefahren. Was Google mit den Büchern macht halte ich z.B. für Fragwürdig. Am Ende gibts nur noch ein Exemplar von dem Buch und das hat Google in seiner Datenbank. Wenn sie jetzt was ändert hat das Auswirkungen auf das Menschheitswissen (wobei es in diesem Fall nur ein Buch wäre). Am Ende ist es nicht mehr der Butler gewesen sondern der Gärtner. Nagut nicht weiter tragisch. Aber was wäre wenn Jesus nur übers Wasser gehen konnte weil er die neuen Rex3000 Hover Schuhe anhatte?
Gruß
Rex3000 Hoverschuh Erfinder
T-Rex
Sowas hab ich früher auch gedacht, bis zu dem Zeitpunkt als Apple irgendwelche Spionage Dinger in seine Handys eingebaut hat und das erst zwei Jahre später durch Zufall aufgeflogen ist.
Native Software mit einer OS-Javascript-Bibliothek zu vergleichen, ist wie ein Fahrrad mit Obstsalat zu vergleichen
Nehmen wir mal an du wärst der größte Nerd auf dieser Welt, sitzt in deinem Keller lässt dir von Mama Plätzchen backen und baust die geilsten Webseiten die je ein Mensch gesehen hat. Guckst du jeden Tag nach dem jquery Code, denn dir Google so freundlich bereitstellt?
Ähm. Schonmal was von Checksummen gehört und das man Scripte automatisch vergleichen kann, ohne auch nur einen Blick drauf zu werfen?
Oder anders, hast du dir jemals den Code von Google angeguckt?
Nein, da ich keine CDNs nutze.Das liegt aber daran, dass meine ersten Projekte mit jQuery noch nicht online sind und um lokal zu testen nehme ich lieber eine lokale Kopie.
Bei Marktreife werde ich aber sicher CDNs nutzen mit nem Fallback auf ne lokale Kopie.
Was Google mit den Büchern macht halte ich z.B. für Fragwürdig.
Du vergleichst schon wieder Äpfel mit ner Strassenlaterne.
CDNs stellen Ressourcen zur Verfügung, die von anderen Programmierern (oder Communities)gepflegt werden, die Bücher werden von Google archiviert und dadurch stehen sie natürlich unter deren Kontrolle.
Wenn du also das mit den Büchern nicht magst, ist das absolut kein Argument gegen CDNs
Wenn du also das mit den Büchern nicht magst, ist das absolut kein Argument gegen CDNs
Das setzt voraus das ich gegen CDNs Argumentieren möchte.
Ich möchte lediglich ein paar Fragen zum nachdenken aufwerfen, die jeder für sich beantworten kann.
Gruß
Fragwürdiger
T-Rex
Hi,
Meine eigenen Server habe ich unter Kontrolle.
Da vertraue ich eher Google als mir selbst, was das Absichern von Servern betrifft.
ich nicht, denn es geht ja nicht so sehr um das Absichern gegen Angriffe von Dritten, sondern von Google selbst. Ich kann nie wissen, was den Jungs bei Google morgen für tolle Dinge einfallen. Google ist ein kommerzielles Unternehmen und wird Profit abgreifen, wo immer möglich - auch wenn das meinem Idealismus widerspricht, oder auch dem von anderen Web-Autoren.
Also bleibt nur, die Abhängigkeit von großen Anbietern nach Möglichkeit zu vermeiden.
Ciao,
Martin
Meine Herren!
Meine eigenen Server habe ich unter Kontrolle.
Da vertraue ich eher Google als mir selbst, was das Absichern von Servern betrifft.ich nicht, denn es geht ja nicht so sehr um das Absichern gegen Angriffe von Dritten, sondern von Google selbst.
Ich traue Google so viel Presse-Affinität zu, dass sie die Konsequenzen eines Image-Verlustes gut abzuschätzen wissen, die ein Angriff dieses Ausmaßes anrichten würde. Imho. sind deine Sorgen eher paranoider Natur als technisch fundiert begründbar. Wie sollte so ein Angriff von Google denn aussehen? Eine Code-Injection wie von T-Rex befürchtet würde jedenfalls schneller ans Tageslicht geraten, als man "jQuery" auszusprechen vermag.
Hallo,
Meine eigenen Server habe ich unter Kontrolle.
Da vertraue ich eher Google als mir selbst, was das Absichern von Servern betrifft.
ich nicht, denn es geht ja nicht so sehr um das Absichern gegen Angriffe von Dritten, sondern von Google selbst.Ich traue Google so viel Presse-Affinität zu, dass sie die Konsequenzen eines Image-Verlustes gut abzuschätzen wissen, die ein Angriff dieses Ausmaßes anrichten würde.
ich nicht, denn gerade von Google ist ja bekannt, dass exzessiv geschnüffelt wird. Was spricht dagegen, dass ein ähnliches Schnüffelscript wie Google Analytics auch in die jquery-Ressourcen integriert wird, die über das CDN verbreitet werden? Moralisch sehr viel, technisch nichts.
Imho. sind deine Sorgen eher paranoider Natur als technisch fundiert begründbar. Wie sollte so ein Angriff von Google denn aussehen?
Zum Beispiel so, wie ich gerade geschildert habe. Oder dass der Konzern einfach mitloggt, wer (über den Browser-Fingerprint ist schon eine ganz passable Nutzer-Identifikation möglich) wann, wie oft und von wo aus (d.h. mit welchem Referer) die jquery-Bibliothek abruft. So entsteht ruck-zuck ein Profil von Tausenden, wenn nicht gar Millionen von Internet-Nutzern, von denen man dann weiß, welche Web-Angebote sie so im Alltag nutzen.
Ich finde, wenn es um die Privatsphäre und den Schutz gegen das Unterwandern derselben oder um das Ausspähen von Informationen geht, die andere nichts angehen, kann man gar nicht paranoid genug sein.
Eine Code-Injection wie von T-Rex befürchtet würde jedenfalls schneller ans Tageslicht geraten, als man "jQuery" auszusprechen vermag.
Ja, vermutlich. Aber ein wenig mehr Raffinesse darf man den Burschen schon zutrauen.
Schönes Wochenenden,
Martin
Zum Beispiel so, wie ich gerade geschildert habe. Oder dass der Konzern einfach mitloggt, wer (über den Browser-Fingerprint ist schon eine ganz passable Nutzer-Identifikation möglich) wann, wie oft und von wo aus (d.h. mit welchem Referer) die jquery-Bibliothek abruft. So entsteht ruck-zuck ein Profil von Tausenden, wenn nicht gar Millionen von Internet-Nutzern, von denen man dann weiß, welche Web-Angebote sie so im Alltag nutzen.
Ist das nicht ein wenig witzlos? Ich meine, es geht doch darum, dass jQuery vom CDN eventuell schon im Cache ist, dann wird doch erst gar kein Request abgesetzt, also kann doch der Betreiber gar keine passable Nutzer-Identifikation mehr schaffen, oder übersehe ich jetzt was?
MfG
bubble
Hallo,
Zum Beispiel so, wie ich gerade geschildert habe. Oder dass der Konzern einfach mitloggt, wer (über den Browser-Fingerprint ist schon eine ganz passable Nutzer-Identifikation möglich) wann, wie oft und von wo aus (d.h. mit welchem Referer) die jquery-Bibliothek abruft. So entsteht ruck-zuck ein Profil von Tausenden, wenn nicht gar Millionen von Internet-Nutzern, von denen man dann weiß, welche Web-Angebote sie so im Alltag nutzen.
Ist das nicht ein wenig witzlos? Ich meine, es geht doch darum, dass jQuery vom CDN eventuell schon im Cache ist, dann wird doch erst gar kein Request abgesetzt, also kann doch der Betreiber gar keine passable Nutzer-Identifikation mehr schaffen, oder übersehe ich jetzt was?
ja, möglicherweise schon. :-)
Erstens ist es optimistisch, wenn man davon ausgeht, dass eine solche Ressource bereits im Cache ist. Das mag zutreffen, wenn man während *einer* Browser-Session mehrere Sites besucht, die dieselbe Ressource verlangen. Brave Browser löschen ihren Cache-Inhalt aber beim Beenden.
Zweitens geht eventuell auch dann ein Request raus, wenn die gewünschte Ressource bereits im Cache ist - nämlich ein "conditional GET". Das ist ein normaler GET-Request mit einem If-Modified-Since-Header, mit dem der Browser beim Server anfragt: Ich habe die Ressource in der Version vom 14.11. um 21:49, wenn du was Aktuelleres hast, schick's mir bitte. Und darauf antwortet der Server mit einem Status 304 (Not Modified) und einem leeren Response Body, oder eben mit einem 200 und der aktuellen Fassung der verlangten Ressource. Freilich kann man seinen Browser auch auf "stur" einstellen, so dass er nicht nach einer neueren Version fragt, aber das möchte man in der Regel nicht, weil es mehr Ärger als Nutzen bringt.
So long,
Martin
Brave Browser löschen ihren Cache-Inhalt aber beim Beenden.
Nein, das machen nur paranoide Browser. Der Cache im Auslieferungszustand liegt bei einigen tagen bis eine Woche, zumindest bei den Browsern, die ich kenne.
Da ca. 90% aller Internetnutzer gar nicht wissen, was ein Cache ist, wird die Einstellung mit hoher Wahrscheinlichkeit nicht geändert.
BTW: Wenn der Browser jedesmal nach dem Beenden den Cache löscht, müssen immer wieder die Ressourcenvom Server angefordert werden, daher ist eine viel detailiertere Auswertung möglich.
Somit unterstützt so eine Paranoiaeinstellung die Datensammelwut und hat als Effekt genau das Gegeteil von dem, was du erreichen willst.
Hallo,
Brave Browser löschen ihren Cache-Inhalt aber beim Beenden.
Nein, das machen nur paranoide Browser.
erwischt. ;-)
Der Cache im Auslieferungszustand liegt bei einigen tagen bis eine Woche, zumindest bei den Browsern, die ich kenne.
Bei mir ist die Einstellung hinsichtlich der Aufbewahrungsdauer eigentlich gegenstandslos, weil meine Browser ausschließlich RAM als Cache verwenden (dürfen). Ich kann es nicht leiden, wenn Programme etwas speichern, ohne dass ich das explizit will.
BTW: Wenn der Browser jedesmal nach dem Beenden den Cache löscht, müssen immer wieder die Ressourcenvom Server angefordert werden, daher ist eine viel detailiertere Auswertung möglich.
Somit unterstützt so eine Paranoiaeinstellung die Datensammelwut und hat als Effekt genau das Gegeteil von dem, was du erreichen willst.
Ja, ich weiß. Das ist eine Abwägung zwischen zwei verschiedenen Übeln. Ich bin schon immer wieder entsetzt, wie lange mancher Schrott im tmp-Verzeichnis liegenbleibt, das eigentlich bei jedem Systemstart (oder Shutdown) gelöscht werden sollte. Unter Windows hatte ich das so.
Ciao,
Martin
Hallo,
Oder dass der Konzern einfach mitloggt, wer (über den Browser-Fingerprint ist schon eine ganz passable Nutzer-Identifikation möglich) wann, wie oft und von wo aus (d.h. mit welchem Referer) die jquery-Bibliothek abruft.
Das steht technisch gesehen natürlich in ihrer Macht, wie gesagt.
Das machen sie vermutlich auch in beschränkter Weise, alleine um Missbrauch zu vermeiden und Angriffe zu erkennen.
So entsteht ruck-zuck ein Profil von Tausenden, wenn nicht gar Millionen von Internet-Nutzern, von denen man dann weiß, welche Web-Angebote sie so im Alltag nutzen.
Ich wiederhole mich ungerne, aber Google hat diese Daten bereits in viel größerem Ausmaß, nämlich über Google AdSense, Google Analytics, den Plus-One-Button und die Nutzung sämtlicher *.google.com-Dienste. Das ist ganz legal, freiwillig und geht ohne Betrug und ohne Fälschung fremder JavaScript-Bibliotheken vonstatten.
Das Profil, das durch den wiederholten Abruf von jQuery entsteht, ist kein Vergleich dazu.
Die Möglichkeit, dass Googles CDN jQuery manipulieren kann, ist natürlich gegeben, aber absurd. Wenn Google das macht, würde es einen riesigen Aufschrei geben. Sie haben viel leistungsfähigere Methoden, um die Nutzer auszuspionieren – siehe oben.
Aber ein wenig mehr Raffinesse darf man den Burschen schon zutrauen.
Es gibt keine Raffinessen beim Ausliefern von jQuery. Entweder die Dateien sind Byte für Byte identisch oder nicht, entweder die kryptographischen Hashes sind identisch oder nicht. Letzteres würde jeweils auffallen.
Nichts gegen Paranoia, aber sie sollte schon plausibel sein. Das Einbinden von jQuery von einem kostenlosen CDN ist ein potenzielles Risiko, wenn man dem Anbieter misstraut, aber im Vergleich zu den üblichen Tracking-Methoden witzlos. Das Szenario, dass jemand die CDN-Rechner hackt und so Malware verbreitet, ist wahrscheinlicher, als dass sich ein bekannter IT-Riese mit billigen Tricks Tracking-Code in jQuery einbaut.
Im Allgemeinen: Ich habe nichts gegen Threaddrift, aber man kann auch geschickt eine Diskussion entgleisen, wenn man die Ausgangsfrage ignoriert und stattdessen über eigene Befindlichkeiten redet.
Mathias
Hi,
Das Szenario, dass jemand die CDN-Rechner hackt und so Malware verbreitet, ist wahrscheinlicher, als dass sich ein bekannter IT-Riese mit billigen Tricks Tracking-Code in jQuery einbaut.
glaubst du das wirklich? - Ich nicht. Ich halte immer noch die für die Gefährlichsten, die an den zentralen Schaltstellen sitzen.
Im Allgemeinen: Ich habe nichts gegen Threaddrift, aber man kann auch geschickt eine Diskussion entgleisen, wenn man die Ausgangsfrage ignoriert und stattdessen über eigene Befindlichkeiten redet.
Stimmt. Das hast du tatsächlich perfekt drauf.
Ciao,
Martin
Hallo Stop
Nochmal Zum Mitschreiben Stop
Es Geht Hier Um Das Einbinden Von JQuery Ueber Ein CDN Stop
Das Kann Aber Muss Nicht Google Sein Stop
Es Gibt Hunderte CDN Anbieter Stop
Zum Beispiel Amazon CloudFront Oder CloudFlare Oder MaxCDN Stop
Das Sind Im Grunde Webhoster Die Sich Auf Das Verteilen Und Performante Ausliefern Von Dateien Auf Servern Rund Um Die Erde Spezialisiert Haben Stop
Ja Das Sind Allesamt Kommerzielle Profitorientierte Unternehmen Stop
Die Meisten Davon Sind Kostenpflichtig Stop
Sie Bieten Eine Dienstleistung An Und Wollen Dafuer Bezahlt Werden Stop
Diese Anbieter Sind So Vertrauenswuerdig Oder Nicht Wie Andere Hoster Auch Stop
Sie Koennen Auf Ihren Servern Freilich Tun Und Lassen Was Sie Wollen Stop
Eine Ganze Reihe Von CDNs Hosten Bibliotheken Wie JQuery Kostenlos Stop
Zum Beispiel Google Und Microsoft Und Media Temple Und MaxCDN Und CloudFlare Stop
Dieses Kostenlose Angebot Koennen Sie Freilich Jederzeit Aendern Oder Einstellen Stop
Man Kann Freilich Ein Eigenes Kostenpflichtiges CDN Verwenden Stop
Aber Dann Ist Es Unwahrscheinlicher Dass Der Browser Die Datei Schon Im Cache Hat EOF
Mathias
Es geht hier um eine Maßnahme zur Performance-Verbesserung. Das Laden von einem CDN kann die Ladeperformance nachweislich verbessern, selbst hinsichtlich des Overheads für den DNS-Lookup und die zusätzliche TCP-Verbindung. Das ist alles hinreichend untersucht und der Stand der Forschung ist: Verwendet CDNs.
Die Worte hör ich wohl ...
Drei Fragen:
Danke für jede Antwort
Gruß H.
Hallo!
- Wie ist das, wenn verschiedene Websites jQuery von verschiedenen Hostern einbinden? Landen die dann mehrmals im Cache?
Ja, klar.
Das ist ja das Standardverhalten, wenn eine Website jQuery vom selben Host einbindet. http://example.net/jquery.js und http://example.com/jquery.js werden gesondert gecacht, selbst wenn der Inhalt identisch ist.
- Wie ist das, wenn verschiedene Websites (auf Grund der Erstellungs-Historie) verschiedene Versionen von jQuery einbinden (gehostet werden ja z. B. 1.8, 1.9. 2.0)?
Dann wird ebenfalls jede Version einzeln gecacht. Andere URL => neuer Cache-Eintrag.
- Wie ist das, wenn auf die jeweils aktuellste Version von jQuery verwiesen wird (jQuery.last o. ä.) und dann Features verloren gehen (z.B. von 1.9.xx zu 2.0.xx)
Das sollte man tunlichst vermeiden. Das bietet das Google-CDN auch aus guten Gründen nicht an.
Erstens verletzt das das CDN-Caching-Konzept. Nur wenn unter derselben URL immer derselbe Inhalt kommt, kann der Server den Browser anweisen, die URL bis zum Sankt Nimmerleinstag zu cachen.
Zweitens funktioniert das in der Praxis nicht. Man kann nicht ohne zu testen einfach auf die neueste jQuery-Version umstellen. Denn jQuery ändert seine interne Funktionsweise und auch die externe API immer wieder. Das gilt für fast alle JavaScript-Bibliotheken. Der Umstieg sollte schon gar nicht automatisch passieren, wenn der Hoster die neue jQuery-Version einspielt. Entwickler müssen das manuell machen: Die Release-Notes lesen, testweise umstellen und die Funktionstüchtigkeit verifizieren. am besten mit einer automatisierten Test-Suite.
Grüße,
Mathias
Hallo Matthias!
Danke für Deine umfassende Antwort und Klarstellung. So ähnlich habe ich es mir gedacht, war mir aber nicht sicher. Das vielfach zu lesende Argument "sowieso schon im Cache" ist aber damit weitgehend obsolet, oder?
Gruß H.
Hallo,
Das vielfach zu lesende Argument "sowieso schon im Cache" ist aber damit weitgehend obsolet, oder?
Das sehe ich nicht so negativ. Natürlich ist die Situation durch die verschiedenen jQuery-Minor-Versions nicht so einfach; nicht jede Site, die jQuery vom Google CDN einbindet, kann auf den Browsercache vertrauen.
Ich weiß nicht, ob es empirische Untersuchungen über die Cache-Hits bei kostenlosen CDNs gibt. Wenn man die durchschnittliche Ladeperformance mit jQuery-CDN und ohne misst, wird das CDN wahrscheinlich schneller sein, was aber nicht an Cache-Hits liegen muss, sondern alleine an besserer Auslieferung liegt. Es ist schwierig, die reine Ladezeit eines Assets auf einer komplexen Seite bei den tatsächlichen Nutzern zu messen.
Die Caches heute sind ziemlich groß, zumindest auf Tablets und Desktop, sodass beim längeren Surfen auf verschiedenen Seiten sicherlich Cache-Hits auftreten. So viele aktuelle jQuery-Versionen gibt es schließlich nicht.
Grüße,
Mathias
Die Caches heute sind ziemlich groß, zumindest auf Tablets und Desktop, sodass beim längeren Surfen auf verschiedenen Seiten sicherlich Cache-Hits auftreten. So viele aktuelle jQuery-Versionen gibt es schließlich nicht.
So stelle ich mir ein funktionierendes Forum vor: man fragt, man bekommt eine begründete Antwort, und hinterher ist man klüger als zuvor. Vielen Dank!
Gruß H.
Meine eigenen Server habe ich unter Kontrolle. Und wenn nicht, sind wenigstens nur meine eigenen Websites betroffen.
Darf ich mal nach deinem Beruf bzw. nach deinem Wissensstand fragen, wenn du so eine, IMO fragwürdige, Aussage triffst.
Ich betreibe selbst mehrere Server, aber ich würde nie behaupten, ich hab die mehr im Griff als die Techniker von Google, die das nicht nebenbei machen müssen sondern sich damit Vollzeit beschäftigen können.
Meine Herren,
gerade über diesen Artikel gestolpert, der das Thema sehr ausfürhlich behandelt:
http://www.kendoui.com/blogs/teamblog/posts/13-11-07/know-when-to-cdn.aspx
Moin,
Everybody has jQuery cached on their client from the Google CDN anyway
habe gerade nachgeschaut, also ich hab's nicht im Cache, obwohl www.google.de meine Startsteite ist.
Gruß und so
Hallo,
habe gerade nachgeschaut, also ich hab's nicht im Cache, obwohl www.google.de meine Startsteite ist.
Ich sehe nicht, was das miteinander zu tun hat. www.google.de bindet jQuery nicht ein.
Dass unter anderem Google jQuery auf ihrem CDN anbietet, sagt nichts darüber aus, ob und wo diese Firmen jQuery selbst einsetzen.
Grüße,
Mathias