Un sito WordPress lento può avere molte cause. Immagini grandi, plugin troppi o scritti male, interrogazioni del database lente, servizi esterni, mancanza di caching, WP-Cron, processi PHP o risorse di hosting sovraccariche possono influenzare il tempo di caricamento singolarmente o insieme.
Ecco perché non esiste una soluzione universale affidabile secondo il modello „installa questo singolo plugin di performance e WordPress sarà veloce“. Prima di ottimizzare, dovresti scoprire, quale parte del sito web è effettivamente lenta.
Una buona analisi delle prestazioni distingue, ad esempio, tra una risposta lenta del server, un'elaborazione complessa di WordPress e un frontend che viene rallentato nel browser solo da immagini, JavaScript, CSS, web font o servizi esterni.
Breve spiegazione: Misura prima di ottimizzare. Se la prima risposta del server è già lenta, dovresti esaminare PHP, database, plugin, processi di WordPress e risorse di hosting. Se la pagina HTML arriva rapidamente ma il browser impiega molto tempo per il rendering, le cause sono probabilmente da ricercare in immagini, CSS, JavaScript, font o risorse esterne.
Cosa significa esattamente „WordPress è lento“? #
L'affermazione può descrivere problemi molto diversi.
Forse il sito web pubblico impiega diversi secondi prima che accada qualcosa. Forse la pagina viene visualizzata rapidamente, ma immagini e altri elementi impiegano molto tempo a caricarsi. In altri casi, è solo l'area di amministrazione di WordPress a essere lenta o esclusivamente il checkout di WooCommerce a rispondere con ritardo.
Queste situazioni non hanno necessariamente la stessa causa.
Perciò un'ottimizzazione delle prestazioni dovrebbe iniziare sempre con una descrizione del problema il più possibile accurata.
Considerare separatamente il frontend e l'area di amministrazione di WordPress #
Un sito web può essere veloce nel frontend e allo stesso tempo avere un'area amministrativa lenta.
Questo è tecnicamente del tutto possibile. Le pagine pubbliche possono, ad esempio, essere servite da una cache di pagina, mentre le richieste all'interno di:
/wp-admin/
devono essere elaborate in modo dinamico da WordPress e PHP.
Se solo l'area di amministrazione è lenta, non dovresti quindi ottimizzare automaticamente le immagini sulla homepage. Viceversa, un'immagine hero lenta non spiega necessariamente un editor di WordPress lento.
Il tempo di caricamento consiste in diverse sezioni #
Quando si visita una pagina WordPress, succedono semplificando diverse cose.
Il browser deve raggiungere il dominio e stabilire una connessione. Il server web elabora la richiesta. Se la pagina non può già essere fornita da una cache, PHP avvia l'applicazione WordPress. WordPress carica, tra le antere cose, i plugin e il tema, esegue le query sul database e genera il documento HTML.
Solo dopo, nel browser ha inizio un'altra parte importante: l'HTML viene elaborato e vengono caricate risorse aggiuntive come fogli di stile, JavaScript, immagini e font.
Un'indicazione generale come „la pagina si carica in quattro secondi“ non dice quindi ancora in quale punto questo tempo venga perso.
Cos'è il TTFB? #
TTFB sta per Tempo al primo byte. In parole semplici, questo valore descrive quanto tempo impiega il primo byte della risposta del server ad arrivare al client dopo una richiesta.
Un TTFB elevato può essere un indizio di problemi sul lato server. Tuttavia, non dimostra automaticamente che il server di hosting sia troppo lento.
Nel tempo misurato possono influire diversi fattori, tra cui la rete, la creazione della connessione, l'elaborazione del server e, nel caso di WordPress dinamico, in particolare la necessaria elaborazione di PHP e del database.
Importante: Un TTFB elevato e un rendering visivo lento non sono la stessa cosa. Un sito WordPress può rispondere rapidamente lato server e poi sembrare comunque lento a causa di grandi risorse frontend.
La cache delle pagine trasforma radicalmente le prestazioni di WordPress #
Senza la cache della pagina, per una normale visualizzazione di una pagina WordPress deve tipicamente eseguire PHP, caricare WordPress, elaborare plugin e tema, eseguire query sul database e generare HTML da esse.
Una cache di pagine può memorizzare temporaneamente l'HTML già generato e servirlo nuovamente in caso di richieste adeguate.
In questo modo WordPress non deve ripetere l'intero processo dinamico a ogni visualizzazione di pagina anonima.
Ciò può causare una differenza di prestazioni notevole, in particolare sulle normali pagine di contenuto.
Non tutte le pagine possono essere memorizzate nella cache allo stesso modo #
Nei siti web dinamici, il caching deve essere utilizzato in modo mirato.
Un carrello WooCommerce, un checkout o un'area membri personalizzata, ad esempio, non possono essere trattati semplicemente come un post di un blog pubblico.
Anche gli utenti registrati necessitano di contenuti individuali a seconda dell'applicazione.
Una configurazione errata della cache può quindi essere sì veloce, ma allo stesso tempo causare errori funzionali o contenuti errati.
La cache non è una riparazione per il codice lento #
La memorizzazione nella cache delle pagine può accelerare notevolmente molte pagine pubbliche. Tuttavia, non dovrebbe essere utilizzata per mascherare completamente i problemi di fondo.
Se una richiesta WordPress non memorizzata nella cache richiede molto tempo, la causa potrebbe essere, ad esempio, plugin inefficienti, problemi di database o chiamate API esterne.
Queste cause possono continuare a verificarsi nell'area di amministrazione, per gli utenti loggati, durante il checkout o in caso di richieste non memorizzate nella cache.
Consiglio pratico: Durante un'analisi delle prestazioni, verifica se possibile sia una normale visualizzazione di pagina memorizzata nella cache sia le aree elaborate in modo dinamico. Una homepage veloce non dimostra che l'intera applicazione WordPress funzioni rapidamente.
I plugin possono rallentare notevolmente WordPress #
Il solo numero di plugin installati non è un indicatore affidabile delle prestazioni.
Un sito web con 30 plugin leggeri può funzionare più velocemente di un sito web con cinque estensioni molto complesse.
Ciò che è determinante è, cosa fa effettivamente un plugin durante una richiesta.
Un plugin può, ad esempio, generare molte query al database, contattare servizi esterni, caricare grandi quantità di JavaScript o eseguire operazioni ad alta intensità di calcolo ad ogni caricamento di pagina.
„Troppi plugin“ è una diagnosi troppo imprecisa #
La raccomandazione di eliminare semplicemente quanti più plugin possibile è quindi riduttiva.
Se WordPress è lento, dovresti identificare i plugin che rallentano effettivamente il sito.
Particolarmente interessanti sono i plugin la cui performance è cambiata notevolmente dopo l'installazione o l'aggiornamento.
Dovresti verificare anche le estensioni che si sovrappongono dal punto di vista funzionale. Più plugin per la stessa attività possono non solo generare complessità non necessaria, ma in alcuni casi influenzarsi reciprocamente.
Ti spiegheremo come testare le estensioni in modo controllato l'una contro l'altra su Rilevare e risolvere i conflitti di plugin o temi in WordPress.
Anche il tema influisce sul tempo di caricamento #
Il tema attivo determina una parte essenziale dell'output del frontend. Può caricare fogli di stile, JavaScript, font, immagini e funzionalità aggiuntive.
Un tema molto esteso può quindi richiedere più risorse rispetto a un tema leggero.
Tuttavia, questo non significa che un tema minimalista renda automaticamente veloce qualsiasi sito web WordPress. Page builder, plugin, immagini e funzioni personalizzate possono comunque causare la maggior parte del carico.
Il tema e il resto del sito web dovrebbero quindi essere considerati insieme.
Valutare i Page Builder in modo differenziato #
I Page Builder consentono layout complessi, ma possono generare HTML, CSS e JavaScript aggiuntivi.
Se ciò sia problematico nella pratica dipende molto da come è stato strutturato il sito web.
Molti container nidificati, animazioni, slider, video, grandi immagini di sfondo e numerosi widget possono rendere una pagina notevolmente più complessa.
Invece di dare la colpa a prescindere al Page Builder, dovresti analizzare quali risorse ed elementi vengono effettivamente caricati sulla specifica pagina.
Le immagini sono tra i principali rallentamenti del frontend #
Una foto ad alta risoluzione direttamente da una fotocamera o da uno smartphone può pesare diversi megabyte. Se un'immagine di questo tipo viene utilizzata tal quale su un sito web, il visitatore deve trasferire questi dati, sebbene l'immagine venga eventualmente visualizzata con una larghezza di poche centinaia di pixel.
Ecco perché le immagini dovrebbero essere dimensionate correttamente e compresse in modo sensato.
I formati di immagine moderni possono ridurre ulteriormente la quantità di dati trasmessi, a condizione che siano adatti al rispettivo sito web e al supporto del browser.
Le dimensioni dell'immagine e la dimensione del file non sono la stessa cosa #
Un'immagine può ad esempio avere dimensioni di:
5000 × 3333 Pixel
possedere, sebbene sul sito web sia indicato solo con:
800 × 533 pixel
viene visualizzato.
La semplice riduzione visiva tramite CSS non riduce automaticamente il file di immagine originale che deve essere trasferito.
Ecco perché le dimensioni delle immagini dovrebbero già corrispondere al loro effettivo utilizzo.
Utilizzare il Lazy Loading in modo sensato #
Le immagini e le altre risorse che si trovano molto al di sotto dell'area inizialmente visibile non devono necessariamente essere caricate subito.
Il lazy loading può caricare tali risorse in modo differito fino a quando non sono necessarie.
Questo riduce la quantità di dati iniziale.
Tuttavia, un'immagine importante nell'area direttamente visibile non dovrebbe essere ritardata artificialmente senza una buona ragione. L'ottimizzazione delle prestazioni non significa caricare fondamentalmente ogni risorsa il più tardi possibile.
JavaScript può rallentare la visualizzazione #
I moderni siti web WordPress utilizzano spesso JavaScript per navigazioni, slider, moduli, tracciamento, sistemi di consenso, page builder e molte altre funzioni.
Un JavaScript eccessivo o caricato in modo sfavorevole può ritardare l'elaborazione nel browser.
Soprattutto sui dispositivi mobili più lenti, non è solo la dimensione del file a essere rilevante. JavaScript deve essere scaricato, analizzato ed eseguito.
Ecco perché un file più piccolo può comunque essere costoso se richiede molta elaborazione computazionale.
Ritardare JavaScript – ma in modo controllato #
I plugin di prestazioni offrono spesso funzionalità come il caricamento ritardato o differito di JavaScript.
Questo può migliorare la rappresentazione iniziale, ma non deve essere attivato ciecamente.
Se gli script dipendenti vengono caricati nell'ordine sbagliato, ad esempio menu, moduli, slider o altri elementi interattivi possono guastarsi.
Dopo tali ottimizzazioni, dovresti quindi testare sempre le funzioni principali del sito web.
Anche i CSS possono diventare un collo di bottiglia #
Fogli di stile di grandi dimensioni o molti file CSS differenti aumentano il carico di lavoro del browser.
Il CSS necessario per la visualizzazione iniziale, ma disponibile solo in ritardo, può essere particolarmente problematico.
Anche in questo caso vale tuttavia quanto segue: un numero il più possibile ridotto di file non è automaticamente l'unico obiettivo. I moderni protocolli di trasmissione e i meccanismi di cache modificano la valutazione rispetto alle vecchie regole di ottimizzazione.
Ciò che conta è l'effettivo comportamento di caricamento del sito web.
I webfont richiedono richieste aggiuntive #
I font web personalizzati possono migliorare il design, ma causano risorse aggiuntive.
Un numero particolarmente elevato di famiglie di caratteri, stili di carattere e servizi di font esterni può aumentare il tempo di caricamento.
Verifica quindi quali varianti di carattere vengono effettivamente utilizzate.
Se vengono utilizzati servizi di caratteri esterni, oltre alle prestazioni è necessario considerare anche i requisiti di protezione dei dati.
I servizi esterni possono rallentare un sito web veloce #
Non ogni risorsa di un sito WordPress viene caricata dal proprio server.
Tipiche componenti esterne sono, ad esempio, servizi di analisi e tracciamento, mappe, video, widget di social media, reti pubblicitarie, sistemi di chat o font esterni.
Le prestazioni di questi servizi esulano in parte dal controllo del proprio server WordPress.
Se una pagina risponde rapidamente lato server ma impiega molto tempo a caricarsi nel browser, dovresti esaminare anche le richieste di terze parti.
Non sottovalutare i video incorporati #
Un video incorporato può caricare file JavaScript aggiuntivi, immagini di anteprima, connessioni e altre risorse da un provider esterno.
Questo effetto può moltiplicarsi in diversi video.
A seconda del sito web, può essere utile caricare completamente i media esterni solo dopo l'interazione dell'utente.
Il database di WordPress come fattore di performance #
WordPress memorizza contenuti, impostazioni e molti dati dei plugin in un database relazionale.
Durante la visualizzazione di una pagina, WordPress, il tema e i plugin eseguono query su questo database.
Le dimensioni pure del database non sono un fattore determinante in automatico. Un database di grandi dimensioni ma strutturato in modo sensato può funzionare senza problemi, mentre un database più piccolo può causare problemi di prestazioni a causa di query inefficienti.
Riconoscere le query di database lente #
Se una richiesta WordPress dinamica è lenta, le singole query al database possono rappresentare una parte considerevole del problema.
In particolare i plugin con funzioni complesse di ricerca, filtraggio, statistica o reportistica possono generare query complesse.
Un'analisi professionale non dovrebbe quindi chiedersi solo quanto è grande il database, ma quali query richiedono effettivamente molto tempo e con quale frequenza vengono eseguite.
wp_options e autoload #
La tabella delle opzioni di WordPress contiene i dati di configurazione di WordPress e dei plugin. Determinate opzioni vengono caricate automaticamente in molte richieste di WordPress.
Se i plugin lasciano lì dati caricati automaticamente molto grandi o non necessari, ciò può compromettere le prestazioni.
Tali voci non dovrebbero tuttavia essere eliminate casualmente dal database in base al loro nome.
Attenzione: Le „pulizie“ del database possono rimuovere permanentemente impostazioni o dati dei plugin. Prima di interventi manuali, crea un backup ed elimina solo i dati di cui la funzione e l'origine sono state chiaramente stabilite.
Transienti e dati temporanei #
WordPress e i plugin possono utilizzare i cosiddetti transient per memorizzare temporaneamente i dati.
I transient non sono fondamentalmente un errore e fanno parte del normale meccanismo di WordPress.
Le implementazioni errate o quantità insolitamente grandi di dati temporanei possono diventare problematiche.
Tuttavia, la cancellazione forfettaria di tutti i transient non è una strategia di performance duratura. Se si riformano immediatamente in quantità problematiche, è necessario indagarne la causa.
Le revisioni non sono automaticamente il problema #
WordPress può salvare le versioni precedenti di post e pagine come revisioni.
Sito web a lungo gestito possono in tal modo generare molti record di dati.
Ciò non significa tuttavia che alcune centinaia o migliaia di revisioni siano automaticamente la causa di un sito web lento.
Un database dovrebbe essere ottimizzato sulla base di misurazioni reali e non a causa di ipotesi generali.
Differenziare tra Object Cache e Page Cache #
La cache di pagina e la cache di oggetti risolvono problemi diversi.
In parole semplici, una Page Cache memorizza output di pagine già generati. Una Object Cache persistente, invece, può memorizzare temporaneamente risultati e dati di cui WordPress ha bisogno durante l'elaborazione, andando oltre i singoli rilasci di richieste.
Tecnologie come Redis possono essere utilizzate come backend per una Object Cache persistente.
Ciò può essere particolarmente utile per le applicazioni WordPress dinamiche con accessi ricorrenti al database.
Tuttavia, un object cache non sostituisce una page cache e non elimina nemmeno il codice scritto male.
WooCommerce ha esigenze diverse rispetto a un blog #
Un semplice blog consiste principalmente di contenuti leggibili pubblicamente. Molte pagine possono quindi essere memorizzate nella cache in modo molto efficace.
Un negozio WooCommerce, invece, possiede numerosi processi dinamici. Il carrello, il checkout, l'account cliente, la giacenza di magazzino, i prezzi e altre funzioni possono dipendere dall'utente o dallo stato.
Ecco perché le prestazioni in WooCommerce devono essere considerate in modo più differenziato.
Una homepage del negozio memorizzata in cache in modo eccellente, ad esempio, dice poco su quanto velocemente venga elaborato il checkout o una ricerca di prodotti complessa.
wp-admin lento: verificare i plugin e i processi in background #
Se è esclusivamente l'area di amministrazione di WordPress a essere lenta, dovresti analizzare quali processi vi si stanno svolgendo.
I plugin possono caricare widget della dashboard, contattare server di licenza esterni, calcolare statistiche o elaborare dati in background.
Anche un numero elevato di richieste AJAX o REST amministrative può essere rilevante.
Poiché l'area di amministrazione solitamente non può essere completamente memorizzata nella cache come una pagina pubblica, i processi inefficienti vi risultano particolarmente evidenti.
classificare correttamente admin-ajax.php #
WordPress e i plugin possono modificare il file:
wp-admin/admin-ajax.php
da utilizzare per le richieste AJAX.
Molti accessi di questo tipo non sono automaticamente problematici. Tuttavia, in presenza di richieste AJAX molto frequenti o particolarmente lente, si dovrebbe verificare quale funzione o plugin le attiva.
Il solo blocco di admin-ajax.php non è una soluzione generale sensata per le prestazioni e può danneggiare le funzionalità del sito web.
Non disattivare ciecamente la REST API di WordPress #
WordPress e i moderni plugin utilizzano la REST API per numerose funzionalità.
Disattivarla completamente per motivi di prestazioni può compromettere l'editor a blocchi o le estensioni.
Se le richieste REST generano un carico notevolmente elevato, è necessario identificare l'applicazione o la rotta responsabile.
Il WP-Cron può influire sulle prestazioni #
Per impostazione predefinita, WordPress utilizza WP-Cron per eseguire le attività pianificate.
Ciò include, a seconda del sito Web, ad esempio post programmati, attività di manutenzione e lavori in background registrati dai plugin.
A ogni caricamento di pagina WordPress può verificare se ci sono attività programmate in scadenza.
Se ci sono molte attività cron o attività particolarmente complesse, questo può sovraccaricare il sito web.
È quindi fondamentale non solo che WP-Cron esista, ma anche quali attività vengano eseguite tramite esso e quanto tempo queste richiedano.
Sostituire WP-Cron con un vero cronjob #
Su ambienti di hosting adeguati, può essere utile non avviare la chiamata cron interna di WordPress durante i normali caricamenti di pagina, bensì eseguirla in modo controllato tramite un cronjob lato server.
A tale scopo, WordPress può, ad esempio, utilizzare:
DISABILITA_WP_CRON
essere configurato di conseguenza.
Ciò dovrebbe tuttavia avvenire solo se successivamente viene effettivamente configurato un cronjob esterno affidabile.
Attenzione: Disattivare semplicemente WP-Cron, senza configurare un'alternativa, può impedire l'esecuzione delle attività programmate di WordPress e dei plugin.
La versione di PHP influisce sulle prestazioni di WordPress #
WordPress viene eseguito principalmente lato server con PHP. La versione di PHP utilizzata influisce quindi sulla compatibilità, sulla sicurezza e sulle prestazioni.
Una versione di PHP aggiornata, supportata da WordPress e dai plugin utilizzati, è fondamentalmente opportuna.
Non dovresti cambiare versione di PHP solo perché una versione più recente rende presumibilmente ogni sito web automaticamente più veloce.
Prima di un cambio, i plugin, il tema e il codice personalizzato devono essere compatibili.
Ti spiegheremo come procedere su Modificare la versione di PHP per WordPress e verificare la compatibilità.
Differenza tra PHP Memory Limit e performance #
Il limite di memoria PHP determina quanta memoria un singolo processo PHP o un'esecuzione PHP può utilizzare all'interno della rispettiva configurazione.
Se WordPress raggiunge questo limite, può verificarsi un errore come:
Dimensione di memoria consentita ... esaurita
verificarsi.
Tuttavia, un limite di memoria più elevato non rende automaticamente più veloce un sito WordPress che funziona normalmente.
Se un plugin consuma una quantità insolita di memoria, aumentare il limite potrebbe anche limitarsi a spostare il sintomo.
Spieghiamo le differenze in dettaglio su Limite di memoria PHP in WordPress: individuare e risolvere gli errori.
OPcache di PHP #
Il codice PHP deve essere elaborato per l'esecuzione. L'OPcache può memorizzare nella cache il bytecode PHP già compilato in memoria, in modo che i file PHP non debbano essere ricompilati completamente a ogni richiesta.
Su moderni ambienti di hosting PHP, OPcache è quindi una componente importante per le prestazioni lato server.
In qualità di utente WordPress, di solito non devi apportare modifiche continue a questo. Tuttavia, durante un'analisi delle prestazioni tecniche, l'ambiente di esecuzione PHP fa parte del quadro generale.
Le risorse di hosting possono diventare un collo di bottiglia #
Anche un sito WordPress tecnicamente ben ottimizzato richiede potenza di calcolo, memoria di lavoro, prestazioni del database e risorse I/O.
Se un sito web richiede permanentemente più risorse di quante il suo ambiente possa fornire, le richieste potrebbero essere elaborate più lentamente.
Ciò riguarda, ad esempio, siti Web ad alto traffico, grandi negozi WooCommerce o siti Web con plugin intensivi di risorse.
In CURIAWEB i nostri Offerte di hosting WordPress un ambiente di hosting ottimizzato per WordPress. Ciononostante, in caso di un problema specifico di prestazioni, bisognerebbe sempre verificare prima, quale risorsa è effettivamente limitata, anziché dare per scontato che la soluzione sia semplicemente una maggiore potenza dei server.
Interpretare correttamente le risorse di CloudLinux #
In un ambiente di hosting CloudLinux, le risorse di un account di hosting possono essere limitate in modo controllato. In questo modo, un singolo account non può consumare risorse dell'intero server senza limiti.
Se un sito web WordPress supera ripetutamente tali limiti, si tratta di un'importante informazione diagnostica.
Tuttavia, ciò che è decisivo è, quale viene raggiunto il limite e il perché.
Un consumo di risorse improvvisamente molto elevato può essere causato, ad esempio, da un plugin problematico, da bot, da cronjob o da un numero insolitamente elevato di richieste dinamiche. In tal caso, un pacchetto di hosting più grande potrebbe semplicemente offrire maggiore margine di manovra senza eliminare la causa.
Utilizzo della CPU #
Il codice PHP, le operazioni sui database e altri processi richiedono tempo CPU.
Se un sito Web esegue continuamente attività ad alta intensità di calcolo, la CPU può diventare un collo di bottiglia.
È particolarmente interessante a questo proposito se il carico elevato si verifica permanentemente o solo in determinati momenti.
Picchi di carico ricorrenti possono indicare, ad esempio, cron job, backup, importazioni, scansioni o bot.
I/O e accesso al disco #
WordPress legge e scrive file e dati. Anche i plugin possono causare grandi quantità di operazioni sui file.
Backup, elaborazione di immagini, scansioni di sicurezza, importazioni e file di log estesi sono esempi di processi che possono consumare risorse di I/O.
Una memoria NVMe veloce è utile, ma non può compensare completamente operazioni sui file inefficienti o inutilmente frequenti.
Processi PHP e richieste simultanee #
Durante il caricamento di pagine dinamiche, PHP deve elaborare le richieste. Se un numero molto elevato di richieste non memorizzate nella cache raggiunge contemporaneamente il sito web, i processi o i worker disponibili possono diventare un collo di bottiglia.
Questo è uno dei motivi per cui un caching efficiente delle pagine per contenuti pubblicamente memorizzabili nella cache può essere così efficace: non ogni visitatore richiede quindi una nuova esecuzione completa di WordPress.
I bot possono sovraccaricare WordPress #
Non ogni visita al sito web proviene da un vero visitatore.
Anche motori di ricerca, strumenti SEO, servizi di monitoraggio, crawler di intelligenza artificiale, scanner di sicurezza e bot indesiderati possono generare richieste.
I bot particolarmente aggressivi possono richiamare URL dinamici ad alta frequenza, sovraccaricando in questo modo PHP e database.
In caso di picchi di carico inspiegabili, vale quindi la pena dare un'occhiata anche ai log degli accessi e agli URL richiesti.
wp-login.php e tentativi di accesso automatizzati #
I siti WordPress accessibili al pubblico ricevono frequentemente richiesteautomated su:
wp-login.php
Un numero elevato di tali richieste può richiedere risorse aggiuntive.
Meccanismi di sicurezza adeguati possono limitare i tentativi di accesso indesiderati. Tuttavia, eliminare semplicemente il file di login o modificare i file del core di WordPress non è una soluzione.
XML-RPC come possibile origine delle richieste #
A seconda della configurazione e delle funzioni utilizzate,
xmlrpc.php
Ricevere richieste.
Se XML-RPC sia necessario dipende dal singolo sito web e dai servizi utilizzati.
Invece di disattivare la funzione in modo generalizzato sulla base di raccomandazioni generali sulle prestazioni, dovresti prima verificare se lì si genera effettivamente un carico rilevante e se esistono funzioni dipendenti.
I backup possono richiedere temporaneamente risorse #
Un backup completo di WordPress potrebbe dover leggere molti file, creare archivi ed esportare i contenuti del database.
Nei siti web di grandi dimensioni, ciò può causare un notevole carico di risorse.
Se, ad esempio, WordPress rallenta ogni giorno a una certa ora, dovresti quindi verificare se in quel momento sono in corso backup o altre attività di manutenzione pianificate.
Anche le scansioni di sicurezza richiedono potenza #
Un plug-in di sicurezza che analizza migliaia di file richiede inevitabilmente risorse.
Ciò non significa che i controlli di sicurezza siano fondamentalmente sbagliati. Tuttavia, la loro frequenza ed esecuzione dovrebbero essere adeguate al sito web e all'ambiente di hosting.
Se i problemi di prestazioni si verificano sempre durante una scansione, la correlazione temporale è un indizio importante.
I file di log possono diventare molto grandi senza essere notati #
I plugin difettosi o il debug permanentemente attivato possono generare file di log di grandi dimensioni.
Un famoso file di debug di WordPress è, ad esempio:
wp-content/debug.log
Se un errore viene registrato più volte ad ogni caricamento di pagina, questo file può crescere rapidamente.
Il debug dovrebbe pertanto essere utilizzato in modo controllato per la diagnosi e successivamente configurato nuovamente in modo appropriato.
Spieghiamo di più al riguardo sotto Attivare il debug di WordPress e utilizzare i log degli errori.
Un'API esterna lenta può bloccare WordPress #
I plugin a volte comunicano con servizi esterni durante una richiesta.
Quando WordPress attende la risposta di un server esterno lento o irraggiungibile, il sito web stesso può subire ritardi nella risposta.
Questo è particolarmente insidioso, perché il proprio server può funzionare perfettamente dal punto di vista tecnico.
Se i problemi di prestazioni si verificano in modo sporadico, è possibile analizzare di conseguenza anche le richieste HTTP esterne.
Non confondere DNS e rete con WordPress #
Prima che il browser raggiunga WordPress, è necessario che la domain venga risolta e che venga stabilita una connessione con il server.
I problemi a questo livello non sono problemi di prestazioni di WordPress in senso stretto.
Un'analisi completa valuta pertanto anche se il ritardo si verifica già prima dell'effettiva elaborazione sul server.
CDN: utile, ma non automaticamente necessaria #
Una Content Delivery Network può fornire risorse statiche tramite sistemi geograficamente distribuiti e, a seconda della configurazione, occuparsi di ulteriori ottimizzazioni.
Ciò può essere utile in particolare con un pubblico distribuito a livello internazionale.
Tuttavia, una CDN non corregge una funzione PHP lenta, una query di database inefficiente o un plugin difettoso.
Per un pubblico target prevalentemente regionale, si dovrebbe quindi verificare quale problema specifico debba essere risolto tramite una CDN.
Molti tentativi HTTP non sono automaticamente negativi #
Le vecchie guide sulle prestazioni si concentrano spesso molto sul ridurre il più drasticamente possibile il numero dei singoli file.
Il numero di richieste rimane rilevante, ma non dovrebbe essere considerato isolatamente.
Anche la dimensione del file, la priorità, la memorizzabilità nella cache, il protocollo di trasferimento e il carico di elaborazione nel browser giocano un ruolo importante.
Un singolo file JavaScript enorme non è automaticamente migliore di diverse risorse più piccole e strutturate in modo sensato.
Classificare correttamente i Core Web Vitals #
Per l'esperienza utente percepita, non sono rilevanti solo i secondi necessari per il caricamento completo.
Le moderne misurazioni delle performance considerano, tra le altre cose, quando appare il contenuto visibile più importante, quanto velocemente una pagina risponde alle interazioni e se il layout si sposta inaspettatamente durante il caricamento.
Perciò un sito Web può offrire una scarsa esperienza utente nonostante un tempo di caricamento complessivo accettabile.
LCP – Largest Contentful Paint #
In parole semplici, il Largest Contentful Paint considera quando un elemento di contenuto grande o importante viene visualizzato nell'area visibile.
Spesso si tratta di una grande immagine, di un titolo o di un altro contenuto in evidenza.
Se, ad esempio, l'immagine hero è molto grande o viene caricata con un ritardo non necessario, ciò può peggiorare il LCP.
INP – Interaction to Next Paint #
Interaction to Next Paint valuta la reattività di una pagina alle interazioni dell'utente durante l'intera visita.
Un JavaScript complesso può, ad esempio, fare sì che il browser non riesca a rispondere abbastanza rapidamente dopo un clic o un'altra interazione.
Di per sé, una risposta rapida del server non garantisce quindi una buona performance di interazione.
CLS – Cumulative Layout Shift #
Il Cumulative Layout Shift valuta gli spostamenti imprevisti del layout.
Se, ad esempio, un'immagine viene caricata inizialmente senza uno spazio riservato e successivamente spinge verso il basso il resto del contenuto, ciò può influire sulla stabilità visiva.
Anche i banner, i caratteri o altri elementi caricati in un secondo momento possono contribuire a questo.
Distinguere tra dati di laboratorio e dati di utenti reali #
Gli strumenti di performance possono eseguire test in condizioni controllate. Questi cosiddetti dati di laboratorio sono eccellenti per analisi riproducibili.
Tuttavia, i visitatori reali utilizzano dispositivi, browser e connessioni di rete differenti.
I dati sul campo o i dati reali degli utenti possono quindi mostrare un quadro diverso.
Entrambe le prospettive sono utili e non dovrebbero essere confuse.
Un singolo speed test non basta #
Le misurazioni delle prestazioni possono variare.
Lo stato della cache, la rete, i servizi esterni e i processi in background influenzano il risultato.
Ecco perché non dovresti apportare modifiche estese a un sito Web sulla base di un singolo test.
Diverse misurazioni in condizioni comparabili forniscono una base migliore.
Consiglio pratico: Prima di procedere con ottimizzazioni importanti, documenta un valore iniziale. Successivamente, modifica se possibile solo un'area rilevante e misura di nuovo. In questo modo puoi verificare se una misura ha effettivamente aiutato.
La sola homepage non è un test sufficiente #
Un sito web WordPress è spesso costituito da tipi di pagina molto diversi.
Per un'analisi significativa dovresti considerare, ad esempio, anche un normale articolo, una landing page importante e, nel caso di WooCommerce, una pagina prodotto.
Se esclusivamente una singola pagina è lenta, la causa potrebbe risiedere nella struttura di proprio quella pagina e non nell'intera installazione di WordPress.
Prestare particolare attenzione alle prestazioni mobili #
Un sito web che funziona senza problemi su un computer desktop potente con una connessione Internet veloce può risultare notevolmente più lento su uno smartphone medio.
Grandi quantità di JavaScript e complessi effetti visivi incidono maggiormente sui dispositivi meno potenti.
Le prestazioni non dovrebbero quindi essere valutate esclusivamente dal proprio computer d'ufficio.
Perché un punteggio di performance non è l'unico obiettivo #
Gli strumenti condensano spesso misurazioni complesse in un unico punteggio.
Simili punteggi sono utili, ma non dovrebbero diventare un fine a sé stanti.
Un sito web dovrebbe essere veloce, stabile e facilmente utilizzabile da utenti reali. Una modifica tecnica che migliora esclusivamente un punteggio ma danneggia un'importante funzionalità non è un'ottimizzazione riuscita.
Pulire regolarmente WordPress – ma in modo mirato #
Nel corso del tempo, su molte installazioni si accumulano plugin, temi, file multimediali, funzioni di test e vecchie configurazioni non più utilizzati.
Non tutto questo rallenta immediatamente il sito web. Tuttavia, i componenti non necessari aumentano la complessità e possono rendere più difficili la manutenzione e la risoluzione dei problemi.
Le estensioni non più necessarie dovrebbero quindi essere rimosse accuratamente previa verifica.
Gli aggiornamenti possono risolvere problemi di prestazioni #
Le versioni attuali di WordPress, dei plugin e dei temi non contengono solo nuove funzionalità e correzioni di sicurezza. In parte, gli sviluppatori migliorano anche le prestazioni e la compatibilità.
Un'installazione permanentemente obsoleta non è quindi una strategia di performance sensata.
Gli aggiornamenti sui siti web importanti dovrebbero essere controllati ed eseguiti con una strategia di backup o di ripristino funzionante.
Quando un plugin dovrebbe essere sostituito #
Se un'estensione richiede permanentemente in modo sproporzionato molte risorse e non esiste alcuna soluzione di configurazione o aggiornamento, una sostituzione può essere opportuna.
Ciò che conta non è quale plugin viene definito il „più veloce“ in qualche classifica, ma quali funzionalità richiede effettivamente il tuo sito web e come l'alternativa funziona nel tuo specifico ambiente.
Quando è opportuno aumentare le risorse di hosting #
L'ottimizzazione non significa che ogni sito web debba essere gestito con risorse minime.
Se un sito web strutturato tecnicamente in modo corretto richiede costantemente risorse elevate a causa di traffico reale o di processi dinamici legittimi, una maggiore potenza di calcolo può essere la soluzione giusta.
Prima di ciò, tuttavia, si dovrebbe escludere che il carico sia causato principalmente da un errore, da bot, da un cron job fuori controllo o da un'estensione inefficiente.
Risolvere i problemi di prestazioni in modo sistematico #
Inizia con il sintomo concreto. L'intero sito web è lento o solo una pagina? Riguarda il frontend, wp-admin o entrambi? È già lenta la risposta del server o i ritardi si verificano solo durante il caricamento e l'elaborazione delle risorse frontend?
Verifica poi se il problema si presenta in modo permanente o solo in determinati momenti. Un pattern temporale ricorrente può indicare backup, cron job, scansioni o altri processi pianificati.
Considera poi le ultime modifiche. Se il sito è diventato lento subito dopo l'installazione di un plugin, un aggiornamento o una modifica PHP, possiedi già un indizio importante.
Solo successivamente dovresti esaminare in modo mirato plugin, query di database, richieste esterne, cache, PHP e risorse di hosting.
Cosa è meglio evitare di fare se hai un sito WordPress lento #
Non installare cinque plugin di performance contemporaneamente. Più sistemi che cercano di ottimizzare contemporaneamente cache, CSS, JavaScript e database possono generare nuovi conflitti e rendere la diagnosi più difficile.
Non eliminare a caso tabelle o opzioni del database solo perché uno strumento di ottimizzazione le contrassegna come grandi. Le dimensioni da sole non dimostrano un problema di prestazioni.
Inoltre, non cambiare contemporaneamente tema, versione di PHP, sistema di cache e diversi plugin. Se dopo il sito web è più veloce, non saprai quale misura ha effettivamente aiutato.
E non aumentare automaticamente le risorse del server prima di aver verificato il motivo per cui le risorse esistenti sono esaurite.
Regola fondamentale: Prima misurare, poi circoscrivere la causa, quindi ottimizzare in modo mirato e infine misurare di nuovo. L'ottimizzazione delle prestazioni senza valori di confronto è spesso solo una congettura.
Quali informazioni aiutano il supporto di CURIAWEB? #
Se un sito web WordPress su CURIAWEB è insolitamente lento, una descrizione del problema il più possibile dettagliata aiuta molto di più rispetto all'affermazione generale „WordPress è lento“.
Condividi, ad esempio, quale URL è interessato, se il problema si verifica anche nell'area di amministrazione e da quando noti il cambiamento. Se le prestazioni sono scarse solo in determinati momenti, è importante anche l'orario approssimativo.
È inoltre utile sapere se immediatamente prima siano stati modificati plugin, temi, WordPress, PHP o altre impostazioni.
In caso di valori anomali delle risorse o messaggi di errore, possiamo poi verificare in modo mirato se, ad esempio, sono coinvolti PHP, il database, i processi o le risorse dell'account.
Non inviare password non richieste.
Riepilogo #
Un sito WordPress lento ha raramente una sola causa possibile. La risposta del server, PHP, il database, i plugin, il tema, la cache, le immagini, JavaScript, CSS, i servizi esterni e le risorse di hosting influenzano diverse parti del tempo di caricamento.
Ecco perché l'ottimizzazione non dovrebbe iniziare con l'installazione di un qualsiasi plugin di performance, bensì con la misurazione e la delimitazione del problema.
Se la risposta dinamica del server è già lenta, dovresti esaminare in particolare l'elaborazione PHP, le query al database, i plugin, le chiamate API esterne, i cron job e le risorse di hosting. Se il server risponde rapidamente mentre la pagina viene caricata lentamente nel browser, l'attenzione siposta maggiormente su immagini, JavaScript, CSS, font e risorse di terze parti.
La Page Cache e la Object Cache persistente possono alleggerire notevolmente WordPress, ma assolvono a compiti diversi e non sostituiscono un'applicazione pulita. Anche una maggiore potenza del server è la soluzione giusta solo se mancano effettivamente risorse e non se un processo difettoso genera un carico inutile.
Un'ottimizzazione WordPress sostenibile segue quindi sempre lo stesso principio: misurare, determinare la causa, modificare in modo mirato e misurare di nuovo.
