File JS, include PHP o tag statico?

[Experiment8]

Ciao a tutti,

Vi scrivo perché vorrei chiarire un dubbio: recentemente ho visto un sito in cui vengono richiamati nell'header i soliti Javascript per i piu' disparati compiti, ma invece di essere presenti con i classici tag statici "script" con annesso tag "src", venivano inseriti direttamente nell'header della pagina all'interno di un generico elemento "script", in cui veniva scritto tutto il codice JS presente in questi file direttamente tramite un include in PHP.

La mia domanda è semplice, è preferibile ad avere tag statici "classici" o un include PHP di questo genere? Sicuramente si evitano alcune chiamate HTTP dato che è tutto compreso nella pagina HTML, "sacrificando" il server, ma non risulta una soluzione meno "Pulita"? Inoltre quale metodo garantisce la miglior resa in termini di cache del sito?

Scusate la domanda magari banale, sinceramente io sono per mantenere tag HTML statici, anche per una questione di pulizia del codice, altrimenti tanto vale scrivere il codice direttamente nel template così non si appesantisce nemmeno il server...

Grazie a chiunque riuscirà a fare un pò di chiarezza!

[chumkiu]

La risposta è ovviamente: "dipende".

Ci sono livelli di ottimizzazione che richiedono scelte difficili o contro-intuitive o che sembrano andare contro standard di fatto o consigli di buone pratiche (o almeno, quelli più conosciuti e ritenuti erroneamente universalmente validi).

Ci sono ovviamente tanti casi da prendere in esame e valutare di conseguenza, anche considerando il tipo di utenza (se è molto "di ritorno" o sono per lo più "nuovi visitatori") e di conseguenza quanto vuoi complicarti la generazione e la manutenzione di codice per risparmiare qualche decimo di secondo in più di caricamento (che in alcuni casi ha senso fare, in altri no).

In ogni progetto, c'è del codice che ha senso rendere bloccante (cioè che sia caricato prima del rendering della pagina) e altro codice che non ha senso renderlo tale. Pensa per esempio alle librerie di 200kb (jQuery per esempio): queste non ha senso renderle bloccanti e sarebbe opportuno caricarle in modo asincrono quanto prima. Però ci possono essere dei bytes di javascript che sono essenziali per il rendering della pagina (in alcuni progetti, per esempio, noi usiamo una funzione per gestire le immagini responsive, e questa deve essere caricata prima che il browser incontri qualche tag <img>. La stessa funzione che carica le librerie in modo asincrono, e che funzioni su tutti i browser, deve essere dichiarata ed eseguita quanto prima).

Per cui, se questo codice essenziale (quindi "bloccante") è di pochi bytes, hai due scelte:

- fare un normale file esterno da richiamare col classico script src.
- inserirlo nella pagina (opportunamente minificato)

Se il codice bloccante è poco, può aver senso utilizzare la seconda: ti risparmi tutti i bytes degli header di richiesta del client e di risposta del server (oltre che tutte le latenze di una chiamata http). Inoltre risolvi anche il problema di invalidazione della cache ed eventualmente, se questi files statici sono in un altro dominio (tipo js.dominio.it invece che il classico www.*), ti risparmi anche una chiamata al dns. Questi sono tutti millisecondi risparmiati.

Se hai un sito molto visitato, e/o dove la velocità di caricamento la prima volta è essenziale per una buon prima impressione sul visitatore, sono tutti accorgimenti che si possono adottare.

[Experiment8]

Ciao chumkiu,


Grazie per la tua spiegazione, molto completae chiara, capisco dunque come questa scelta possa risultare idonea in alcuni ambiti.


Una domanda, verso la fine tu dici che se i file sono addirittura su un dominio differente puoi evitare, inserendo il codice nella pagina, di avere la latenza di una chiamata http e di una al dns, ma questo quindi vale anche per le cdn o mi sbaglio? Lo dico perché il sito in questione lo vedo avere gli include PHP che ho citato prima, che sono in linea con l'idea di rendere il primo caricamento il più veloce possibile, o comunque diminuire la latenza, ma lo stesso ha anche chiamate a cdn JQuery e diverse font Google, questo invece non penalizza il discorso del primo caricamento e della velocità di visualizzazione per il discorso della latenza? aiuta sicuramente a livello di cache per i visitatori che ritornano, ma non i nuovi, o mi sbaglio?


Mi sembra di capire che la verità sta nel mezzo

[chumkiu]

Vale ovviamente per tutto. Con le CDN hai una certa probabilità (secondo me troppo bassa per crederci sul serio) che le risorse che richiedi siano già cachate dall'utente. Ma se non lo sono, una richiesta http te la devi fare comunque.

Per i DNS: ovviamente è più probabile che hai già l'indirizzo del CDN nella cache del browser.

La verità sta nel fatto che bisogna prima occuparsi delle cose macroscopiche, e poi dei peli nell'uovo :-)
Tradotto: non mi preoccuperei dei dns se poi mi metti 300kb di javascript bloccante nell'head :-)

Che poi ripeto, può essere una scelta legittima farla, purché sia fatta con cognizione di causa. Per esempio in una area admin, non ha senso preoccuparsi di queste cose (secondo me). O in un gioco con decine di librerie da caricare, ha forse senso fare un preloading con una animazione o frase di intrattenimento, piuttosto che destreggiarsi in chiamate asincrone qua e la a rischio di gestirsele male.

edit: Ah e poi una nota.

Ci sono strumenti che ti compattano il codice javascript (cosa che ha senso fare sia nei file esterni, sia [e soprattutto] negli include nell'html.
Guardati uglify (io lo uso con Grunt)

[Experiment8]

Ciao chumkiu,

Grazie mille per il chiarimento, come per ogni cosa dunque dipende da molti fattori stabilire la strada giusta.
Sono comunque d'accordo con te sul fatto della poca probabilità data dalle cdn di avere già in cache il file, ok che il dns possa con piu' probabilità esserlo, ma allora a quel punto tanto vale avere una versione propria sul proprio server no? tanto in qualunque caso la chiamata HTTP viene eseguita, e la cache vale anche per il proprio dominio esattamente come per le cdn...
Per quanto riguarda la libreria grazie mille, sinceramente non la conoscevo, la metterò alla prova