Soll JavaScript, auf das im head-Abschnitt verwiesen wird, mit demselben Hostnamen wie das Hauptdokument bereitgestellt werden?

Ich hatte den Eindruck, dass für die beste Leistung Javascript als statischer Inhalt behandelt und zusammen mit CSS-Dateien, Bildern usw. aus einer Domain ohne Cookies bereitgestellt werden sollte.

Aber Google sagt hier: Liefern Sie keine früh geladenen externen JS-Dateien aus der Domäne ohne Cookies

Für JavaScript, auf das im Kopf des Dokuments verwiesen wird und das für den Seitenstart benötigt wird, sollte es mit demselben Hostnamen wie das Hauptdokument bereitgestellt werden. Da die meisten Browser andere Downloads und das Rendern blockieren, bis alle JavaScript-Dateien heruntergeladen, analysiert und ausgeführt wurden, ist es besser, das Risiko einer zusätzlichen DNS-Suche zu diesem Zeitpunkt der Verarbeitung zu vermeiden.

So, jetzt bin ich in Konflikt geraten. Mir ist nicht klar, was "für den Seitenstart benötigt" bedeutet.

Normalerweise habe ich zwei JavaScript-Referenzen, JQuery von ajax.googleapis.com und eine master.js-Datei, die hauptsächlich Ereignishandler in der Funktion $ (document) .ready () enthält. Wird dies für den Seitenstart benötigt?

In Anbetracht der verfügbaren Optionen (ajax.googleapis.com, statische Domäne ohne Cookies, ursprünglicher Hostname), wo soll mein JavaScript bereitgestellt werden?

So, jetzt bin ich in Konflikt geraten. Mir ist nicht klar, was "für den Seitenstart benötigt" bedeutet.

Dies hängt sehr davon ab, wie Ihre Website funktioniert. Grundsätzlich ist es das JavaScript, das ausgeführt werden muss, bevor jemand die Webseite verwenden kann.

Wenn Sie beispielsweise zu http://www.weather.com/ gehen , können Sie sehen, dass sich die feinen Leute dazu entschlossen haben, JavaScript-Magie zu verwenden, um einen Hinweis für das Wettersuchformular bereitzustellen. Dh die Wörter Enter Zip, City or Place (e.g. Disney World)erscheinen im Texteingabefeld. Leider gibt es eine leichte Verzögerung beim Laden der Seite, zumindest bei mir. Wenn die Seite also langsam genug ist, um geladen zu werden, und Sie schnell genug sind, um mit der Texteingabe zu beginnen, bevor das JavaScript ausgeführt wird - was kein Problem ist -, kann Ihre Eingabe durch das JavaScript, das diesen Hinweis blind platziert, verkorkst werden Text im Eingabefeld.

Zugegeben, dies könnte vermieden werden, indem zuerst im Textfeld nach Benutzereingaben gesucht wird oder einfach auf diese anachronistische Technik verzichtet wird. Dann wäre es jedoch kein besonders gutes Beispiel.

In Anbetracht der verfügbaren Optionen (ajax.googleapis.com, statische Domäne ohne Cookies, ursprünglicher Hostname), wo soll mein JavaScript bereitgestellt werden?

Dies kann nicht wirklich beantwortet werden, ohne zu wissen, was Ihr JavaScript tut. Wie bpeterson76 andeutet, hängt dies auch von der spezifischen Situation Ihrer Site ab. Dh wie groß ist die Seite? Wie gut ist die Nachfrage Ihres Gastgebers nach Meetings? Wie viele CSS-Dateien, Bilder usw. werden geladen? Wie viele externe Ressourcen werden geladen?

Abhängig von Ihrer spezifischen Situation kann dies eine vorzeitige Optimierung sein.

Die Regel "Alles, was benötigt wird, bevor die Seite gerendert wird, sollte vom selben Server stammen" gilt im Allgemeinen für Ihren ServerServer oder andere kleinere Ressourcen - Situationen, in denen die DNS-Suche einen merklichen Sekundenbruchteil in Anspruch nimmt (was sich schnell summieren kann, wenn Ihre Objekte über viele Domänen verstreut sind). Bei allgemeinen öffentlichen Ressourcen wie dem jQuery-Cache von Google und anderen Bibliotheken besteht eine gute Chance, dass der Browser Ihres Besuchers diese DNS-Suche bereits heute durchgeführt hat (da andere Websites auf den Inhalt dieses Dienstes verweisen) und die Datei wahrscheinlich auch im Cache gespeichert ist Die Übertragung muss durchgeführt werden (oder wenn eine Anforderung erfolgt, wird möglicherweise nur eine kurze Antwort "304 - nicht geändert" zurückgegeben). Selbst wenn für das Objekt ein vollständiger Download erforderlich ist, ist das Content Delivery-Netzwerk von Google für die meisten Nutzer schneller als Ihr kleinerer Vorgang.

Eine verwandte Regel: Objekte, die für die korrekte Funktion der Seite nicht erforderlich sind (wie der Benutzer es sieht), sollten in der HTTP-Hauptantwort so spät wie möglich angegeben werden. Zum Beispiel Dinge wie die Skripte, die für Werbe- / Statistikdienste benötigt werden (z. B. Google Analytics und sein Umfeld) - geben Sie dem Nutzer Ihre Inhalte so schnell wie möglich und laden Sie dann das Hintergrundmaterial, das Sie nur wirklich interessiert. Ich habe einige Anzeigen- / Statistikdienste blockiert (indem ich sie in meiner Hosts-Datei 127.0.0.1 zugeordnet habe), weil sie oft zu langsam sind und Websites, die früh auf sie verweisen, mir nur eine leere Seite geben, während auf die Skripte gewartet wird Wenn ich mich zu spät auf sie beziehe, kann ich den Inhalt lesen, für den ich da bin, während das andere Zeug im Hintergrund herumwirbelt.

Die Nützlichkeit einer Domain ohne Cookies für statische Inhalte ist eine Frage der Größenordnung. Wenn Sie lediglich eine 10-Byte-Sitzungs-ID in den Cookies haben und zehntausend Besucher pro Tag ~ 20 statische Objekte pro Besuch anfordern, sparen Sie nur ~ 118 MB Bandbreite pro Monat (20 * 20 * 10000 * 31/1024/1024). Wenn auf der anderen Seite auf Ihrer Website ein oder zwei KByte an Daten in den Cookies gespeichert sind, kann der Unterschied erheblich größer sein, insbesondere wenn einer Ihrer Benutzer über langsame Verbindungen auf die Website zugreift (z. B. GPRS über Tethering mit einem Mobiltelefon oder ein Over - überfüllte WLAN-Verbindung in einem stark gestörten Bereich oder wenn Sie Millionen von Besuchen pro Tag erhalten.

Zusammenfassend sind meine Einstellungen für Skripte, die geladen werden müssen, bevor die Seite gerendert werden kann:

1. ajax.googleapis.com oder ähnlich
2. ursprünglicher Hostname der aufrufenden Seite
3. statische Domain ohne Cookies

Informationen zu Ressourcen, die für das Rendern der ersten Seite nicht unbedingt erforderlich sind, sollten Sie so spät wie möglich abrufen und die oben aufgeführte Liste der Einstellungen umkehren (obwohl der Unterschied zwischen dem ursprünglichen Hostnamen und der Domäne ohne Cookies höchstwahrscheinlich nur dann erheblich ist, wenn Sie in großem Maßstab arbeiten ).

Google betreibt ein riesiges Content-Werbenetzwerk, das auf der ganzen Welt verteilt ist und den Content näher an den Nutzer bringt als jeder andere Server, den Sie wahrscheinlich betreiben (denken Sie an Akami, aber im Besitz von Google) Google bringt Ihre Datei schneller als Ihr lokaler Server zum Nutzer ... es sei denn, diese befinden sich in unmittelbarer Nähe zu Ihrem persönlichen Server.

Diese Frage ist bei Stackoverflow immer wieder aufgetaucht, und die obige Antwort scheint immer der Konsens zu sein. Aber von einem realistischen Standpunkt aus gesehen, werden die Gewinne, die durch das Hosting bei einem gegen dem anderen erzielt werden, auf lange Sicht ziemlich gering sein. Das Minimieren, Optimieren und Reduzieren der gesamten HTTP-Anforderungen bietet weitaus bessere Vorteile als das Überprüfen des physischen Standorts. In Situationen, in denen es wichtig zu werden beginnt (ich habe einen Job gemacht, bei dem eine Seite mehr als 1,5 Millionen Mal pro Tag geladen wurde, sodass eine Verbesserung um 5.000 Gigs zu Bandbreiteneinsparungen führte), gibt es normalerweise ein Team von Entscheidungsträgern, die mit der Überprüfung dieser Entscheidungen beauftragt sind.

Persönlich hoste ich normalerweise bei Google aus dem einzigen Grund, dass sie mir das aktuellste Exemplar von dem geben, wonach ich suche.

Eine wichtige Sache, an die man sich erinnern sollte, ist, dass Browser die Anzahl der Ressourcen, die gleichzeitig von derselben Domain heruntergeladen werden, begrenzt haben, in der Regel zwischen 2 und 6, abhängig vom Browser. Durch die Verwendung einer anderen Domain kann der Browser mehr Dinge gleichzeitig von Ihrer Domain herunterladen.

Die beste Lösung ist daher, ein beliebtes CDN wie ajax.googleapis.com zu verwenden, da auf diese Weise keine Cookies vorhanden sind. Der Benutzer hat wahrscheinlich bereits die DNS-Suche durchgeführt und möglicherweise sogar die Ressource zwischengespeichert. CDNs sind auf Geschwindigkeit optimiert und haben wahrscheinlich einen Server in der Nähe Ihres Benutzers.

Wenn ein CDN nicht in Frage kommt, können Sie, wenn Sie viele Cookies haben oder viele Ressourcen zum Herunterladen haben (Bilder usw.), eine cookiefreie Domain verwenden (die DNS-Suche muss sowieso nur einmal durchgeführt werden).

Wenn Sie nur wenige Ressourcen (nur eine benutzerdefinierte Javascript-Datei) und wenige Cookies (nur eine winzige Sitzungs-ID) von derselben Domain haben.

Gute Ressourcen:

http://www.phpied.com/free-falling-waterfalls/

http://www.stevesouders.com/blog/2009/04/27/loading-scripts-without-blocking/

http://developer.yahoo.com/performance/rules.html

Obwohl die obigen Antworten den größten Teil Ihrer Frage zerlegt haben, werde ich einen Beitrag zu "Erforderlich für den Seitenstart" leisten. Ich übersetze dies in: Ist dieses Skript für die Nutzung der Website unerlässlich ? Erfahrungsgemäß lautet die Antwort in der Regel nein. Fälle, in denen ich:

• Formularvalidierung
• Eine JavaScript-basierte Navigation (ohnehin nicht ideal)
• Wenn das Layout von JavaScript abhängt
• Wenn JavaScript oder eine Bibliothek (wie jQuery) für wichtige DOM-Änderungen verwendet wird

Und die YSlow-Leistungsrichtlinien von Yahoo als Referenz.