Preload, preconnect e fetchpriority in WordPress: quando usarli e quando evitarli

Quando si cerca di migliorare le prestazioni di un sito WordPress, prima o poi si incontrano attributi e resource hint come preload, preconnect e fetchpriority.

L’obiettivo è apparentemente semplice: dire al browser quali risorse sono importanti e permettergli di caricarle prima.

Il problema è che dare priorità a troppe risorse può produrre l’effetto opposto.

Il browser dispone infatti di una quantità limitata di connessioni e banda. Se indichiamo come prioritarie risorse che in realtà non lo sono, queste possono entrare in competizione con CSS, immagini e altri elementi realmente necessari per visualizzare la parte iniziale della pagina.

Vediamo quindi a cosa servono preload, preconnect e fetchpriority e, soprattutto, quando ha senso utilizzarli in WordPress.

Preload: caricare prima una risorsa importante

Il preload permette di comunicare al browser che una determinata risorsa sarà necessaria a breve.

Un esempio classico è un font utilizzato nella parte iniziale della pagina:

<link
    rel="preload"
    href="/wp-content/themes/mio-tema/fonts/inter.woff2"
    as="font"
    type="font/woff2"
    crossorigin
>

Normalmente il browser scopre il font dopo aver scaricato e analizzato il CSS.

Con il preload possiamo anticiparne la scoperta.

Può essere utile anche per l’immagine principale della hero:

<link
    rel="preload"
    as="image"
    href="/wp-content/themes/mio-tema/images/hero.webp"
>

Ma qui nasce uno degli errori più frequenti.

Non bisogna precaricare tutto

Aggiungere il preload a molte immagini, font e file JavaScript non significa necessariamente rendere il sito più veloce.

Ogni risorsa precaricata compete con le altre risorse necessarie durante il caricamento iniziale.

Il preload dovrebbe quindi essere riservato a poche risorse realmente critiche, ad esempio:

• il font principale visibile immediatamente;
• l’immagine responsabile dell’LCP;
• una risorsa fondamentale che il browser scoprirebbe altrimenti troppo tardi.

Se una risorsa viene utilizzata soltanto nella parte bassa della pagina, precaricarla generalmente non porta alcun vantaggio.

Preconnect: anticipare una connessione esterna

preconnect ha uno scopo diverso.

Non serve a scaricare direttamente una risorsa, ma permette al browser di iniziare prima alcune operazioni necessarie per collegarsi a un dominio esterno.

Per esempio:

<link rel="preconnect" href="https://www.googletagmanager.com">

Prima di scaricare una risorsa da un dominio esterno possono essere necessarie diverse operazioni, come risoluzione DNS, apertura della connessione TCP e negoziazione TLS.

Con preconnect possiamo anticipare parte di questo lavoro.

È quindi particolarmente interessante quando sappiamo che una risorsa importante verrà richiesta molto presto da un dominio differente da quello del sito.

Quando evitare preconnect

Anche in questo caso vale la stessa regola: non aggiungerlo indiscriminatamente a tutti i domini esterni.

Se nella pagina sono presenti servizi esterni utilizzati soltanto dopo un’interazione dell’utente o molto più avanti durante il caricamento, aprire preventivamente una connessione potrebbe essere inutile.

Meglio individuare prima quali domini vengono effettivamente contattati durante il caricamento iniziale.

Chrome DevTools, nella scheda Network, è uno degli strumenti più semplici per verificarlo.

Fetchpriority: indicare la priorità di una risorsa

fetchpriority permette invece di fornire al browser un’indicazione sulla priorità con cui dovrebbe recuperare una determinata risorsa.

Un caso particolarmente interessante riguarda l’immagine principale della pagina:

<img
    src="/images/hero.webp"
    alt="Realizzazione siti web"
    width="817"
    height="577"
    fetchpriority="high"
>

Se quell’immagine rappresenta l’elemento LCP della pagina, fetchpriority="high" può aiutare il browser a riconoscerne prima l’importanza.

In WordPress potremmo avere, ad esempio:

<img
    src="<?php echo esc_url(get_field('hero_image')); ?>"
    alt="<?php echo esc_attr(get_field('hero_image_alt')); ?>"
    width="817"
    height="577"
    loading="eager"
    fetchpriority="high"
>

Questa configurazione può avere senso per l’immagine principale visibile immediatamente nella hero.

Fetchpriority=”high” non va utilizzato su tutte le immagini

Un errore piuttosto comune è pensare:

Se high significa prioritario, lo aggiungo a tutte le immagini importanti.

Ma se tutto diventa prioritario, la priorità perde significato.

In una pagina con dieci immagini non avrebbe senso assegnare:

fetchpriority="high"

a tutte e dieci.

Normalmente è più utile riservarlo alla risorsa che ha realmente un ruolo importante nel rendering iniziale, spesso proprio l’immagine LCP.

Le immagini più in basso nella pagina possono continuare a utilizzare il normale lazy loading:

<img
    src="/images/portfolio.webp"
    alt="Progetto sito web"
    loading="lazy"
    width="800"
    height="600"
>

Preload e fetchpriority sono la stessa cosa?

No.

È facile confonderli perché entrambi possono essere utilizzati per ottimizzare il caricamento di una risorsa importante.

Il preload permette principalmente di far scoprire anticipatamente una risorsa.

fetchpriority, invece, fornisce un’indicazione sulla priorità con cui recuperarla.

In alcuni casi possono essere utilizzati insieme, ma non significa che sia sempre necessario farlo.

Prima di aggiungere entrambe le ottimizzazioni è importante capire come il browser sta già caricando quella risorsa.

Attenzione al lazy loading dell’immagine LCP

Un’altra situazione che incontro spesso durante l’ottimizzazione di WordPress riguarda il lazy loading applicato automaticamente alle immagini.

Il lazy loading è molto utile per le immagini che si trovano più in basso nella pagina:

loading="lazy"

ma può essere controproducente sull’immagine principale della hero.

Se l’immagine è immediatamente visibile e rappresenta l’LCP, generalmente vogliamo che il browser inizi a scaricarla il prima possibile.

In questo caso può avere più senso:

loading="eager"
fetchpriority="high"

riservando loading="lazy" alle immagini non immediatamente visibili.

Come aggiungere un preload in WordPress

Se stiamo sviluppando un tema WordPress custom, possiamo aggiungere un preload tramite wp_head.

Per esempio:

function custom_preload_resources() {
    if (is_front_page()) {
        ?>
        <link
            rel="preload"
            href="<?php echo esc_url(get_template_directory_uri() . '/assets/fonts/inter.woff2'); ?>"
            as="font"
            type="font/woff2"
            crossorigin
        >
        <?php
    }
}
add_action('wp_head', 'custom_preload_resources', 1);

In questo esempio il preload viene aggiunto soltanto nella homepage.

Questo è importante.

Se quel font o quella specifica risorsa non è necessaria in tutte le pagine, non c’è motivo di aggiungere automaticamente il relativo preload all’intero sito.

Lo stesso principio può essere applicato utilizzando condizioni WordPress come:

is_front_page()
is_page()
is_singular()
is_post_type_archive()

In questo modo possiamo controllare con precisione dove effettuare l’ottimizzazione.

Come capire se queste ottimizzazioni stanno realmente funzionando

Il punto più importante è non considerare preload, preconnect e fetchpriority come ottimizzazioni da aggiungere automaticamente.

Prima bisogna misurare.

Chrome DevTools permette di analizzare l’ordine con cui vengono richieste le risorse nella scheda Network.

PageSpeed Insights può invece aiutare a individuare problemi relativi all’LCP e alla scoperta tardiva delle risorse principali.

Una procedura corretta potrebbe essere:

1. eseguire un test iniziale;
2. individuare la risorsa critica;
3. applicare una singola ottimizzazione;
4. svuotare eventuali cache;
5. ripetere più volte il test;
6. confrontare i risultati.

È meglio evitare di aggiungere contemporaneamente dieci modifiche diverse, perché diventa difficile capire quale abbia realmente prodotto un miglioramento.

Conclusione

preload, preconnect e fetchpriority sono strumenti molto utili per ottimizzare le prestazioni di WordPress, ma devono essere utilizzati in maniera selettiva.

L’obiettivo non è dire al browser di caricare tutto prima.

L’obiettivo è aiutarlo a capire cosa deve essere caricato prima.

Su un sito WordPress ben ottimizzato possono bastare poche indicazioni mirate: una corretta gestione dell’immagine LCP, eventualmente il preload di una risorsa realmente critica e un preconnect verso un dominio esterno utilizzato nelle prime fasi del caricamento.

Come spesso accade nell’ottimizzazione delle performance, aggiungere più codice non significa automaticamente ottenere un sito più veloce.

Prima si misura, poi si interviene.