Un utente ha chiesto informazioni su Autoptimize di Wordpress

Allineato “sopra la cartella CSS”, ma il file del sistema operativo css è ancora caricato prima del ritorno.

Un utente ha chiesto 👇

Sto utilizzando Autoptimize su alcuni siti Web, incluso un sito Web in cui ho un account criticcss.com e utilizzo la potenza Critical CSS.

Su entrambi i siti web, ho abilitato l’opzione “Inline over the CSS folder” e ho incollato il codice CSS generato. Ma quando guardo il sorgente sulla pagina, vedo che il CSS ATF è caricato correttamente nella testina e quindi ha appena caricato il file CSS “autoptimize_xxx.css” (nel mio caso si chiama autoptimize_113bf4ce64c9d146a7e51ecafe85f562.css).

Quindi su Google Page Insights for Mobile, vedo ancora un errore “Rinvia CSS inutilizzati” con il file “autoptimize_113bf4ce64c9d146a7e51ecafe85f562.css” elencato come problema principale.

Ciò accade su un sito Web con l’accensione CSS Critical e su un altro sito Web senza la potenza in cui ho incollato manualmente il codice CSS.

Puoi vedere il problema che si verifica su: https://oneflow.com/

Lanciatore di thread

(@ zach21uk)

2 anni fa

Immagine del problema qui: https://imgur.com/a/oVvzB8p

Autore del plugin

(@optimizingmatters)

2 anni fa

Quando si utilizza “inline & deferral” (possibilmente con il plug-in CSS automatizzato critico) il CSS è in linea in modo critico e il CSS completo non viene tecnicamente posticipato ma è “precaricato”, il che significa che viene caricato senza che sia un blocco di rendering (che è consigliato GPSI separatamente). AO utilizza loadCSS Filamentgroup per questo scopo.

Il vantaggio dell’utilizzo di “precaricamento” è che la pagina sotto la cartella ha uno stile il più rapidamente possibile senza il blocco CSS. Posticiparlo (come ha fatto AO alcune versioni fa) rendeva più probabile che l’utente scorresse verso il basso fino a una parte della pagina che non era ancora stata disegnata. Dal momento che il precaricamento dell’intero SEC non ostacola il rendering, c’è poco vantaggio nel posticiparlo semplicemente e lo svantaggio può essere significativo.

Inoltre, Google ha chiarito la sua posizione con decidere di rinominare l’opportunità come “sbarazzarsi di SEC inutilizzato” nel Faro (da qui GPSI), quindi la questione non è realmente “differita”.

Spero che questo chiarisca
onesto

Lanciatore di thread

(@ zach21uk)

2 anni fa

Franco,

Grazie per la tua risposta dettagliata. Quale metodo di ricarica viene utilizzato? È il metodo ““O qualche altro metodo?

In tal caso, dove trovo il codice precaricato quando esploro la pagina Web e puoi dirmi dove si trova il codice che lo alimenta nei file del plug-in?

Non sono sicuro o sicuro che le cose stiano andando come dovrebbero.

Con l’aggiunta di Critical CSS, Critical CSS viene generato su ogni pagina del sito (es. CSS richiesto per il rendering della pagina). Pertanto, “autoptimize_xxx.css” non deve essere affatto necessario, o almeno fino a più tardi nel processo di caricamento. Quando il file viene caricato e con quel file contenente CSS per l’intero sito, PageSpeed ​​identifica correttamente che è richiesto un CSS non caricato per quella pagina e quindi l’avviso “Aggiungi CSS inutilizzato”.

Senza il plug-in, il plug-in fornisce un solo campo per l’inserimento manuale di CSS critici e quindi ho scelto (e la maggior parte delle persone sceglierebbe) di inserire CSS critici per la home page. Pertanto, anche la homepage stessa non dovrebbe aver bisogno di “autoptimize_xxx.css” (affatto, o fino a più tardi nel processo di caricamento), come dovrebbe essere ciò che è necessario per rendere disponibile la pagina nella SEC critica.

Proverò a modificare il nucleo del plug-in per vedere se posso caricare il file in modo che non attivi l’avviso in PageSpeed, ma voglio ulteriori approfondimenti che puoi offrire perché penso che sì, un problema chiave qui è come il plugin gestisce i CSS critici rispetto al file CSS ottimizzato in generale.

Grazie
Zach

—-
Zach Nicodemous.
Sviluppatore: http://codeable.io/zach-nicodemous

Autore del plugin

(@optimizingmatters)

2 anni fa

AO utilizza l’approccio LoadCSS Filamentgroup per caricare l’intero CSS, che aggiunge un attributo di caricamento. al <link rel=preload etichetta; onload="this.onload=null;this.rel='stylesheet'" e che è polyfill per i browser che non supportano ancora rel = preload.

Posso seguire e essere d’accordo con la maggior parte di ciò che stai dicendo e ne stavo discutendo lì Edizione LoadCSS e stavo cercando di caricare il CSS da solo un po ‘più tardi usando i filtri AO invece di cambiare core secondo questo Gist, sentiti libero di usarlo come punto di partenza 😉

Alla fine; il JS in questa risposta StackOverflow sembra molto interessante, perché include lo scrollevent (il che ha senso; un utente che scorre durante il caricamento della pagina dovrebbe ottenere il CSS completo al più presto in modo che non appaia materiale non specificato).

Fammi sapere come vanno le cose, sarò felice di testare / rivedere tutto ciò che stai facendo e se puoi diramare sarò felice di accettarlo come PR su Github! 🙂

onesto

Was this helpful?

0 / 0

Lascia un commento 0

Your email address will not be published. Required fields are marked *