Statistiche

Con le statistiche di WordPress in MyKinsta, è possibile scoprire cosa succede dietro le quinte del sito visualizzando un’ampia gamma di dati analitici. Permettono di indagare e individuare alcuni problemi del sito direttamente dalla dashboard di MyKinsta. Oggi approfondiremo ogni sezione delle statistiche di MyKinsta e offriremo alcuni esempi di come utilizzare questi dati per migliorare e correggere le anomalie di un sito WordPress.

Come visualizzare le statistiche di MyKinsta

La pagina Cruscotto di MyKinsta offre alcune informazioni rapide sull’utilizzo delle risorse, sul trasferimento dei dati (larghezza di banda), sulle visite uniche al sito live e sull’utilizzo del CDN (se applicabile).

Per approfondire i report, potete consultare le statistiche di tutti i siti del vostro piano andando su to your nome utente > Impostazioni Azienda > Statistiche. Nota: se si dispone anche di un Hosting di Applicazioni o Hosting di Database, è necessario selezionare la sottopagina Siti WordPress. Quando si visualizzano le statistiche a livello aziendale, si visualizzano i dati per tutti i siti e gli ambienti WordPress.

Per visualizzare le statistiche solo per un sito specifico (statistiche a livello di sito), andate su Siti WordPress > nome sito > Statistiche.

Potrete quindi scegliere di visualizzare i dati relativi alle ultime 24 ore, 7 giorni, 30 giorni o al ciclo di fatturazione corrente (Mese corrente nel menu a tendina).

Le statistiche sono suddivise in sette diverse sezioni, che approfondiremo qui di seguito:

Risorse

Nella sezione Risorse potrete visualizzare il numero totale di visite, lo spazio su disco, l’utilizzo della larghezza di banda, le principali richieste per byte e le principali richieste per visualizzazioni.

Utilizzo piano

La sezione Utilizzo piano mostra i totali per tutti i siti del piano dell’azienda. Le informazioni sull’Utilizzo del disco vengono calcolate una volta al giorno per ogni sito web in diversi momenti. Ciò significa che la quantità di spazio su disco utilizzato può variare nel corso della giornata e il totale per tutti i siti web potrebbe non essere del tutto preciso fino al giorno successivo.

Distribuzione dell’utilizzo del piano

Il rapporto sulla distribuzione dell’utilizzo del piano mostra una ripartizione del numero di visite, dell’utilizzo della larghezza di banda e dello spazio su disco per ogni sito WordPress del vostro piano aziendale. Spazio su disco si riferisce alla capacità di memorizzazione attualmente in uso e visualizza sempre i dati più recenti nell’arco di tempo specificato. È possibile ordinare il grafico per Visite, Larghezza di banda, o Spazio su disco in ordine crescente o decrescente facendo clic sull’intestazione corrispondente.

Poiché i piani di hosting di Kinsta si basano sul numero totale di visitatori del vostro sito live, è possibile identificare la quantità di piano utilizzata da ciascun sito. L’utilizzo della larghezza di banda e dello spazio su disco vi aiutano a identificare i siti su cui potreste dover effettuare ulteriori analisi per la risoluzione dei problemi.

Visite

Il grafico delle visite mostra il numero di visite all’ambiente WordPress (Live, Staging Standard, o Staging Premium). Questo grafico utilizza il tempo universale coordinato (UTC).

Se si evidenzia un punto specifico del grafico, viene mostrato il numero di visite per quel giorno e una percentuale di confronto con il punto precedente (giorno o ora, a seconda dell’intervallo di tempo selezionato). Questo è il numero esatto di visite all’ambiente. I filtri e le regole di Google Analytics non si applicano in questo caso. Tutti i servizi mostreranno un numero diverso in base alla propria serie di regole: chi considerano irrilevante/traffico bot e chi no.

I piani di hosting di Kinsta si basano sul numero totale di visitatori del sito live. Solo le visite all’ambiente live vengono conteggiate nell’utilizzo del piano (indicato nella parte superiore della pagina delle statistiche a livello aziendale e nella sezione delle statistiche di WordPress della pagina Cruscotto). È possibile leggere maggiori informazioni su come Kinsta conta le visite.

Nota: Il totale delle visite nella sezione Risorse delle statistiche può differire dal totale visualizzato nella pagina Cruscotto di MyKinsta. Questo perché la pagina Cruscotto di MyKinsta mostra sempre le visite effettuate nell’ambito del ciclo di fatturazione corrente.

Spazio su disco

Il grafico dello spazio su disco mostra il limite di spazio di archiviazione e il suo utilizzo. Nota: l’utilizzo dello spazio su disco non può essere visualizzato per le ultime 24 ore, quindi bissognerà selezionare 7 giorni, 30 giorni o il mese corrente nel menu a tendina dell’intervallo di tempo nella parte superiore della pagina.

Larghezza di banda

Il report sull’utilizzo della larghezza di banda mostra il totale dei dati utilizzati dal sito. Kinsta addebita i piani in base al numero di visitatori del sito, ma l’utilizzo della larghezza di banda può aiutare a individuare e risolvere i problemi di performance. Questo grafico utilizza il tempo universale coordinato (UTC).

Se si evidenzia un punto specifico del grafico, verranno mostrati alcuni dati di confronto, come ad esempio la differenza percentuale tra un giorno e l’altro.

Consigliamo vivamente a tutti i clienti di implementare un CDN. Non solo perché si registrerà un aumento della velocità, ma anche perché questo può essere un ottimo modo per ridurre l’utilizzo di larghezza di banda e risorse utilizzate dal sito. La larghezza di banda del CDN è molto economica o addirittura gratuita. Date un’occhiata al nostro articolo approfondito sui vantaggi di un CDN per WordPress e sul perché bisognerebbe usarne uno. Oppure, scoprite come attivare il CDN di Kinsta sul vostro sito.

Principali richieste per byte

Un byte è una sequenza di bit binari in un flusso di dati serializzato nei sistemi di trasmissione dati. Per quanto riguarda un sito WordPress, questo valore è normalmente misurato in MB, GB e TB. Il numero totale di byte trasferiti sul sito costituisce la larghezza di banda. Nel report Principali Richieste per Byte si vede quali sono le richieste al sito che consumano più larghezza di banda.

Principali richieste per visualizzazioni

Il report Principali Richieste per Visualizzazioni mostra le risorse più richieste dal sito sul server, indipendentemente dalle dimensioni. Se il sito utilizza una larghezza di banda superiore al previsto, questo report e quelli precedenti possono aiutare a risolvere i problemi e a stabilire dove va a finire la larghezza di banda. Spesso è possibile individuare facilmente uno schema.

CDN & edge

Nella sezione Utilizzo CDN, se è abilitato il CDN di Kinsta, è possibile visualizzare la larghezza di banda del CDN, i file principali in base alle richieste, i file principali in base ai byte e le estensioni dei file principali in base ai byte. Se un particolare file multimediale del sito sta usando tutta la vostra larghezza di banda, è possibile individuarlo qui.

Larghezza di banda CDN

Il report sull’utilizzo della larghezza di banda CDN mostra il totale dei dati CDN utilizzati dal sito. Questo grafico utilizza il tempo universale coordinato (UTC).

Se si evidenzia un punto specifico del grafico, vengono mostrati alcuni dati di confronto, come la differenza percentuale tra un giorno e l’altro.

Larghezza di banda Edge

Questo grafico mostra i dati totali serviti dalla edge cache. Questo grafico utilizza il tempo universale coordinato (UTC).

Se si evidenzia un punto specifico del grafico, vengono mostrati alcuni dati di confronto, come la differenza percentuale tra un giorno e l’altro.

Principali file per richieste

Il report Principali file per richieste mostra i file più richiesti sul vostro sito serviti dal CDN. Questo può aiutarvi a identificare quali file sono responsabili della maggior parte dell’utilizzo della larghezza di banda del CDN.

Principali file per byte

Il report Principali file per byte mostra i file più grandi del sito serviti dal CDN. Questo può aiutare a individuare i file di grandi dimensioni che si potrebbe ottimizzare, riducendo le dimensioni del file e l’utilizzo della larghezza di banda del CDN.

Principali estensioni file per byte

Il report sulle principali estensioni di file per byte mostra le principali X estensioni di file servite dal CDN. Questo può aiutare a individuare i tipi di file multimediali del sito che utilizzano maggiormente la larghezza di banda del CDN.

Dispersione

Nella sezione Dispersione si possono visualizzare diverse informazioni sul traffico del sito.

Desktop vs. Tablet vs. Mobile

Il grafico desktop vs. tablet vs. mobile consente di vedere quali sono i dispositivi che raggiungono il vostro sito. Nell’esempio che segue, si può notare che il traffico è prevalentemente desktop, al 95%.

Performance

Nella sezione Performance, è possibile visualizzare il tempo di risposta medio di PHP + MySQL, il throughput di PHP, il limite di memoria PHP raggiunto, limite di thread PHP, utilizzo di AJAX, tempo di risposta PHP + MySQL medio e tempo massimo di upstream.

Tempi medi di Risposta PHP + MySQL

Ogni volta che si visita un sito WordPress, vengono utilizzati PHP e MySQL per compilare e interrogare i dati che si vedono nella pagina. Questo grafico mostra il tempo medio di risposta del motore PHP e del motore MySQL per ogni richiesta non memorizzata.

Se questo valore è alto o mostra un picco recente, non esitate ad aprire una nuova chat con il nostro team di supporto per verificare se ci sono problemi legati al server. Se non si riscontrano problemi legati al server, consigliamo di utilizzare il nostro strumento APM per individuare i problemi di prestazioni.

Throughput PHP

Il throughput è il numero di transazioni per unità di tempo. In questo report, ci si riferisce al throughput PHP del sito WordPress. In altre parole, mostra quante richieste totali sono state eseguite nel periodo di tempo selezionato. Il grafico a linee mostra una ripartizione più dettagliata per ore o giorni (a seconda dell’intervallo di tempo).

Limite di memoria PHP raggiunto

Questo diagramma mostra quante volte è stato raggiunto il limite di memoria PHP. Kinsta ha un limite di memoria PHP predefinito di 256MB, più che sufficiente per la maggior parte dei plugin e siti WordPress. Questo limite esiste per impedire agli script PHP di consumare troppa memoria. Se si imposta un limite troppo alto, uno script non configurato correttamente o non funzionante può causare seri problemi utilizzando troppa memoria. Se il vostro sito è impostato correttamente su Kinsta, non dovreste raggiungere il limite di memoria PHP.

Potete modificare il limite di memoria PHP di un sito per thread da Siti WordPress > nome sito > Info > Prestazioni PHP > Modifica. Se si aumenta la memoria per thread, si riduce il numero di thread PHP disponibili e, quindi, il numero di richieste in entrata che il sito può gestire contemporaneamente. Tuttavia, è anche possibile modificare il Pool di memoria totale per aumentare il numero di thread e la memoria disponibile per il sito.

Limite dei PHP thread

Il grafico del limite dei PHP thread mostra quante volte il motore PHP ha raggiunto il massimo dei PHP thread allocati. Ad esempio, se il piano include 4 PHP thread e il sito utilizza tutti e 4 i PHP thread contemporaneamente e non può rispondere immediatamente alle richieste PHP in arrivo, questo conterà come un caso di raggiungimento del limite di PHP thread.

Questo può fornire solo un quadro parziale dell’attività dei thread PHP, poiché registra solo il numero di volte in cui viene raggiunto il limite di thread PHP e non il tempo in cui tutti i thread PHP sono stati utilizzati.

Ogni piano di hosting di Kinsta comprende un numero predefinito di thread PHP. È possibile modificare il numero di thread PHP per ogni sito da Siti WordPress > nome sito > Info > Prestazioni PHP > Modifica. Se si aumenta il numero di thread, si riduce il limite di memoria per thread; tuttavia, si può anche modificare il Pool di memoria totale per aumentare sia il numero di thread che la memoria disponibile per il sito. Le informazioni contenute in questo grafico possono aiutare a valutare se il sito sta superando continuamente i limiti.

Utilizzo di AJAX

AJAX (Asynchronous JavaScript and XML) è un termine che descrive l’uso di uno script lato client che permette di aggiornare parti di una pagina web senza dover fare un postback o un refresh della pagina.

Per quanto riguarda WordPress, potreste aver visto admin-ajax.php nei test di velocità. WordPress usa Ajax per le principali funzioni di amministrazione, come il salvataggio automatico dei post, la gestione della sessione utente e le notifiche. Le chiamate Ajax per queste funzioni avvengono attraverso il file admin-ajax.php in /wp-admin.

I problemi più comuni con Ajax in WordPress sono dati da plugin che ne causano il picco e da problemi di CPU sul back-end. Per maggiori informazioni, si dia un’occhiata al nostro articolo di approfondimento sulla diagnosi dell’elevato utilizzo di Admin-AJAX in WordPress.

Il grafico dell’utilizzo di AJAX mostra il conteggio delle richieste di admin-ajax e permette di vedere se ci sono picchi di utilizzo di Ajax in determinati periodi. Selezionando una delle barre del grafico, potrete vedere il numero di richieste Ajax per quel particolare periodo di tempo. Potrete quindi seguire alcuni dei suggerimenti contenuti nel post che abbiamo citato sopra per restringere le cause di questi picchi.

Principali tempi di risposta medi di PHP + MySQL

Questo elenco mostra i percorsi con i tempi di risposta più elevati di PHP e MySQL. Il tempo mostrato è la media per richiesta, non il tempo totale per tutte le richieste. Questi valori possono rappresentare dei picchi una tantum, quindi è meglio confrontare questo elenco con l’elenco Principali tempi massimi di upstream.

Tempi massimi di upstream

Il tempo di upstream è il tempo totale impiegato da NGINX (e dai server upstream) per elaborare una richiesta e inviare una risposta. Questo elenco mostra i percorsi con i tempi massimi di upstream di PHP e MySQL (combinati) per le richieste. Il tempo si riferisce alla singola richiesta, non al tempo totale per tutte le richieste.

Risposta

Nella sezione Risposta si può visualizzare la ripartizione dei codici di risposta, le statistiche di risposta, la ripartizione degli errori 500, la ripartizione degli errori 400, la ripartizione dei redirect e i principali errori 404.

Suddivisione dei codici di risposta

Il grafico della suddivisione dei codici di risposta offre una panoramica della distribuzione dei codici di stato HTTP serviti per le risorse richieste. I codici di risposta, noti anche come codici di stato HTTP, non sono sempre negativi. Ad esempio, un codice di stato HTTP 200 significa “Tutto OK”. Questo codice viene fornito quando una pagina web o una risorsa si comporta esattamente come ci si aspetta. Approfondiremo gli altri più avanti.

Statistiche di risposta

Il report delle Statistiche di risposta mostra il numero totale di redirect, gli errori, la percentuale di successo e la percentuale di errori. Ogni sito WordPress presenta un leggero tasso di errore, il che è del tutto normale.

Suddivisione errori 500

Il grafico Grafico Suddivisione Errori 500 mostra il numero totale di errori 500 che si sono verificati sul server. Ecco una spiegazione più precisa del significato di ciascuno di essi:

• 500: “Si è verificato un errore sul server e non è stato possibile completare la richiesta”. Si tratta di un codice generico che indica un “errore interno del server“. Qualcosa è andato storto sul server e la risorsa richiesta non è stata consegnata.
• 502: “Bad Gateway”. Questo codice di errore indica che un server ha ricevuto una risposta non valida da un altro. A volte una query o una richiesta impiega troppo tempo e quindi viene annullata o uccisa dal server. Leggi di più su come risolvere un errore 502 bad gateway.
• 503: “Il server non è disponibile per gestire questa richiesta in questo momento”. La richiesta non può essere completata in questo momento. Questo codice può essere restituito da un server sovraccarico che non può gestire altre richieste. Abbiamo una guida passo passo su come risolvere l’errore 503 service unavailable in WordPress.

Suddivisione errori 400

Il grafico Suddivisione Errori 400 mostra il numero totale di errori 400 che si sono verificati sul server. Ecco una spiegazione più precisa del significato di ciascuno di questi errori:

• 401: “Non autorizzato“. Il server restituisce questo errore quando la risorsa di destinazione non dispone di credenziali di autenticazione valide.
• 403: “L’accesso a quella risorsa è proibito”. Questo codice viene restituito quando un utente tenta di accedere a qualcosa a cui non ha il permesso di accedere. Ad esempio, il tentativo di visualizzare un contenuto protetto da password senza aver effettuato il login può produrre un errore 403.
• 404: “La risorsa richiesta non è stata trovata”. È il messaggio di errore più comune di tutti. Questo codice significa che il server non riesce a trovare la risorsa richiesta e non sa se sia mai esistita.
• 405: “Metodo non consentito“. Questo errore viene generato quando il server di hosting (server di origine) supporta il metodo ricevuto, ma la risorsa di destinazione non lo supporta.
• 429: “Troppe richieste“. Il server genera questo errore quando l’utente ha inviato un numero eccessivo di richieste in un determinato periodo di tempo (limitazione della velocità). Spesso questo errore è causato da bot o script che cercano di entrare con la forza bruta nella pagina di accesso predefinita di WordPress. Si può provare a bloccare il sito cambiando l’URL di accesso a WordPress.
• 499: “Richiesta chiusa dal client”. Questo errore viene restituito da NGINX quando il cliente chiude la richiesta mentre NGINX la sta ancora elaborando.

Suddivisione redirect

Il grafico Suddivisione redirect mostra il numero totale di reindirizzamenti che si sono verificati sul server. Come i codici di risposta 200, non tutti i codici di risposta sono negativi. I codici di risposta 300 in genere significano che il contenuto è stato spostato altrove. I redirect 301, ad esempio, sono molto importanti perché aiutano a mantenere le posizioni nelle classifiche SEO per le modifiche agli URL e ai siti. Ecco una spiegazione più precisa del significato di ciascuno di questi codici.

• 301: “La risorsa richiesta è stata spostata in modo permanente”. Questo codice viene inviato quando una pagina web o una risorsa è stata sostituita in modo permanente con una risorsa diversa. Viene utilizzato per il reindirizzamento permanente degli URL.
• 302: “La risorsa richiesta è stata spostata ma è stata trovata”. Questo codice indica che la risorsa richiesta è stata temporaneamente spostata in una posizione diversa.
• 304: “La risorsa richiesta non è stata modificata dall’ultimo accesso”. Questo codice indica al browser che le risorse memorizzate nella cache del browser non sono cambiate. Accelera la consegna delle pagine web riutilizzando le risorse scaricate in precedenza.

Principali errori 404

L’elenco degli Principali Errori 404 aiuta a risolvere i problemi relativi alle risorse che non esistono sul sito più richieste dai visitatori o dai bot automatici.

Se si vedono un gran numero di errori 404, in genere è consigliato analizzare il sito e risolverli per non danneggiare SEO e usabilità. Potete anche cercarli in Google Search Console alla voce errori di crawl.

Cache

La sezione Cache mostra lo stack dei componenti della cache, il grafico dei componenti della cache e il totale dei bypass della cache.

Stack componenti cache

Ogni volta che un file o una risorsa viene richiesta dai server di Kinsta, quest’ultimo invia un valore nell’intestazione della risposta HTTP (X-Kinsta-Cache) per informare sullo stato della cache.

Esistono quattro tipi di header della risposta della cache:

• HIT: HIT significa che la risorsa viene servita dalla cache dei server di Kinsta. In genere è quello che si vuole vedere.
• BYPASS: significa che probabilmente una regola o un conflitto impedisce alla risorsa di essere memorizzata nella cache. Abbiamo delle regole per evitare che alcuni elementi del sito WordPress vengano memorizzati nella cache. Ad esempio, la pagina /wp-login.php non viene memorizzata nella cache, il che garantisce una corretta funzionalità quando si accede alla dashboard.
• MISS: significa che il contenuto non era ancora presente nella cache ma lo sarà dopo la prima richiesta. La seconda richiesta di quel file sarà un HIT della cache. Ogni volta che si cancella la cache del sito WordPress, questa deve essere ricostruita dalle persone che lo visitano. Per questo motivo consigliamo di non svuotare costantemente l’intera cache. Il plugin Kinsta MU cancella automaticamente solo alcune sezioni del sito in modo che il resto possa rimanere nella cache. Ulteriori informazioni sono disponibili nell’articolo come Kinsta gestisce la cache.
• EXPIRED: Significa che il contenuto nella cache è scaduto e che è stato recuperato il nuovo contenuto dal server di hosting.

Il report sullo stack dei componenti della cache mostra il numero totale di valori degli header di risposta della cache generate dal sito.

Grafico dei componenti della cache

Il grafico dei componenti della cache è un altro strumento per visualizzare i valori totali delle intestazioni di risposta della cache.

Principali bypass della cache

Il report Principali bypass della cache mostra le principali richieste che aggirano la cache del sito. È bene dare un’occhiata a questo report per assicurarsi che i percorsi in questione bypassino la cache. L’esempio qui sotto mostra che /wp-cron.php non viene memorizzato nella cache, il che è necessario affinché WP-Cron funzioni come previsto.

Geo & IP

Nella sezione Geo & IP si possono visualizzare i paesi, le città e gli indirizzi IP da cui provengono la maggior parte delle visite al sito. Questo permette di conoscere i paesi, le città e i singoli indirizzi IP dei visitatori del sito.

Paesi principali

L’elenco dei Paesi principali può aiutare a stabilire se il data center in cui si trova il vostro sito è la posizione migliore. È un’analisi geografica per paese degli indirizzi IP dei visitatori. Nell’esempio che segue, il sito dovrebbe essere collocato su un server negli Stati Uniti, dato che la maggior parte del traffico proviene da lì.

Kinsta ha ora 37 sedi di Google Cloud Platform in tutto il mondo dove ospitare i siti WordPress. Per maggiori informazioni, date un’occhiata al nostro articolo di approfondimento sulla latenza di rete e sul perché è importante posizionare il sito in modo strategico.

Città principali

L’elenco delle Città principali mostra l’analisi geografica per città degli indirizzi IP dei visitatori.

IP client principali

L’elenco degli IP client principali può essere utile se il sito consuma improvvisamente molta banda. Mostra i principali indirizzi IP ordinati in base al numero di richieste.

Come utilizzare questi dati? Ecco un esempio di un caso di studio su un sito di ecommerce basato su WordPress. L’analisi dei 10 principali IP negli ultimi 7 giorni ha evidenziato alcune attività sospette. La maggior parte di essi aveva più di 10.000 richieste e c’erano parecchi IP con un numero di richieste molto elevato. Molto probabilmente si trattava di un attacco DDoS o di forza bruta. Inserendo un paio dei principali IP nella ricerca di Google, abbiamo appurato che la maggior parte di essi erano indirizzi proxy, il che significa che qualcuno probabilmente voleva nascondere il proprio traffico.

La buona notizia è che, oltre alla protezione firewall, la nostra integrazione di Cloudflare include anche una protezione DDoS (Distributed Denial of Service) gratuita. Se si ha bisogno di ulteriori interventi, basta contattare il nostro team di supporto. Se necessario, possiamo bloccare gli IP per voi.

Altre opzioni sono la creazione di un proprio account Cloudflare (dove attivare e configurare il Web Application Firewall di Cloudflare con regole più specifiche per il sito) o l’aggiunta di un altro web application firewall come Sucuri.

Note aggiuntive

I dati analitici completi vengono conservati per 30 giorni. Consigliamo di controllare più frequentemente le pagine Dashboard e Statistiche dopo la prima migrazione a Kinsta. Se notate un picco di traffico inspiegabile o un’incongruenza preoccupante, contattate il nostro team di supporto e analizzeremo i log per stabilire la causa.

Speriamo che con tutti i dati di cui abbiamo parlato qui sopra sia più chiaro come Kinsta fornisce i contenuti ai vostri visitatori.