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.
Solche Scores sind hilfreich, sollten aber nicht zum Selbstzweck werden.
Eine Website sollte schnell, stabil und für reale Benutzer gut bedienbar sein. Eine technische Änderung, die lediglich einen Score verbessert, dafür aber eine wichtige Funktion beschädigt, ist keine erfolgreiche Optimierung.
WordPress regelmäßig aufräumen – aber gezielt #
Im Laufe der Zeit sammeln sich auf vielen Installationen nicht mehr verwendete Plugins, Themes, Medien, Testfunktionen und alte Konfigurationen an.
Nicht alles davon macht die Website unmittelbar langsam. Unnötige Komponenten erhöhen aber die Komplexität und können Wartung sowie Fehlersuche erschweren.
Nicht mehr benötigte Erweiterungen sollten deshalb nach vorheriger Prüfung sauber entfernt werden.
Updates können Performance-Probleme lösen #
Aktuelle WordPress-, Plugin- und Theme-Versionen enthalten nicht nur neue Funktionen und Sicherheitskorrekturen. Entwickler verbessern teilweise auch Performance und Kompatibilität.
Eine dauerhaft veraltete Installation ist deshalb keine sinnvolle Performance-Strategie.
Updates sollten bei wichtigen Websites kontrolliert und mit einer funktionierenden Backup- beziehungsweise Wiederherstellungsstrategie durchgeführt werden.
Quando un plugin dovrebbe essere sostituito #
Wenn eine Erweiterung dauerhaft unverhältnismäßig viele Ressourcen benötigt und keine Konfigurations- oder Update-Lösung existiert, kann ein Ersatz sinnvoll sein.
Entscheidend ist dabei nicht, welches Plugin in irgendeiner Bestenliste als „schnellstes“ bezeichnet wird, sondern welche Funktionen deine Website tatsächlich benötigt und wie die Alternative in deiner konkreten Umgebung arbeitet.
Wann mehr Hosting-Ressourcen sinnvoll sind #
Optimierung bedeutet nicht, dass jede Website mit minimalen Ressourcen betrieben werden muss.
Wenn eine technisch sauber aufgebaute Website aufgrund echten Traffics oder legitimer dynamischer Prozesse dauerhaft hohe Ressourcen benötigt, kann mehr Rechenleistung die richtige Lösung sein.
Vorher sollte jedoch ausgeschlossen werden, dass die Last hauptsächlich durch einen Fehler, Bots, einen außer Kontrolle geratenen Cronjob oder eine ineffiziente Erweiterung entsteht.
Performance-Probleme systematisch eingrenzen #
Beginne mit dem konkreten Symptom. Ist die gesamte Website langsam oder nur eine Seite? Betrifft es das Frontend, wp-admin oder beides? Ist bereits die Serverantwort langsam oder entstehen die Verzögerungen erst beim Laden und Verarbeiten der Frontend-Ressourcen?
Prüfe danach, ob das Problem dauerhaft oder nur zu bestimmten Zeiten auftritt. Ein wiederkehrendes Zeitmuster kann auf Backups, Cronjobs, Scans oder andere geplante Prozesse hindeuten.
Betrachte anschließend die letzten Änderungen. Wenn die Website direkt nach Installation eines Plugins, einem Update oder einer PHP-Änderung langsam geworden ist, besitzt du bereits einen wichtigen Anhaltspunkt.
Erst danach solltest du gezielt Plugins, Datenbankabfragen, externe Requests, Cache, PHP und Hosting-Ressourcen untersuchen.
Was du bei einer langsamen WordPress-Website besser nicht tun solltest #
Installiere nicht fünf Performance-Plugins gleichzeitig. Mehrere Systeme, die gleichzeitig Cache, CSS, JavaScript und Datenbank optimieren wollen, können neue Konflikte erzeugen und die Diagnose erschweren.
Lösche nicht wahllos Datenbanktabellen oder Optionen, nur weil ein Optimierungstool sie als groß markiert. Größe allein beweist kein Performance-Problem.
Wechsle außerdem nicht gleichzeitig Theme, PHP-Version, Cache-System und mehrere Plugins. Wenn die Website danach schneller ist, weißt du nicht, welche Maßnahme tatsächlich geholfen hat.
Und erhöhe Serverressourcen nicht automatisch, bevor du geprüft hast, warum die vorhandenen Ressourcen ausgeschöpft werden.
Regola fondamentale: Erst messen, dann Ursache eingrenzen, anschließend gezielt optimieren und danach erneut messen. Performance-Optimierung ohne Vergleichswerte ist häufig nur Vermutung.
Quali informazioni aiutano il supporto di CURIAWEB? #
Wenn eine WordPress-Website bei CURIAWEB ungewöhnlich langsam ist, hilft eine möglichst genaue Beschreibung des Problems wesentlich mehr als die allgemeine Aussage „WordPress ist langsam“.
Teile beispielsweise mit, welche URL betroffen ist, ob das Problem auch im Adminbereich auftritt und seit wann du die Veränderung bemerkst. Wenn die Performance nur zu bestimmten Zeiten schlecht ist, ist auch der ungefähre Zeitpunkt wichtig.
Hilfreich ist außerdem zu wissen, ob unmittelbar zuvor Plugins, Themes, WordPress, PHP oder andere Einstellungen verändert wurden.
Bei auffälligen Ressourcenwerten oder Fehlermeldungen können wir anschließend gezielt prüfen, ob beispielsweise PHP, Datenbank, Prozesse oder Account-Ressourcen beteiligt sind.
Non inviare password non richieste.
Riepilogo #
Eine langsame WordPress-Website hat selten nur eine mögliche Ursache. Serverantwort, PHP, Datenbank, Plugins, Theme, Cache, Bilder, JavaScript, CSS, externe Dienste und Hosting-Ressourcen beeinflussen unterschiedliche Teile der Ladezeit.
Deshalb sollte die Optimierung nicht mit dem Installieren eines beliebigen Performance-Plugins beginnen, sondern mit einer Messung und Eingrenzung des Problems.
Ist bereits die dynamische Serverantwort langsam, solltest du insbesondere PHP-Verarbeitung, Datenbankabfragen, Plugins, externe API-Aufrufe, Cronjobs und Hosting-Ressourcen untersuchen. Antwortet der Server schnell, während die Seite im Browser langsam aufgebaut wird, rücken Bilder, JavaScript, CSS, Fonts und Drittanbieter-Ressourcen stärker in den Fokus.
Page Cache und persistenter Object Cache können WordPress erheblich entlasten, lösen aber unterschiedliche Aufgaben und ersetzen keine saubere Anwendung. Auch mehr Serverleistung ist nur dann die richtige Lösung, wenn tatsächlich Ressourcen fehlen und nicht lediglich ein fehlerhafter Prozess unnötig Last erzeugt.
Eine nachhaltige WordPress-Optimierung folgt deshalb immer demselben Prinzip: messen, Ursache bestimmen, gezielt verändern und erneut messen.
