Il tuo sito è lento e GTMetrix mostra più di 130 richieste HTTP per pagina?

Non è un numero astratto uscito da un report. Ogni richiesta è una chiamata del browser al server per un file: uno script, un foglio di stile, un'immagine o un font. Più richieste ci sono, più a lungo i visitatori fissano una pagina bianca. Secondo Portent, un ritardo di caricamento da 0 a 3 secondi riduce la conversione del 2,5%. E ogni secondo in più oltre quello costa un ulteriore 4,4%.

Il problema delle richieste HTTP non è che esistono. È che la maggior parte dei siti WordPress ne genera molte più del necessario. Ecco cinque passaggi concreti per ridurre il numero di richieste senza riscrivere il sito da zero.

💡 Panoramica rapida:

• Rimuovi plugin e temi inutilizzati che creano richieste extra su ogni pagina
• Ottimizza le immagini: comprimi i file, elimina le immagini non usate, unisci le icone in sprite
• Unisci CSS e JavaScript in 1-2 file e attiva la minificazione
• Imposta il caricamento differito per gli script che bloccano il rendering della pagina
• Attiva caching e CDN così che i visitatori di ritorno non ricarichino l'intero sito

Step 1. Rimuovi il superfluo

Ogni plugin installato porta con sé dei file. PHP, CSS, JavaScript: ognuno di questi genera una richiesta HTTP al caricamento della pagina. Venti plugin significano quasi un centinaio di richieste solo all'avvio, prima ancora di qualsiasi contenuto.

La prima cosa da fare è un audit. Apri Plugin → Plugin installati e chiediti onestamente: quali sono critici per il funzionamento del sito e quali sono lì solo "per sicurezza"? Quell'analizzatore SEO che hai installato un anno fa e aperto due volte è un candidato alla rimozione. Anche il plugin per le icone social, se hai già inserito i link nel footer.

Una categoria a parte sono i plugin che si connettono a server di terze parti. Live chat, radio in streaming, notifiche push. Ciascuno di questi plugin crea richieste HTTP esterne aggiuntive verso server di terze parti. Elimina tutto ciò senza cui il sito può funzionare. Ti serve una volta al mese? Installalo per un giorno e poi rimuovilo.

La stessa regola vale per i temi. In Aspetto → Temi, tieni solo il tema attivo e uno di backup (per esempio, il default Twenty Twenty-Five). Elimina il resto.

Se un plugin serve ma solo su una pagina specifica, caricalo in modo selettivo. Asset CleanUp: Page Speed Booster fa esattamente questo. È un plugin gratuito con oltre 100.000 installazioni attive e una valutazione di 4,7 su WordPress.org.

Il plugin scansiona la pagina, mostra un elenco dei file CSS e JS caricati e ti permette di disabilitare file specifici su determinate pagine, tipi di contenuto o sull'intero sito. Ti serve Contact Form 7 solo sulla pagina contatti? Deselezionalo ovunque altrove, e i suoi script non verranno caricati dove il modulo non è usato.

🔗 Asset CleanUp su WordPress.org

Già che ci sei, ottimizza il database. Dopo aver ripulito i plugin, le loro impostazioni e i record restano nelle tabelle e vanno rimossi. Controlla anche i link non funzionanti: ogni redirect è una richiesta HTTP in più.

Per vedere chiaramente la portata del problema prima e dopo, testa il tuo sito su GTMetrix:

La prima esecuzione mostra la baseline: numero di richieste, dimensione totale della pagina, tempo di caricamento. Dopo ogni passaggio di questo articolo, esegui di nuovo il test. Così vedrai quali modifiche hanno avuto l'impatto maggiore.

Step 2. Ottimizza le immagini

Le immagini sono il "peso" maggiore su una pagina WordPress media. Secondo HTTP Archive, le immagini rappresentano circa il 44% della dimensione totale della pagina su desktop. E ogni immagine è una richiesta HTTP.

Inizia rimuovendo i file inutilizzati. In Media → Libreria, filtra per "Non collegato". Sono le immagini non associate a nessun articolo. Se non sono usate nel tema o nel footer, eliminale.

Poi viene la compressione. Plugin come WP Compress la gestiscono automaticamente: quando carichi un'immagine, questa passa attraverso un ottimizzatore cloud, viene compressa senza perdita visibile di qualità e convertita in WebP o AVIF. Questi formati sono sensibilmente più leggeri del JPEG a parità di qualità visiva. Secondo Google, WebP riduce la dimensione del file in media del 25-35% rispetto al JPEG.

WP Compress ha oltre 10.000 installazioni attive, una valutazione di 4,5 su 5 e più di 1,1 milioni di download su WordPress.org. Le prime 100 immagini sono gratis, abbastanza per vedere la differenza.

🔗 WP Compress su WordPress.org

La compressione da sola non riduce il numero di richieste HTTP. Ma riduce la dimensione di ogni file, il che significa meno tempo per trasferirlo. Combinata con gli altri passaggi, produce un miglioramento di velocità percepibile.

Sprite CSS: un file invece di dieci

Se hai una dozzina di piccole icone su una pagina (social network, frecce, stelle di valutazione), ognuna viene caricata come richiesta separata. Uno sprite CSS risolve il problema: tutte le icone sono unite in un unico file e i CSS mostrano il frammento necessario.

Ecco come funziona: cinque immagini significano cinque richieste al server. Quelle stesse cinque immagini unite in un unico sprite significano una richiesta. Strumenti online come CSS Sprite Generator possono creare sprite per te. È richiesta una conoscenza di base dei CSS per impostare il background-position per ciascuna icona.

Nota: se il tuo server supporta HTTP/2, i file vengono caricati in modo asincrono all'interno di un'unica connessione. In quel caso, i vantaggi dello sprite sono meno evidenti. Ma in pratica, una dozzina di icone in un unico file si carica comunque più velocemente di dieci file separati.

Step 3. Unisci e minifica CSS e JavaScript

Un tipico sito WordPress ha oltre 40 file JS e oltre 20 file CSS. Ognuno è una richiesta HTTP separata. Si arriva a oltre 60 chiamate al server solo per script e stili, tutti caricati prima che appaia qualsiasi contenuto.

La minificazione rimuove tutto il superfluo dai file: spazi, interruzioni di riga, commenti. Il file diventa più leggero, ma il numero di richieste HTTP resta lo stesso.

L'unione fonde più file in uno. Cinque file CSS diventano due (uno per above-the-fold, uno per tutto il resto). Cinque file JS, stessa cosa. E invece di dieci richieste, si scende a due o tre.

Lo strumento gratuito più diffuso per questo è Autoptimize. Un plugin con un milione di installazioni attive e una valutazione di 4,7. Nelle impostazioni ci sono tre caselle di controllo: ottimizza HTML, CSS e JS. Selezionale tutte e tre e vedrai risultati immediati.

Per un controllo più granulare c'è WP Rocket, una soluzione premium che unisce i file, li minifica e aggiunge il caching in un'unica interfaccia.

Dopo averli combinati, controlla sempre il sito in modalità incognito: a volte unire i file rompe il layout. Se qualcosa non va, disabilita la combinazione per il file problematico e lascia solo la minificazione.

🔗 Sito ufficiale di WP Rocket

Un'ultima cosa: combinare i file non è la panacea di tutti i mali. Se un plugin carica script esterni da una CDN (Google Fonts, reCAPTCHA, player di YouTube), non puoi combinarli. Puoi solo rimandarli o caricarli in modo asincrono, il che ci porta al passaggio successivo.

Step 4. Gestire gli script che bloccano il rendering

Il browser legge una pagina dall'alto verso il basso. Quando incontra <script src="..."> nel <head>, interrompe il rendering, scarica completamente lo script e solo dopo riprende. I visitatori vedono una pagina bianca in questo intervallo.

La soluzione è spostare gli script non necessari per il rendering della prima schermata in fondo alla pagina, oppure aggiungere l'attributo async/defer. La differenza:

• defer: lo script si carica in background ma viene eseguito solo dopo che il parsing HTML è completato e nell'ordine in cui è incluso;
• async: lo script si carica e viene eseguito alla prima occasione, senza un ordine garantito.

Per WordPress esiste un plugin gratuito chiamato Async JavaScript. Aggiunge async o defer agli script selezionati tramite un'interfaccia chiara. Funziona subito ma richiede cautela: se uno script caricato con async deve essere eseguito prima di un altro, la pagina potrebbe rompersi.

Un approccio sicuro è testare uno script alla volta, verificare il sito in modalità incognita e poi passare al successivo.

Anche WP Rocket può differire gli script: vai su File Optimization → Load JavaScript deferred. Seleziona "Deferred" e aggiungi jQuery alle esclusioni, dato che la maggior parte dei temi e plugin WordPress ne dipende.

Risultato: la pagina inizia il rendering prima, anche se il numero totale di richieste HTTP non è cambiato. I visitatori vedono i contenuti mentre gli script rimanenti si caricano in background.

Step 5. Attivare caching e CDN

La cache riduce direttamente le richieste HTTP nelle visite successive. Il meccanismo è semplice: il browser salva in locale i file statici (CSS, JS, immagini, font). Al caricamento successivo della pagina, invece di richiederli al server, li recupera dalla cache. Zero richieste HTTP per quel file.

Il caching lato server è il livello successivo: il server consegna una pagina HTML già assemblata invece di eseguire decine di query PHP sul database. I plugin di caching (WP Rocket, Flying Press, W3 Total Cache) lo fanno in automatico.

Una CDN (Content Delivery Network) è una rete di server distribuiti nel mondo. Invece di scaricare i file dal tuo hosting in Olanda per un visitatore in Brasile, la CDN li consegna dal nodo più vicino. Inoltre, i provider CDN spesso includono compressione, minificazione e ottimizzazione delle immagini già pronte all'uso.

Cloudflare è un'opzione gratuita che copre le esigenze di base: CDN, protezione DDoS, SSL gratuito.

Installa il plugin Cloudflare per WordPress. Collega il tuo sito alla CDN e fornisce impostazioni di base direttamente dal pannello di amministrazione. Per un controllo più fine, vai alla dashboard Cloudflare: attiva Auto Minify per CSS/JS/HTML, la compressione Brotli e Rocket Loader per il caricamento asincrono degli script.

🔗 Cloudflare su WordPress.org

Con caching e CDN, il numero di richieste HTTP per i visitatori ricorrenti cala drasticamente. Prima visita: caricamento completo. Seconda visita: la maggior parte dei file arriva dalla cache del browser e dal nodo CDN più vicino, senza alcuna chiamata al tuo server.

Bonus: verifica se il tuo server supporta HTTP/2

HTTP/2 è un protocollo che trasferisce più file attraverso una singola connessione TCP. Il browser non aspetta che il file n.1 finisca di scaricarsi prima di richiedere il file n.2; si caricano in parallelo. Questo riduce l'impatto di un numero elevato di richieste HTTP: 60 file su HTTP/2 si caricano più velocemente degli stessi 60 su HTTP/1.1.

Verifica il tuo server usando lo strumento KeyCDN HTTP/2 Test. Inserisci il tuo dominio e clicca "Test". Un risultato "HTTP/2 is supported" significa che il multiplexing è attivo.

Se il test mostra HTTP/1.1, contatta il tuo hosting. La maggior parte dei provider moderni (SiteGround, Cloudways, Kinsta) abilita HTTP/2 di default. Su hosting condivisi del 2010, potrebbe non essere così. Controlla anche la versione PHP: passare a una versione PHP moderna offre un miglioramento di performance percepibile, mentre le versioni obsolete elaborano le richieste in modo significativamente più lento. Se il tuo host non aggiorna né il protocollo né la versione PHP, potrebbe essere il momento di valutare un cambio di hosting.

Se preferisci il formato video, ecco una guida visiva per ridurre le richieste HTTP in WordPress (12 minuti).

⁉️🤔 Domande frequenti

Quante richieste HTTP sono considerate normali per WordPress?

Un intervallo di riferimento è da 30 a 60 per pagina. Qualsiasi valore sopra 80-90 richiede ottimizzazione. GTMetrix e Pingdom mostrano numeri specifici nei loro report. Dopo aver applicato i cinque step di questo articolo, è realistico scendere da 130 a 35-45 richieste.

"Ho un sito su Elementor, e ha già più di 100 richieste. È normale?"

I page builder generano molti CSS e JS per loro natura. Elementor e Divi aggiungono 30-50 richieste da soli. Questo non significa "accettalo"; significa che il resto del tuo sito dovrebbe essere il più pulito possibile. Rimuovi tutto ciò che non è correlato al builder: plugin superflui, font esterni, immagini non ottimizzate. Tieni solo ciò che serve effettivamente ai tuoi visitatori.

Cosa conta di più: il numero di richieste o il peso totale della pagina?

Entrambi. 20 richieste da 1 MB ciascuna significano 20 secondi di caricamento. 100 richieste da 5 KB ciascuna potrebbero caricarsi più velocemente, ma ogni richiesta comporta un overhead per lookup DNS, connessione TCP e handshake TLS. Su HTTP/2 questa differenza si attenua. Su HTTP/1.1 è critica. Ottimizza entrambi: riduci il numero di richieste tramite combinazione dei file e sprite, riduci il peso tramite compressione e minificazione.

Posso farcela senza plugin?

In parte sì. La minificazione di CSS/JS può essere impostata via Gulp o Webpack durante lo sviluppo del tema. HTTP/2 si abilita a livello server (configurazione Nginx/Apache). La cache può essere gestita tramite regole server. Ma per la maggior parte dei proprietari di siti WordPress, i plugin sono la strada più pratica: la configurazione richiede minuti, i risultati sono immediati e il rischio di rompere il sito è più basso.

Ogni quanto dovrei ricontrollare il numero di richieste HTTP?

Dopo ogni installazione o aggiornamento importante di un plugin. Un nuovo plugin potrebbe aggiungere i suoi CSS/JS a tutte le pagine, e non te ne accorgi finché il sito inizia a rallentare. Una volta al mese è sufficiente per i controlli di routine. GTMetrix permette di impostare un monitoraggio automatico con alert quando le performance calano.

Ho davvero bisogno di questa guida se ho già un hosting veloce?

L'hosting risolve una parte del problema a livello server, ma non a livello di codice. Se un plugin inserisce 15 script nell'<head> della pagina, nemmeno i server di fascia più alta li faranno caricare all'istante. Il browser aspetterà comunque. Un hosting veloce ti dà un vantaggio iniziale, ma vince davvero chi pulisce anche il lato client.

Cosa riduce davvero le richieste HTTP e cosa no?

Vediamo tutti i passaggi senza illusioni:

• Pulire plugin e temi dà il miglioramento più evidente. Ogni plugin rimosso elimina i suoi CSS, JS e chiamate esterne. In pratica, dopo un audit spariscono dalle 10 alle 30 richieste.
• La compressione delle immagini riduce la dimensione dei file, ma il numero di richieste resta invariato. Il tempo di caricamento totale, però, cala in modo sensibile.
• Combinare CSS e JS taglia in modo significativo il numero di richieste. Rischio: può rompere il layout, quindi verifica dopo ogni modifica.
• Caricamento differito degli script: stesso numero di richieste, ma la pagina diventa visibile prima.
• Caching e CDN: per i nuovi visitatori la differenza è minima. Per chi torna, i caricamenti successivi avvengono senza una sola richiesta al server.

Se dovessimo scegliere esattamente tre azioni che producono l'impatto maggiore su un tipico sito WordPress: (1) rimuovere i plugin superflui, (2) attivare la combinazione di CSS/JS con Autoptimize, (3) configurare Cloudflare. Sono tre passaggi che richiedono una serata invece di una settimana, e i risultati nei numeri di GTMetrix li vedi il giorno dopo.