- Home
- Categorie
- Digital Marketing
- Posizionamento Nei Motori di Ricerca
- SEO Tecnica - Core web vitals - File JS
-
SEO Tecnica - Core web vitals - File JS
Buongiorno a tutti,
premetto che sono uno sviluppatore e sto sviluppando una soluzione custom con motore #Hugo. Il tema che sto usando utilizza tantissimi file JS di terze parti (mega menù, JQuery, slider, popup ecc. ecc.)
In ottica SEO ho scritto un codice per fare in modo che in ogni pagina vengano richiamati solo i riferimenti ai file dei codici JS utilizzati per quella singola pagina.Quindi, ad esempio, la pagina_A utilizzerà:
- JQuery
- Slider
mentre la pagina_B utilizzerà:
- JQuery
- Slider
- Popup
- Carosello
Dopodiché unisco tutto in un unico file, minimifico e servo alla pagina.
Facendo così ottengo il fatto che ogni pagina carica un unico file (e poche richieste al server solitamente piacciono a Google Page Speed e ai Core Web Vitals) ma questo file, ovviamente è pesantissimo (contiene tutto). Inoltre ad ogni cambio di pagina il file ovviamente cambia e il browser (e il google bot) deve riscaricarsi un nuovo file dove una buona parte del codice (JQuery ad esempio) è sempre la stessa. Quindi ho un vantaggio (poche richieste al server) ma uno svantaggio, secondo me, per l'utente perché non sfrutto per niente la cache del browser senza considerare che la pagina carica, per forza di cose, un po' più lentamente (un conto è elaborare diversi file JS un conto è elaborare un unico file enorme)Potrei mettere i singoli file (minimificati ovviamente) così sfrutterei la cache del browser tuttavia avrei il problema che farebbe molte più richieste al server...ora cosa è meglio lato SEO? Quanto influisce sui Core WebVitals questo aspetto?
Grazie a chi mi risponderà
1 Risposta -
@pinguinone a mio avviso, sul lato "seo" l'unica cosa che ti può importare è la parte dei CWV, quindi il discorso è servire il sito "passando" i cwv.
riguardo il numero di richieste, se ti riferisci alle indicazioni di PSI, non mi affiderei molto o troppo ai "suggerimenti" che dice, o meglio sarebbero da prendere e applicare a seconda dei casi, stessa cosa per la minificazione, ne parli come se fosse una azione dovuta e indispensabile, ma dipende da quando è grande il file iniziale e da quando diventa una volta minificato, e quindi anche da come lo hai creato/compilato ecc ( se lo hai scritto tu, se arriva da esterno pace amen)
quindi se parti da un .js o un .css di 4KB e minificato diventa 3,5KB quanto guadagni in tempo di download su una linea LTE ?
stessa cosa per il numero di richieste al server: se il tuo sito viene servito da http1.1 potresti avere problemi, allo stesso modo se il tuo sito verrà visitato molto spesso. ma con http2 , più il fatto che molte risorse ti vanno in cache, le richieste al server diminuiscono ed in ogni caso la risultante sarà più veloce che un unico file.
quello che ti servirebbe invece fare, a mio avviso, è capire quali sono gli asset da "render blocking" e far si che non blocchino le altri risorse da scaricare. quindi metti il caso che hai un unico JS ( o css che sia) che fa render blocking, il browser deve attendere che lo scarichi tutto prima di passare ad altre risorse ( la sto facendo breve e piu semplice possible), mentre se avessi 3 file diversi, magari uno solo blocca, gli altri vanno via lisci ( anche qui la faccio semplice)
in realtà l'ideale sarebbe avere file divisi cosi da poter usare async, defer, delay, early hints, preload ecc ecc
poi lavori se possibile cosi:
js o css che servono su tutte le pagine li fai caricare singolarmente o Comunque divisi dagli asset singoli per necessità di paginajquery dovrai caricarlo sempre, slider lo carichi solo su home, carosello su portfolio, popup su contatti, bla bla bla
poi va da se che l'ideale sarebbe dare priorità di caricamento agli asset critici o above the fold
quindi se jquery lo chiami per primo perche è necessario per eseguire i js dello slider, e subito dopo lo slider perche lo hai nella hero above the fold della home page, gli asset del carosello che per esempio viene visualizzato vero la fine della homepage, li puoi deferire o mettere in lazy load delay e quel che ti pare ecc
riguardo il css, ed in particolare il css critico, se riesci a crearlo via script ecc, anche li valuta bene se metterlo inline all'inizio della pagina ( che poi non verrà cachato) o se fare in modo di creare un css file fisico del critical per ciascuna pagina, cosi che lo puoi servire in preload e cachare ecc
1 Risposta -
@shazarak giusto per portare esempi esplicativi scritti meglio delle mie spiegazioni pietose
https://docs.wp-rocket.me/article/1009-configuration-for-http-2