Statistiche
Con WordPress Analytics in MyKinsta, è possibile scoprire cosa succede dietro le quinte del sito visualizzando un’ampia gamma di dati analitici. Permette di indagare e individuare alcuni problemi del sito direttamente dalla dashboard di MyKinsta. Oggi approfondiremo ogni sezione di MyKinsta Analytics e offriremo alcuni esempi di come utilizzare questi dati per migliorare e correggere le anomalie di un sito WordPress.
Come entrare nelle 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 alla pagina Impostazioni Azienda > Statistiche. Nota: se si dispone anche di Hosting applicazioni o Hosting database, è necessario selezionare la sottopagina 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), andare su Siti WordPress > nome del 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:
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.
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.
Visite
Il grafico delle visite mostra il numero di visite all’ambiente WordPress (Live, Staging Standard, o Staging Premium). 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. Si ricordi che i filtri e le regole di Google Analytics non si applicano in questo caso. Tutti i servizi mostreranno un numero diverso in base alle loro 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 del 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 risolvere i problemi di performance. 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 vedrà un aumento della velocità, ma anche perché questo può essere un ottimo modo per ridurre la larghezza di banda e le 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, se siete pronto, scoprite come attivare il CDN di Kinsta sul 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.
Utilizzo CDN
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 occupando tutta la tua larghezza di banda, è possibile individuarlo qui.
Larghezza di banda
Il report sull’utilizzo della larghezza di banda del CDN mostra il totale dei dati del CDN utilizzati dal sito. 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.
Principali file per richieste
Il report “Principali File per Richieste” mostra i file più richiesti sul sito serviti dal CDN. Questo può aiutare a individuare i file responsabili del maggiore 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, con l’87%.
Performance
Nella sezione Performance, è possibile visualizzare il tempo di risposta medio di PHP + MySQL, il throughput di PHP, il limite di PHP worker, l’utilizzo di AJAX, il tempo di risposta medio di PHP + MySQL e il 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 dei PHP worker
Il grafico del limite dei PHP worker mostra quante volte il motore PHP ha raggiunto il massimo dei PHP worker allocati. Ad esempio, se il piano include 4 PHP worker e il sito utilizza tutti e 4 i PHP worker contemporaneamente e non può rispondere immediatamente alle richieste PHP in arrivo, questo conterà come un caso di raggiungimento del limite di PHP worker.
Ogni piano di hosting di Kinsta include un certo numero di PHP worker. Le informazioni contenute in questo grafico possono aiutare a capire se il sito sta raggiungendo 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.
Tempo di risposta medio di PHP + MySQL
Questo elenco mostra i percorsi con i tempi di risposta più elevati di PHP e MySQL. 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.
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.
Ripartizione dei codici di risposta
Il grafico della ripartizione 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. Si ricordi che, 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 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 intestazioni 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. Si ricordi che 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. Si legga di più su 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 componenti 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 e IP
Nella sezione Geo e 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 tuo 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, si legga il 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 sopra abbiate sia più chiaro come Kinsta fornisce i contenuti ai vostri visitatori.