JavaScript a cui si fa riferimento nella sezione head deve essere offerto con lo stesso nome host del documento principale?


12

Avevo l'impressione che per le migliori prestazioni, Javascript dovesse essere trattato come contenuto statico e servito da un dominio senza cookie insieme a file CSS, immagini, ecc.

Ma Google dice qui: non pubblicare file JS esterni caricati in anticipo dal dominio senza cookie

Per JavaScript a cui si fa riferimento nell'intestazione del documento e necessario per l'avvio della pagina, dovrebbe essere offerto con lo stesso nome host del documento principale. Poiché la maggior parte dei browser blocca altri download e rendering fino a quando tutti i file JavaScript non sono stati scaricati, analizzati ed eseguiti, è meglio evitare il rischio di una ricerca DNS aggiuntiva in questo punto di elaborazione.

Quindi ora sono in conflitto. Non sono chiaro cosa significhi "necessario per l'avvio della pagina".

In genere ho due riferimenti JavaScript, JQuery fornito da ajax.googleapis.com e un file master.js che contiene principalmente gestori di eventi nella funzione $ (document) .ready (). È necessario per l'avvio della pagina?

Date le opzioni disponibili, (ajax.googleapis.com, dominio senza cookie statico, nome host originale) dove dovrebbe essere offerto il mio JavaScript?

Risposte:


5

Quindi ora sono in conflitto. Non sono chiaro cosa significhi "necessario per l'avvio della pagina".

Questo dipende molto da come funziona il tuo sito. Fondamentalmente, è il JavaScript che deve essere eseguito prima che qualcuno possa utilizzare la pagina web.

Ad esempio, se vai su http://www.weather.com/ , puoi vedere che le brave persone hanno deciso di usare un po 'di magia JavaScript per fornire un suggerimento per il modulo di ricerca meteorologica. Vale a dire le parole Enter Zip, City or Place (e.g. Disney World)compaiono nel campo di inserimento del testo. Sfortunatamente, c'è un leggero ritardo nel caricamento della pagina, almeno da parte mia. Quindi, se la pagina è abbastanza lenta da caricare e sei abbastanza veloce da iniziare a digitare l'input di testo prima che venga eseguito JavaScript - che non è un tratto - il tuo input può essere rovinato dal JavaScript che posiziona ciecamente quel suggerimento testo nella casella di input.

Certo, questo potrebbe essere evitato controllando prima l'input dell'utente nella casella di testo o semplicemente rinunciando a questa tecnica anacronistica. Tuttavia, non servirebbe da ottimo esempio.

Date le opzioni disponibili, (ajax.googleapis.com, dominio senza cookie statico, nome host originale) dove dovrebbe essere offerto il mio JavaScript?

Non si può davvero rispondere a questa domanda senza sapere cosa fa il tuo JavaScript. Inoltre, come allude bpeterson76, dipende dalla situazione specifica del tuo sito. Vale a dire quanto è grande la pagina? quanto è richiesta la tua riunione ospitante? quanti file CSS, immagini, ecc. vengono caricati? quante risorse esterne sta caricando?

A seconda della situazione specifica, questa potrebbe essere un'ottimizzazione prematura.


4

La regola "tutto ciò che è necessario prima che inizi il rendering della pagina dovrebbe provenire dallo stesso server" si applica generalmente al tuoserver o altre risorse minori: situazioni in cui la ricerca DNS può richiedere una notevole frazione di secondo (che può sommarsi rapidamente se i tuoi oggetti sono sparsi in molti domini). Con risorse pubbliche comuni come la cache di Google di jQuery e altre librerie, ci sono buone probabilità che il browser del tuo visitatore abbia già svolto la ricerca DNS oggi (perché altri siti fanno riferimento al contenuto di quel servizio) e probabilmente ha anche il file nella cache, quindi no il trasferimento deve essere eseguito (o se viene effettuata una richiesta, potrebbe restituire una breve risposta "304 - non modificata"). Anche se è necessario un download completo per l'oggetto, la rete di distribuzione dei contenuti di Google sarà più veloce per la maggior parte degli utenti rispetto alle operazioni su scala ridotta.

Una regola correlata: gli oggetti che non sono necessari per la corretta funzione della pagina (come l'utente la vede) dovrebbero essere indicati il ​​più tardi possibile nella risposta HTTP principale. Ad esempio cose come gli script richiesti per i servizi di pubblicità / statistiche (ad es. Google Analytics e simili): dai all'utente i tuoi contenuti il ​​più rapidamente possibile, quindi carica le informazioni di sfondo che ti interessano davvero. Ho bloccato un paio di servizi di annunci / statistiche (mappandoli a 127.0.0.1 nel mio file hosts) perché spesso sono troppo lenti e i siti che li si riferiscono in anticipo mi danno solo una pagina vuota mentre invece sono attesi gli script di riferirmi a loro in ritardo in modo che io possa leggere il contenuto per cui sono lì mentre le altre cose si muovono sullo sfondo.

L'utilità di un dominio senza cookie per il contenuto statico è una questione di scala. Se hai solo un ID sessione di 10 byte nei cookie e diecimila visitatori al giorno che richiedono ~ 20 oggetti statici per visita, risparmierai solo ~ 118 MB di larghezza di banda al mese (20 * 20 * 10000 * 31/1024/1024). Se d'altra parte il tuo sito mantiene uno o due Kbyte di roba nei cookie, la differenza può essere molto più significativa, specialmente se qualcuno dei tuoi utenti accede al sito tramite connessioni lente (ad es. GPRS attraverso il tethering su un cellulare o un over collegamento wifi affollato in un'area ad alta interferenza) o se ricevi milioni di visite al giorno.

Per riassumere, per gli script che devono essere caricati prima che la pagina possa rendere le mie preferenze sarebbero:

  1. ajax.googleapis.com o simili
  2. nome host originale della pagina chiamante
  3. dominio statico senza cookie

Per le risorse che non sono essenziali per il rendering iniziale della pagina, consultale il più tardi possibile e inverti l'elenco delle preferenze sopra (sebbene la differenza tra nome host originale e dominio senza cookie sia molto probabilmente non significativa se non stai operando su vasta scala ).


With common public resources ... there is a good chance that your visitor's browser has already done that DNS lookup today Personalmente, non mi sentirei a mio agio a fare affidamento su questo per il mio sito. Vorrei che fosse il più veloce ragionevolmente possibile in quante più situazioni possibili. Indipendentemente da ciò, fai buoni punti. +1
George Marian,

1

Google gestisce un'enorme rete di contenuti distribuita in tutto il mondo che avvicina il contenuto all'utente rispetto a qualsiasi singolo server che stai probabilmente eseguendo (pensa Akami, ma di proprietà di Google) Quindi, da un punto di vista della velocità, è logico che Google invierà i tuoi file all'utente più velocemente del tuo server locale ... a meno che non siano molto vicini al tuo server personale.

Questa domanda è andata in giro su Stackoverflow e la risposta di cui sopra sembra essere sempre il consenso. Ma da un punto di vista realistico, i guadagni ottenuti ospitando l'uno contro l'altro saranno abbastanza minimi nel lungo periodo. Otterrai benefici di gran lunga migliori dalla minimizzazione, dall'ottimizzazione e dalla riduzione delle richieste HTTP complessive rispetto a quando verifichi dove si trovano fisicamente le cose. In situazioni in cui inizia a importare (ho fatto un lavoro in cui una pagina caricava più di 1,5 milioni di volte al giorno, quindi un miglioramento di 5k significava 5 concerti nei risparmi di larghezza di banda) di solito c'è un team di responsabili delle decisioni che hanno il compito di esaminare queste decisioni.

Personalmente, di solito ospito su Google per il solo motivo che mi daranno la copia più aggiornata di ciò che sto cercando.


Dove ospiti il ​​tuo JavaScript personalizzato? Dominio statico senza cookie o nome host originale?
James Lawruk,

Onestamente, al di fuori di Jquery (principalmente) in linea, non c'è davvero molto che non possa essere collegato dinamicamente. Tendo a ridurre al minimo il voodoo, utilizzando (principalmente) il core Jquery e l'interfaccia utente di Jquery, con la possibile eccezione del plug-in Datatables. Sono un grande sostenitore del concetto di Keep it simple (stupido) e non pubblicherò codice se non è retrocompatibile, il che esclude molte opzioni. Come ho detto sopra, mettere un file su un dominio senza cucina non è un grosso problema.
bpeterson76,

1

Una cosa importante da ricordare è che i browser hanno dei limiti su quante risorse verranno scaricate contemporaneamente dallo stesso dominio, in genere tra 2 e 6 a seconda del browser. L'uso di un dominio diverso consente al browser di scaricare più elementi contemporaneamente dal tuo dominio.

Quindi la soluzione migliore è utilizzare una CDN popolare come ajax.googleapis.com in questo modo non ci sono cookie. Probabilmente l'utente ha già eseguito la ricerca DNS e potrebbe anche aver memorizzato nella cache la risorsa. I CDN sono ottimizzati per la velocità e probabilmente hanno un server vicino al tuo utente.

Se una CDN non è un'opzione, se si dispone di molti cookie o di molte risorse da scaricare (immagini, ecc.), Utilizzare un dominio privo di cookie (è necessario eseguire una ricerca DNS una volta comunque).

Se hai poche risorse (solo un file javascript personalizzato) e pochi cookie (solo un piccolo ID sessione) ospitano dallo stesso dominio.

Buone risorse:

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


1

Sebbene le risposte di cui sopra abbiano analizzato la maggior parte della tua domanda, contribuirò su "necessario per l'avvio della pagina". Lo traduco in: questo script è essenziale per l'utilizzo del sito Web? Per esperienza, di solito la risposta è no. Tuttavia, i casi in cui vorrei:

  • Convalida del modulo
  • Una navigazione basata su JavaScript (non ideale comunque)
  • Se il layout dipende da JavaScript
  • Se JavaScript o una libreria (come jQuery) vengono utilizzati per modifiche DOM critiche

E le linee guida sulle prestazioni YSlow di Yahoo come riferimento.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.