Benchmark di WordPress: testare in modo riproducibile le prestazioni dell'hosting

Cosa rivela un benchmark di WordPress

A Benchmark di WordPress Si parte da una domanda concreta: una determinata pagina si carica rapidamente in determinate condizioni? A tal fine, un browser carica codice HTML, immagini, script e altre risorse e visualizza la pagina. Il risultato descrive l’interazione tra questi elementi, non solo la velocità del server di hosting.

Una seconda domanda riguarda il Comportamento in risposta sotto carico: Come cambiano i tempi di risposta e gli errori quando arrivano richieste che corrispondono a un profilo prestabilito? Una singola visita alla pagina non basta a rispondere a questa domanda. D’altra parte, un test di carico HTTP non mostra immediatamente la velocità con cui un browser carica la pagina completa in modo visibile.

Nel caso di un articolo pubblicato su un blog, la cache della pagina può fornire codice HTML già pronto; un CDN può rendere disponibili risorse o risposte più vicine alla posizione di misurazione. Allo stesso tempo, il tema, i plugin, le immagini e gli script esterni influenzano il risultato. Quali altre cause possono rallentare una pagina è spiegato nell'articolo su Fattori nascosti che compromettono le prestazioni di WordPress.

Per valutare l'influenza dell'hosting, sono utili due domande di confronto. Nel caso del Confronto tra stack Adegua il più possibile il sito web e le impostazioni e documenta le differenze rimanenti. Nel confronto tra i pacchetti, verifica le configurazioni offerte, comprese le rispettive cache e i servizi. Questo approccio è utile ai fini della decisione di acquisto, ma non isola le prestazioni pure del server.

Tieni quindi presente quale pagina, quale tariffa e quale contesto corrispondono a un determinato risultato. Un vantaggio per l’articolo del blog sottoposto a test potrebbe risultare diverso se visualizzato da un account registrato. La misurazione è valida per le condizioni e il periodo di tempo documentati; non costituisce né un vincitore generale del test né una garanzia di prestazione.

Comprendere le misurazioni del browser e i dati sul campo

Un test di velocità di WordPress con Lighthouse fornisce un Foto del laboratorio della pagina in determinate condizioni di misurazione. Il profilo del browser, il dispositivo o l’emulazione, il profilo di rete, la posizione di misurazione e la versione dello strumento devono quindi essere riportati nel protocollo. Solo così sarà possibile valutare in seguito se due esecuzioni sono effettivamente comparabili.

Il Lighthouse Performance Score riassume diversi parametri in modo ponderato. Può variare a causa di contenuti e condizioni di misurazione mutevoli e non evidenzia quale singolo parametro sia cambiato. Ripeti la misurazione con lo stesso profilo e documenta i singoli valori di tutte le esecuzioni, invece di selezionare solo il punteggio migliore.

Tra i parametri più importanti figura l’LCP: descrive il momento in cui viene caricato in modo visibile l’elemento di contenuto più grande e rilevante. Il CLS rileva gli spostamenti imprevisti del layout durante l’utilizzo. L’INP descrive la reattività alle interazioni; per calcolarlo sono necessarie interazioni effettivamente registrate e non è determinato esclusivamente da un semplice caricamento della pagina.

Il Chrome UX Report, abbreviato in CrUX, fornisce invece, se disponibili, Dati sul campo dalle visite degli utenti reali che partecipano al test. Queste esperienze dipendono, tra l’altro, dai loro dispositivi e dalle loro reti. Non sono disponibili per ogni pagina e rispondono a una domanda diversa rispetto a un test di laboratorio eseguito in condizioni controllate.

Per ogni valore, indica se proviene dal laboratorio o dall'ambiente reale. Una semplice richiesta HTTP, ad esempio, può rilevare lo stato e il tempo di risposta, ma non esegue automaticamente il rendering e le interazioni di un browser. Pertanto, da essa non è possibile ricavare LCP, CLS e INP come esperienza di navigazione.

Distinguere correttamente i livelli della cache

A Cache di pagina può memorizzare codice HTML già pronto per richieste ripetute. Una cache degli oggetti, invece, memorizza i dati dell’applicazione necessari a WordPress durante l’elaborazione. Inoltre, il browser può riutilizzare localmente le risorse già caricate; un CDN può memorizzare temporaneamente i contenuti a un ulteriore livello al di fuori del server originale.

Nel caso di una cache delle pagine “calda”, si effettua l’accesso ripetuto a una pagina pubblica dopo una fase di riscaldamento documentata. Ciò è rilevante per i contenuti visitati di frequente, ma non fornisce molte indicazioni sul costo della loro generazione dinamica. Annota quali URL sono stati riscaldati e quali regole di cache e impostazioni CDN erano in vigore.

Per una richiesta non memorizzata nella cache, devi impostare il Bypass della cache verificalo in modo comprensibile, invece di limitarti ad accettarlo. Una sessione registrata può seguire regole diverse e fornire contenuti personalizzati. Controlla la risposta effettiva: un recupero veloce ha poco valore se fornisce un contenuto errato o obsoleto.

Una prima visita in una nuova condizione del browser non implica necessariamente che la cache del server o del CDN sia vuota. Allo stesso modo, un errore del CDN non comporta automaticamente lo svuotamento della cache dell’applicazione. Gli header della cache possono fornire indicazioni, ma, a seconda del provider, non dimostrano lo stato di ogni livello coinvolto; pertanto, è opportuno documentare anche le impostazioni disponibili e i metodi di verifica.

In assenza di un’estensione persistente adeguata, la cache degli oggetti di WordPress è generalmente limitata alla rispettiva richiesta. La costante WP_CACHE Da solo, non attiva né Redis né una soluzione di caching automatica. Il ruolo che Redis e Memcached possono svolgere come cache di oggetti persistente viene illustrato nell'articolo su Redis e Memcached nell'hosting WordPress.

Preparare il confronto e le approvazioni

Per confrontare i servizi di hosting, devi innanzitutto procurarti un stato del sito web comparabile. Crea una copia pulita con gli stessi contenuti, lo stesso set di dati, lo stesso tema e gli stessi plugin, comprese le relative versioni. Rimuovi o sostituisci i dati personali e le credenziali di accesso di produzione in modo che il sito di prova rifletta comunque il caso d'uso desiderato.

Utilizza, per quanto possibile, le stesse versioni di PHP e del database, nonché le impostazioni pertinenti. Prendi nota delle differenze che non è possibile eliminare o che fanno parte del pacchetto acquistato. Un confronto tra i rispettivi pacchetti standard risponde a una domanda diversa rispetto a un confronto tra stack il più possibile allineati: il risultato non può essere attribuito semplicemente alle prestazioni del server.

Prima della prima esecuzione, definisci un piano di misurazione. Deve essere sufficientemente dettagliato da consentire a un’altra persona di ricostruire la procedura e individuare eventuali discrepanze in caso di ripetizione. La seguente lista di controllo distingue le caratteristiche dell’offerta di hosting da quelle del sito web e della misurazione.

• Tariffa, limiti delle risorse, ubicazione del server e versioni del software di entrambi gli ambienti.
• URL di prova e tipi di pagina, stato di accesso, cookie e account di prova utilizzati.
• CDN, cache delle pagine e cache degli oggetti, comprese le regole, la fase di riscaldamento e il bypass pianificato.
• Luogo di misurazione, versione dell'utensile, profilo del browser e del dispositivo, condizioni di rete, orari e ripetizioni.
• Profilo di carico, responsabilità, finestra di prova concordata e limiti concreti di interruzione.

Per i test di carico, concordi le Rilascio Con tutti i responsabili e, se del caso, con l’host, prima di generare traffico. Chiarisci chi sono i referenti, i limiti delle risorse e la procedura da seguire in caso di malfunzionamenti. Escludi i servizi esterni senza il loro consenso; in particolare, impedisci che vengano effettuati pagamenti reali, ordini e notifiche. Verifica in anticipo se la copia di prova impedisca effettivamente tali operazioni.

Modello di misurazione per pagine tipiche

Scegli lo strumento in base alla domanda, non in base al miglior valore singolo possibile. Un Concetto di misurazione assegna a ogni riga un tipo di pagina e uno stato della cache. La tabella mostra quali risultati è possibile ottenere con i rispettivi approcci e quali sono i loro limiti.

Per un articolo di blog pubblico, misura più volte lo stesso URL rappresentativo utilizzando un profilo fisso di browser e rete. Prendi nota se il CDN e la cache della pagina sono attivi e in che modo la pagina è stata “riscaldata” prima delle misurazioni. In questo modo è possibile valutare l’esperienza di caricamento di questa pagina pubblica, non automaticamente quella di una sessione con accesso effettuato.

A ogni ricerca dinamica o visualizzazione dell'account viene assegnata una serie di misurazioni dedicata, con dati di test condivisi e, se necessario, un account di prova. Non limitarti a controllare il codice di stato: la risposta deve corrispondere alla richiesta di ricerca o all'account con cui si è effettuato l'accesso ed essere aggiornata. Verifica inoltre se un'operazione pianificata Bypass della cache effettivamente funziona; un cookie da solo non lo dimostra.

Il fatto che i tempi di risposta differiscano non significa che la causa sia stata individuata. La logica applicativa, gli accessi al database, una cache di oggetti persistente e l’ambiente di hosting possono tutti contribuire a determinare il risultato. Documenta le differenze nella struttura e analizzale poi in modo mirato, invece di considerare una singola richiesta lenta come prova di un determinato collo di bottiglia.

Aumentare gradualmente il carico durante il test di sforzo

Inizia su una pagina di test espressamente autorizzata con poche singole richieste. Controlla lo stato e il contenuto e assicurati che non si verifichino effetti collaterali sulla produzione. Solo in seguito si procede a un test di carico concordato separatamente, ad esempio per le pagine di prodotto autorizzate di un negozio online. Sono esclusi ordini, pagamenti e notifiche reali.

Organizza una carico graduale con livello iniziale, durata e incrementi. Concorda in anticipo soglie di interruzione misurabili relative a errori, tempi di risposta o altri parametri operativi disponibili, nonché un referente per l’interruzione. Attieniti alle procedure espressamente consentite; la visualizzazione di un prodotto non fornisce alcuna indicazione su una procedura di checkout non testata.

Nel modello di carico chiuso, un’istanza utente virtuale attende la fine della propria iterazione corrente prima di iniziare quella successiva. Se l’applicazione rallenta, il carico offerto può diminuire di conseguenza. Il modello è adatto a processi in cui proprio questa attesa è parte integrante del processo; tuttavia, non mantiene un tasso di arrivo costante.

A modello di carico aperto pianifica invece nuove iterazioni indipendentemente dal fatto che quelle precedenti siano state completate. A tal fine, il generatore di carico deve disporre di capacità sufficiente e di istanze utente virtuali disponibili. Se non è in grado di avviare le iterazioni, il test non raggiunge il profilo previsto; pertanto, documenta anche queste iterazioni non avviate.

Registra sia la velocità impostata che quella effettivamente raggiunta. Le iterazioni al secondo corrispondono alle richieste al secondo solo se ogni iterazione genera esattamente una richiesta. Registra inoltre la distribuzione dei tempi di risposta, gli errori e i timeout, nonché la verifica della correttezza dei contenuti: un throughput elevato con risposte errate non costituisce un test di carico riuscito.

Analizzare le serie di misurazioni in modo trasparente

Una serie di misurazioni è significativa solo se considerata nel suo insieme. Annota quindi, per ogni pagina testata e per ogni fase di carico, il numero di richieste analizzate, nonché il numero di errori e di timeout. Distingui le risposte andate a buon fine da quelle fallite, senza omettere i casi di errore dal rapporto: un tempo di risposta basso in presenza di numerosi errori non è indice di un servizio affidabile e veloce.

Il sito Mediano descrive il valore medio delle misurazioni riuscite ordinate. Il 95° percentile, abbreviato in p95, indica inoltre una soglia al di sotto della quale si trova circa il 95% di questi valori di misura. In presenza di un numero esiguo di richieste, il p95 dipende fortemente dalle singole osservazioni; pertanto, indica sempre la dimensione del campione e interpreta le differenze con cautela.

Per ogni esecuzione, registra anche il modello di carico e la velocità effettivamente raggiunta. Una velocità configurata da sola non indica se il generatore sia riuscito ad avviare tutte le iterazioni previste. Il seguente modello rimane vuoto fino al momento della misurazione; a ciascuna esecuzione viene assegnato un proprio protocollo.

Salva i dati grezzi, lo script di test e la configurazione insieme al log. In questo modo sarà possibile verificare in seguito quali richieste sono state incluse nell’analisi e se due serie di dati sono effettivamente comparabili. Non selezionare a posteriori solo l'esecuzione più veloce: se i risultati si sovrappongono in modo significativo, la differenza osservata potrebbe rientrare nei margini di variazione.

Oltre agli indicatori, segnala anche eventuali anomalie nel contenuto, come ad esempio una pagina di accesso inaspettata al posto della prevista visualizzazione del conto. Uno stato tecnico positivo non dimostra di per sé che sia stata visualizzata la pagina corretta. Tali discrepanze devono essere riportate separatamente nella descrizione dell’errore e possono rendere inutilizzabile una serie di misurazioni ai fini della decisione prevista.

Individuare le cause e ripetere la misurazione

Inizia la ricerca dell'errore dalla risposta fornita: il contenuto, lo stato di accesso e l'URL testato sono corretti? Verifica quindi quanto documentato Stato della cache e l'ambiente di misurazione. Cookie diversi, una sede di misurazione diversa o una regola CDN modificata possono rendere i due test non comparabili, senza che le prestazioni dello stack applicativo vero e proprio siano cambiate.

Solo in seguito i dati operativi disponibili aiutano a circoscrivere il problema: l’utilizzo delle risorse e le code possono indicare la presenza di colli di bottiglia, mentre le informazioni relative alle applicazioni o ai database possono segnalare un’elaborazione dispendiosa. Un singolo valore HTTP lento non indica la causa. WordPress indica come fattori influenti, oltre all’hosting, anche il software, la configurazione e i contenuti.

Per un confronto “prima e dopo”, modifica intenzionalmente una sola impostazione, ad esempio l’integrazione di una cache di oggetti persistente. Lo stato del sito web, la pagina di test, il profilo di carico e la posizione di misurazione devono rimanere il più possibile invariati; documenta anche il rispettivo tempo di riscaldamento della cache. Senza un’adeguata implementazione persistente, la cache degli oggetti di WordPress è limitata alla singola richiesta, pertanto è necessario verificarne l’effettiva integrazione.

Esegui diverse sessioni prima e dopo la modifica, distribuendole nel tempo. In questo modo potrai capire meglio se una differenza si ripete o se potrebbe coincidere con normali fluttuazioni. A tal fine, non limitarti a confrontare la mediana e il p95, ma considera anche gli errori, il contenuto delle risposte e il tasso raggiunto; altrimenti, un’apparente accelerazione potrebbe essere dovuta a condizioni di test modificate.

Anche un confronto accurato non tiene conto di ogni fattore. Nel caso dell’hosting condiviso, altri utenti e infrastrutture non visibili possono influenzare il risultato. Se ti mancano i dati relativi alle risorse o alle code, segnala espressamente questa lacuna e formula una causa presunta come ipotesi anziché come risultato comprovato.

Interpretare correttamente i risultati dell'hosting

Basa la scelta dell’hosting sulle pagine e sui flussi di lavoro importanti per il tuo sito web. Un articolo di blog pubblico con una cache delle pagine attiva può generare un carico diverso rispetto alla visualizzazione di un account registrato. Una buona percentuale di risultati in cache sulle pagine pubbliche non garantisce quindi né risposte personalizzate veloci né un processo di checkout affidabile.

Prima di procedere al confronto, definisci quali tempi di risposta, quali tassi di errore e quale profilo di carico siano accettabili per il rispettivo processo. Verifica quindi se le serie di misurazioni documentate soddisfano tali requisiti nelle condizioni concordate. Ciò include anche la correttezza dei contenuti e uno svolgimento stabile; un’elevata frequenza di richieste, di per sé, non costituisce una base decisionale sufficiente.

Set utenti virtuali non sono equiparabili ai visitatori reali presenti contemporaneamente. Il loro comportamento deriva dallo script di test e dal modello di carico: nel modello chiuso, un’istanza attende la fine della propria iterazione prima di iniziare quella successiva. Senza un modello comportamentale adeguato, non è quindi possibile dedurre un numero reale di visitatori dal loro numero.

Riporta il risultato indicando il piano tariffario, lo stato del sito web, gli URL testati, le regole di cache e CDN, la località di misurazione e il periodo di riferimento. Specifica inoltre se hai confrontato stack il più possibile omogenei o i pacchetti completi offerti in ciascun caso. Nel confronto tra pacchetti, le differenze di configurazione possono influire sul risultato; tale confronto non isola automaticamente le prestazioni pure del server.

Se le serie si sovrappongono in modo significativo o se non è possibile controllare adeguatamente l'ambiente circostante, l'affermazione „non è stata dimostrata alcuna differenza significativa“ può risultare utile. Ciò non significa che entrambe le offerte abbiano la stessa velocità in tutte le condizioni, ma semplicemente che il test in questione non consente di stabilire la distinzione desiderata.

Per i controlli operativi, conserva il profilo di misurazione e ripeti le misurazioni selezionate relative al browser e al carico dopo modifiche significative o a intervalli concordati. Confronta i nuovi risultati solo con serie precedenti corrispondenti e documenta le modifiche apportate ai contenuti, alle versioni e alle regole della cache. I test di carico richiedono inoltre una finestra temporale approvata e limiti di interruzione concordati.