Configurare il CSS critico

Che cosa fa il modulo — e che cosa non fa

Per ogni modello di pagina Kakapo richiama via HTTP una vera pagina di esempio del tuo sito (solo nell'area di amministrazione o via cron, mai durante la costruzione della pagina di un visitatore), legge i fogli di stile locali lì collegati direttamente dal disco e verifica ogni singola regola con DOMXPath rispetto al documento. Ne nascono due risultati: il CSS critico, che viene inserito inline nell'head, e l'elenco delle regole che su quel modello non hanno colpito nemmeno un elemento.

Non viene renderizzato nulla. Non c'è alcun browser, alcun viewport e alcuna posizione di scorrimento. «Visibile in alto» è un'approssimazione secondo una regola dichiarata: tutti gli elementi al di sotto di body vengono numerati, il primo 30 per cento (impostazione predefinita, regolabile tra 5 e 90) vale come in alto, più tutto ciò che si trova all'interno dei punti di riferimento inseriti. Vengono sempre inclusi html, body, :root e @font-face nonché le @keyframes che una regola critica richiama tramite animation. Le regole che agiscono solo tramite stati (:hover, :focus, :active) restano fuori, e così anche @media print. Dove il procedimento arriva al suo limite, arrotonda per eccesso: la regola vale come colpita. Qualche kilobyte di troppo costa meno di una regola mancante e dello sfarfallio.

Verificare i requisiti prima di analizzare

Due cose devono essere in ordine. Primo, l'estensione PHP dom/libxml — il modulo non la verifica tramite class_exists(), ma costruisce un documento in miniatura e lo interroga davvero. Il motivo: alcuni hoster impostano disable_classes=DOMDocument, allora class_exists() continua a rispondere «sì», ma il new fallisce. Se l'estensione manca, «Analizza» e «Aggiorna ogni giorno» sono bloccati e accanto è indicato il motivo.

In secondo luogo il loopback: il sito deve raggiungere se stesso via HTTP. Per questo c'è il pulsante «Verifica il loopback» nella sezione Requisiti; memorizza codice HTTP, dimensione della risposta e durata. Se fallisce, fallisce ogni analisi — cause tipiche sono un firewall davanti al sito, una protezione Basic Auth sull'ambiente di staging oppure un nome host che internamente non si risolve.

Ciò che l'analisi non può leggere non viene nemmeno differito: i fogli di stile di host esterni, di un CDN o di Google Fonts restano invariati e continuano a bloccare il rendering. È la via lenta, ma sicura.

Procedere modello per modello

Ci sono sette modelli: Pagina iniziale, Pagina del blog, Singolo articolo, Pagina statica, Archivio, Risultati di ricerca e Pagina di errore 404. Ognuno viene analizzato singolarmente e abilitato singolarmente. Se la tua pagina iniziale mostra l'elenco degli articoli, «Pagina del blog» non è applicabile — l'interruttore resta bloccato, perché sarebbe senza effetto. Se non esiste alcun articolo pubblicato o nessuna pagina, manca la pagina di esempio e anche quel modello resta bloccato.

La via consigliata: prima «Analizza tutte» oppure analizza singolarmente. Poi apri per un modello «Anteprima» e «senza» in due schede — è la stessa pagina reale una volta con e una volta senza trattamento, visibile solo per gli amministratori che hanno effettuato l'accesso e solo con una chiave monouso valida nell'indirizzo. Per questo l'interruttore principale non deve essere acceso. Lo sfarfallio durante la costruzione lo vedi nel modo più affidabile in una scheda a sé con connessione rallentata, non nel riquadro incorporato.

Solo quando il confronto appare pulito abiliti il modello e accendi l'interruttore principale. Parte in modalità di prova: lì vedono il trattamento solo gli amministratori che hanno effettuato l'accesso, per tutti gli altri la pagina resta invariata. Passi a «in produzione» solo dopo aver esaminato più modelli.

I quattro freni e le liste di eccezioni

«Carica in differita i fogli di stile analizzati» è il vero risparmio di tempo. Spento significa: il CSS critico si aggiunge in più inline, per il resto tutto rimane com'era — senza rischi, ma senza guadagno. Acceso significa: i fogli di stile analizzati vengono caricati con media="print" più un ripristino onload, con un duplicato noscript per i visitatori senza JavaScript. Viene differito esclusivamente ciò che è stato davvero letto, e solo se handle e indirizzo del file corrispondono ancora a ciò che è stato analizzato.

«Sospendi in caso di file sorgente modificati» memorizza per ogni file analizzato l'ora di modifica e la dimensione nonché il tema attivo. Se qualcosa cambia, non viene trattato nulla invece di procedere con CSS critico forse sbagliato — nel codice sorgente compare allora una nota con il motivo.

Tre campi di testo sono l'uscita di emergenza. URL da escludere: una riga per percorso, «*» come segnaposto, queste pagine non vengono mai trattate (tipicamente /checkout*, /mein-konto*). Non differire mai questi fogli di stile: un handle di WordPress per riga, preimpostati admin-bar e dashicons. Punti di riferimento: un selettore per riga, tutto ciò che vi si trova dentro vale come in alto — preimpostati sono header, [role="banner"], .site-header, #masthead, nav, .main-navigation, .site-branding, .hero e h1. Le righe non valutabili vengono rifiutate invece che salvate in silenzio.

Una modifica alla quota «in alto» o ai punti di riferimento ha effetto solo dopo una nuova analisi. Tutto il resto svuota subito la cache delle pagine, perché lì si trova HTML già pronto con il vecchio stato.

Quando qualcosa va storto

«Tempo a disposizione esaurito»: l'esecuzione ha raggiunto i 25 secondi o il limite di tempo di PHP. Il rapporto è salvato, il CSS critico consapevolmente no — un CSS critico incompleto provocherebbe uno sfarfallio. Il messaggio indica il file in cui ci si è fermati. Analizza di nuovo oppure togli un foglio di stile molto grande tramite la lista delle eccezioni.

«Ha risposto con HTTP …»: la pagina di esempio non ha restituito il codice atteso (200, per la pagina di errore 404). Non viene salvato nulla. Verifica se la pagina è raggiungibile nel browser e se davanti a essa c'è una protezione.

Un modello è su «obsoleto»: un file CSS analizzato è cambiato oppure il tema è stato sostituito. Analizza di nuovo. Se c'è scritto «quota diversa», il modello è stato creato con un valore percentuale diverso da quello impostato ora — anche in questo caso analizza di nuovo.

Affinché tutto ciò non resti lavoro manuale, c'è «Controlla e aggiorna ogni giorno». L'esecuzione via cron analizza solo i modelli già abilitati e obsoleti; non attiva mai nulla e non crea alcuna analisi per un modello non abilitato. Il suo ultimo risultato compare come nota nella sezione Cintura di sicurezza.

Se una pagina resta comunque irrequieta, aiuta uno sguardo al codice sorgente: lì c'è un commento con il modello trattato e lo stato (anteprima, modalità di prova, in produzione) oppure il motivo per cui consapevolmente non è stato trattato.