WordPress carica CSS e JavaScript che non servono? Come scoprirlo e risolverlo

Uno dei problemi che incontro più spesso nell’ottimizzazione di un sito WordPress non riguarda file particolarmente pesanti, ma file caricati nelle pagine in cui non servono.

Uno slider utilizzato solamente nella homepage può portarsi dietro CSS e JavaScript anche negli articoli del blog. Lo stesso può succedere con gallery, form di contatto, mappe, librerie di icone e script appartenenti ai plugin.

Singolarmente possono sembrare pochi KB. Sommando tutte queste risorse, però, il browser finisce per scaricare, interpretare ed eseguire codice completamente inutile per quella pagina.

Su un tema WordPress custom preferisco quindi seguire una regola molto semplice:

una risorsa dovrebbe essere caricata solamente dove viene realmente utilizzata.

Vediamo come verificare se questo problema è presente e come intervenire direttamente da WordPress.

Il problema: gli enqueue globali

Immaginiamo di utilizzare Swiper per uno slider presente solamente nella homepage.

Un’implementazione di questo tipo funziona:

function theme_assets() {
    wp_enqueue_style(
        'swiper',
        get_template_directory_uri() . '/assets/css/swiper-bundle.min.css',
        array(),
        '11.0'
    );
    wp_enqueue_script(
        'swiper',
        get_template_directory_uri() . '/assets/js/swiper-bundle.min.js',
        array(),
        '11.0',
        true
    );
}
add_action('wp_enqueue_scripts', 'theme_assets');

Il problema è che WordPress esegue questi enqueue in tutto il sito.

Swiper verrà quindi richiesto anche visitando:

• un articolo;
• una pagina FAQ;
• la pagina contatti;
• una pagina che non contiene nessuno slider.

Il codice è corretto dal punto di vista funzionale, ma non è particolarmente efficiente.

Prima di modificare WordPress: verificare cosa viene realmente caricato

Prima di intervenire sul codice preferisco verificare il comportamento reale della pagina.

Chrome DevTools è sufficiente.

Apro DevTools → Network, ricarico la pagina e utilizzo i filtri CSS e JS.

Se sto analizzando una pagina che non contiene slider ma trovo:

swiper-bundle.min.css
swiper-bundle.min.js

ho già individuato due richieste che probabilmente possono essere eliminate.

Il controllo diventa ancora più interessante confrontando pagine differenti dello stesso sito.

Per esempio:

Homepage
✓ style.css
✓ home.css
✓ swiper.css
✓ swiper.js
Articolo blog
✓ style.css
✗ home.css
✗ swiper.css
✗ swiper.js

Questa è la situazione che voglio ottenere.

Non significa necessariamente avere meno CSS nell’intero sito. Significa inviare a ogni pagina solamente ciò di cui ha bisogno.

Caricare Swiper solamente nella homepage

WordPress mette già a disposizione le conditional tag necessarie.

Nel caso della homepage possiamo utilizzare is_front_page():

function theme_assets() {
    wp_enqueue_style(
        'main-style',
        get_template_directory_uri() . '/assets/css/style.css',
        array(),
        '1.0'
    );
    if (is_front_page()) {
        wp_enqueue_style(
            'swiper',
            get_template_directory_uri() . '/assets/css/swiper-bundle.min.css',
            array(),
            '11.0'
        );
        wp_enqueue_script(
            'swiper',
            get_template_directory_uri() . '/assets/js/swiper-bundle.min.js',
            array(),
            '11.0',
            true
        );
    }
}
add_action('wp_enqueue_scripts', 'theme_assets');

Ora Swiper non viene nemmeno inserito nell’HTML delle altre pagine.

Questo è un dettaglio importante.

Non stiamo chiedendo al browser di scaricare prima il file e poi ignorarlo.

La richiesta HTTP non viene proprio generata.

Caricare un CSS solamente in una determinata pagina

Lo stesso principio può essere applicato ai fogli di stile.

Supponiamo di avere una landing page con un CSS dedicato:

if (is_page('realizzazione-landing-page-firenze')) {
    wp_enqueue_style(
        'landing-page',
        get_template_directory_uri() . '/assets/css/landing-page.css',
        array(),
        '1.0'
    );
}

Il browser riceverà landing-page.css esclusivamente quando visita quella pagina.

Per siti con template molto differenti tra loro questo approccio permette di evitare la creazione di un unico enorme style.css.

E se il CSS serve a un intero tipo di contenuto?

Possiamo utilizzare is_singular().

Per esempio, se ho creato un Custom Post Type chiamato experience:

if (is_singular('experience')) {
    wp_enqueue_style(
        'single-experience',
        get_template_directory_uri() . '/assets/css/single-experience.css',
        array(),
        '1.0'
    );
}

Il CSS verrà caricato solamente nelle pagine delle singole esperienze.

Lo stesso vale per il relativo JavaScript:

if (is_singular('experience')) {
    wp_enqueue_script(
        'experience',
        get_template_directory_uri() . '/assets/js/experience.js',
        array(),
        '1.0',
        true
    );
}

È particolarmente utile quando il sito contiene Custom Post Type con funzionalità che il resto del progetto non utilizza.

Un caso più interessante: caricare lo script solo se il componente esiste

Le conditional tag di WordPress risolvono molti casi, ma possiamo spingerci oltre.

Immaginiamo una gallery opzionale gestita tramite ACF.

Non tutte le pagine dello stesso template hanno necessariamente una gallery.

Possiamo quindi controllare direttamente il campo:

if (is_singular('experience') && get_field('gallery')) {
    wp_enqueue_style(
        'swiper',
        get_template_directory_uri() . '/assets/css/swiper-bundle.min.css',
        array(),
        '11.0'
    );
    wp_enqueue_script(
        'swiper',
        get_template_directory_uri() . '/assets/js/swiper-bundle.min.js',
        array(),
        '11.0',
        true
    );
}

In questo caso non stiamo più dicendo:

Carica Swiper nelle pagine Experience.

Stiamo dicendo:

Carica Swiper nelle pagine Experience solamente quando esiste effettivamente una gallery.

È una differenza piccola nel codice, ma rappresenta bene il modo in cui preferisco costruire un tema WordPress.

Attenzione agli script dei plugin

Il problema non riguarda solamente il tema.

Alcuni plugin registrano i propri asset globalmente.

Può quindi capitare di trovare nella pagina CSS o JavaScript appartenenti a funzionalità che vengono utilizzate solamente in una sezione del sito.

In questi casi possiamo utilizzare wp_dequeue_style() e wp_dequeue_script().

Esempio:

function remove_unused_assets() {
    if (!is_page('contatti')) {
        wp_dequeue_style('plugin-form-style');
        wp_dequeue_script('plugin-form-script');
    }
}
add_action('wp_enqueue_scripts', 'remove_unused_assets', 100);

Il valore 100 assegna una priorità più bassa nell’esecuzione dell’hook, permettendo al nostro codice di intervenire dopo che il plugin ha registrato le proprie risorse.

Ma qui bisogna fare attenzione

Non consiglio di copiare un wp_dequeue_script() trovato online senza sapere esattamente cosa fa quella risorsa.

Uno script apparentemente inutile potrebbe essere una dipendenza di un’altra funzionalità.

Prima di rimuoverlo verifico quindi sempre:

1. handle registrato da WordPress;
2. dipendenze;
3. pagine in cui viene utilizzato;
4. console JavaScript dopo la rimozione;
5. comportamento desktop e mobile.

L’obiettivo non è ottenere meno richieste a qualsiasi costo.

L’obiettivo è eliminare solamente quelle realmente inutili.

Come verifico se l’ottimizzazione ha funzionato

Dopo ogni modifica torno nel pannello Network di Chrome.

Prima:

23 richieste CSS/JS

Dopo:

18 richieste CSS/JS

Ma il numero delle richieste, da solo, non è sufficiente.

Controllo anche:

• KB trasferiti;
• dimensione complessiva delle risorse;
• eventuali errori nella Console;
• rendering della pagina;
• funzionamento di slider e componenti;
• PageSpeed Insights.

Una pagina che passa da 23 a 18 richieste ma perde una funzionalità non è stata ottimizzata: è stata semplicemente rotta.

Un errore che ho fatto anch’io: concentrarmi troppo sulla dimensione dei file

Quando si parla di performance WordPress è naturale guardare subito il peso delle immagini o cercare di ridurre qualche KB dal CSS.

Durante alcuni test mi sono però reso conto che era più efficace chiedermi:

“Perché sto caricando questo file?”

invece di:

“Come posso rendere questo file più piccolo?”

Se una libreria JavaScript da 40 KB non serve nella pagina, comprimerla a 30 KB è certamente positivo.

Non caricarla affatto è meglio.

Questo principio mi ha portato a gestire alcune librerie, come gli slider, solamente nelle pagine in cui vengono effettivamente utilizzate.

Meno plugin di ottimizzazione, più controllo sul tema

I plugin di cache e performance possono essere strumenti molto validi, ma non dovrebbero compensare una gestione poco attenta delle risorse del tema.

Quando sviluppo un sito WordPress custom preferisco intervenire prima sull’architettura:

caricare meno codice, caricarlo nel posto giusto e solo successivamente ottimizzare quello che rimane.

È anche uno dei vantaggi principali dello sviluppo di un tema WordPress su misura.

Conoscendo esattamente la struttura del progetto posso decidere che una determinata libreria serve in homepage, un CSS appartiene solamente a un Custom Post Type e uno script deve essere eseguito esclusivamente quando un determinato componente è presente.

La performance, in questo modo, non viene aggiunta alla fine tramite un plugin.

Fa parte direttamente del modo in cui il sito viene sviluppato.