A volte può essere irritante rendersi conto di non avere sufficiente accesso ai dati per risolvere i problemi di WordPress. Per fortuna, con MyKinsta Analytics è possibile indagare e individuare molti di questi problemi direttamente dalla dashboard. Oggi analizzeremo approfonditamente ogni sezione di MyKinsta Analytics e offriremo alcuni esempi (e situazioni reali) di come utilizzare questi dati per migliorare e risolvere i problemi di WordPress. Ecco cosa succede sotto il cofano!

Come Entrare in MyKinsta Analytics

La pagina della Dashboard di MyKinsta offre una sintesi delle informazioni sull’utilizzo delle risorse, sul trasferimento dei dati (larghezza di banda) e sulle visite uniche. Per approfondire i report, è possibile consultare le analisi di tutti i siti del piano dalla pagina Azienda > Statistiche o andando alle Statistiche di un sito specifico (Siti > nome del sito > Statistiche).

Statistiche a livello aziendale in MyKinsta.
Statistiche a livello aziendale in MyKinsta.
Statistiche a livello di sito in MyKinsta.
Statistiche a livello di sito in MyKinsta.

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:

1. 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 totale di visite ricevute dal sito WordPress. Se si evidenzia un punto specifico del grafico, verrà mostrato il numero di visite di 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 al sito. 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.

Visite in MyKinsta Analytics.
Visite in MyKinsta Analytics.

I piani di hosting di Kinsta si basano sul numero totale di visitatori del sito. Leggi di più sul modo in cui Kinsta conta le visite. Nota: il totale delle visite nella sezione Risorse di Analytics può differire dal totale che si vede nella pagina iniziale della Dashboard di MyKinsta. Questo perché la pagina della Dashboard di MyKinsta mostra sempre le visite del ciclo di fatturazione in corso.

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.

Utilizzo dello spazio su disco in MyKinsta.
Utilizzo dello spazio su disco in MyKinsta.

Ampiezza 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.

Utilizzo della larghezza di banda.
Utilizzo della larghezza di banda.

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 Byte.
Principali Richieste per Byte.

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.

Principali Richieste per Visualizzazioni.
Principali Richieste per Visualizzazioni.

2. 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.

Utilizzo CDN in MyKinsta Analytics.
Utilizzo CDN in MyKinsta Analytics.

Ampiezza 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.

Utilizzo della larghezza di banda del CDN.
Utilizzo della larghezza di banda del CDN.

Principali File per Richieste

File Principali per Richieste del CDN.
File Principali per Richieste del CDN.

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 File per Byte del CDN.
Principali File per Byte 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.

Principali File per Byte del CDN.
Principali File per Byte del CDN.

3. Dispersione

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

Palmare vs. Desktop

Il report palmare vs desktop mostra quali sono i dispositivi che accedono al sito. Nell’esempio qui sotto, si può vedere che il traffico è principalmente da desktop (oltre l’86%).

Grafico di dispersione tra palmari e desktop.
Grafico di dispersione tra palmari e desktop.

4. 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 Medio 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.

Tempo medio di risposta PHP + MySQL.
Tempo medio di risposta PHP + MySQL.

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).

Il throughput di PHP.
Il throughput di PHP.

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.

Grafico del limite di PHP worker.
Grafico del limite di PHP worker.

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.

Tempo di caricamento di admin-ajax.php in un grafico a cascata.
Tempo di caricamento di admin-ajax.php in un grafico a cascata.

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.

Grafico dell'utilizzo di AJAX in MyKinsta Analytics.
Grafico dell’utilizzo di AJAX in MyKinsta Analytics.

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.

Principali tempi medi di risposta PHP + MySQL.
Principali tempi medi di risposta PHP + MySQL.

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.

Tempo massimo di upstream.
Tempo massimo di upstream.

5. 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.

Grafico di ripartizione dei codici di risposta.
Grafico di ripartizione dei codici di risposta.

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.

Statistiche di risposta.
Statistiche di risposta.

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.
Grafico Suddivisione Errori 500.
Grafico Suddivisione Errori 500.

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.
Grafico Suddivisione Errori 400.
Grafico Suddivisione Errori 400.

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.
Grafico Suddivisione redirect.
Grafico Suddivisione redirect.

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.

Principali Errori 404.
Principali Errori 404.

Se si vede 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.

Errori 404 in Google Search Console.
Errori 404 in Google Search Console.

6. 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.

Hit X-Kinsta-Cache nelle intestazioni della risposta HTTP.
Hit X-Kinsta-Cache nelle intestazioni della risposta HTTP.

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 dello stack dei componenti della cache.
Grafico dello stack dei componenti della cache.

Grafico componenti cache

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

Grafico componenti cache.
Grafico componenti 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.

Principali bypass della cache.
Principali bypass della cache.

7. 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.

Principali Paesi

L’elenco dei Principali Paesi 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 35 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.

Elenco dei Principali Paesi.
Elenco dei Principali Paesi.

Principali Città

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

Elenco delle Principali Città.
Elenco delle Principali Città.

Principali IP client

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

Principali IP client.
Principali IP client.

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.

Un indirizzo IP proxy nei risultati di ricerca di Google.
Un indirizzo IP proxy nei risultati di ricerca di Google.

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.