Codice JS interno o esterno?

cosmoweb

Codice JS interno o esterno?

Per un buon rendimento o posizionamento di una pagina web il codice JavaScript è meglio inserirlo internamente o meglio caricarlo da un'altro file (tipo .js)?

Esempio:

oppure

Spero di essere stato chiaro!

sjachille

dove possibile esternalizza sempre gli script - il browser li scarica una volta sola velocizzando i tempi di download delle pagine

banned

@sjachille said:

dove possibile esternalizza sempre gli script - il browser li scarica una volta sola velocizzando i tempi di download delle pagine

Non è del tutto corretto, un browser normalmente esegue in ogni caso una richiesta HTTP per verificare se il file è stato cambiato/aggiornato.
Quindi gli scripts - come anche i CSS - sarebbe opportuno metterli su file esterno ma allo stesso tempo aggregarli (evitare quindi di avere 12 scripts in 12 files diversi).

banned,

moroandrea

Per quello che ne sò io aggregarli o meno non comporta alcun giovamento. Il livello di traffico e di download sono essenzialmente gli stessi.
Anzi in caso di colli di bottoglia, una frammentazione del codice in più file risulta più veloce che non l'aggregazione.
Però sono interessato a conoscere la tua esperienza banned. Hai fatto delle prove che dimostrano il contrario?

sjachille

@banned said:

Non è del tutto corretto, un browser normalmente esegue in ogni caso una richiesta HTTP per verificare se il file è stato cambiato/aggiornato.
Quindi gli scripts - come anche i CSS - sarebbe opportuno metterli su file esterno ma allo stesso tempo aggregarli (evitare quindi di avere 12 scripts in 12 files diversi).

banned,

Forse non era del tutto chiaro ma mi riferivo ad una specifica sessione di navigazione - l'utente mi scarica il file esterno una sola volta e non N volte se lo script è incluso nelle pagine

banned

@moroandrea said:

Per quello che ne sò io aggregarli o meno non comporta alcun giovamento. Il livello di traffico e di download sono essenzialmente gli stessi.
Anzi in caso di colli di bottoglia, una frammentazione del codice in più file risulta più veloce che non l'aggregazione.
Però sono interessato a conoscere la tua esperienza banned. Hai fatto delle prove che dimostrano il contrario?

Non le ho fatte io, le ha fatte Yahoo!
http://developer.yahoo.com/performance/rules.html#num_http

banned,

moroandrea

Non approvo ... specie sulla storia del combina tutte le immagini in una e poi usa la background-position per mostrare l'area di interesse.
Cioè stando a quella filosofia dovrei prendere tutte le immagini del sito, fare una immagine che ne sò 2000 x 2000 e poi lavorare di fantasia e di righello per mostrare quello che mi serve?
E poi ... l'utente con un file da 500 k ... quando qua in Italia con la sua 56 k non arriva ad aprire nemmeno una pagina, glielo spieghi tu che hai seguito le linee guida di Yahoo?

Mah ... forse potrà essere diverso negli States dove lavorano con la fibra pure dentro casa, ma qua da noi, facciamo come siamo stati sempre abituati ... piccole immagini che compaiono in maniera progressiva perchè scaricate via via che le richieste vengono soddisfatte.

Al massimo, contemplo lo sliding doors, quindi il raggruppamento di immagini simili, che a buon bisogno è quello che intendono loro.

Ma però quando mi dicono pure, raggruppa tutti i css o tutti gli script in un unico file ...
e la manutenzione dove la mettiamo? Io ragiono anche da programmatore e se devo mantenere un codice js piuttosto complesso, magari diviso su più pezzi di codice eterogeneo riutilizzabile, mi consentano i signori di Yahoo di dire che non hanno capito nulla di manutenzione.
Un file singolo con un pezzo valido per 10 altre applicazioni deve stare per i cavoli suoi.

Ripeto, secondo me il concetto di fondo può anche esserci, ma dovrebbero - visto che hanno scritto delle linee guida - argomentare meglio.

banned

Stiamo andando OT (siamo gia andati, visto che si parla di posizionamento), ma vista la discussione interessante confido che qualche moderatore sposterà dove riterrà più opportuno.
@moroandrea said:

Non approvo ... specie sulla storia del combina tutte le immagini in una e poi usa la background-position per mostrare l'area di interesse.
Cioè stando a quella filosofia dovrei prendere tutte le immagini del sito, fare una immagine che ne sò 2000 x 2000 e poi lavorare di fantasia e di righello per mostrare quello che mi serve?
E poi ... l'utente con un file da 500 k ... quando qua in Italia con la sua 56 k non arriva ad aprire nemmeno una pagina, glielo spieghi tu che hai seguito le linee guida di Yahoo?

Credo tu abbia frainteso quello che viene detto o abbia fatto male i tuoi conti.
Prima di tutto Steve Souders non indica un solo metodo per fare questo lavoro ma ne indica due, preferibili a seconda dei casi.
Secondariamente: difficilmente otterrai un'immagine di tali dimensioni (2000x2000 px), calcola che devi metterci dentro le immagini che constituiscono il layout di una pagina web più eventuali spazi vuoti che ovviamente possono restare tra un'immagine e l'altra.
Se ottieni un'immagine di 2000x2000 px vuol dire che la somma di tutte le immagini che hai su una pagina web non è troppo lontana da quelle dimensioni - e quindi neppure le dimensioni.
Ti risparmi, però, N http requests.

E poi non è detto che devi fare un'unica immagine per tutto quanto il sito web; puoi, ad esempio, creare un'unica immagine per il layout, un'altra per le emoticons, una ancora per le varie icone che puoi utilizzare magari nel menù di navigazione e richiamarle quando ti occorre.

@moroandrea said:

Mah ... forse potrà essere diverso negli States dove lavorano con la fibra pure dentro casa, ma qua da noi, facciamo come siamo stati sempre abituati ... piccole immagini che compaiono in maniera progressiva perchè scaricate via via che le richieste vengono soddisfatte.
Quella tecnica non la utilizzano solo su www.yahoo.com ma anche su it.yahoo.com
Credo che anche nel secondo caso facciano più numeri di te e me insieme per avere qualche esperienza in merito

@moroandrea said:

Al massimo, contemplo lo sliding doors, quindi il raggruppamento di immagini simili, che a buon bisogno è quello che intendono loro.
Qua approvo in pieno, alcune immagini possono benissimo rimaner fuori da questo discorso.

@moroandrea said:

Ma però quando mi dicono pure, raggruppa tutti i css o tutti gli script in un unico file ...
e la manutenzione dove la mettiamo? Io ragiono anche da programmatore e se devo mantenere un codice js piuttosto complesso, magari diviso su più pezzi di codice eterogeneo riutilizzabile, mi consentano i signori di Yahoo di dire che non hanno capito nulla di manutenzione.
Un file singolo con un pezzo valido per 10 altre applicazioni deve stare per i cavoli suoi.
Esistono tools che permettono di aggregare e comprimere N files di 'testo' (si possono usare sia per HTML che per CSS che per JavaScript) in un unico file.
Tutto quello che devi da fare quando aggiorni o modifichi uno di questi file detti file sorgente (e non dirmi che tutti i giorni vai a ritoccare i CSS di un sito web.. solitamente restano tali per mesi) è rilanciare il tool in questione.

@moroandrea said:

Ripeto, secondo me il concetto di fondo può anche esserci, ma dovrebbero - visto che hanno scritto delle linee guida - argomentare meglio.

Ovviamente, come tutto quanto, non è da prendere come oro colato.
Ognuno potrà seguire certi aspetti alla lettera, valutarne altri e decidere che lo sforzo non vale la pena ed addirittura ignorare totalmente altri punti.
Quelle sono, come giustamente hai detto, solamente delle linee guida che però, ti ricordo ancora, sono fornite da qualcuno che sicuramente ha più esperienza di me e di te insieme.

banned,

michele.plus

ciao,
guarda finchè puoi tieni tutti gli elementi separati fra loro. Non ti parlo solo di javascript, ma anche di css e programmazione.
Cerca di tenere tutte le direttive css in file css esterni, i javascript in file esterni e i codici di programmazione in file esterni. Rendi la pagina più leggera, e meno incasinata per i motori di ricerca, che si troveranno così a leggere solo i contenuti, quello che loro interessa