Perdere i dati è un incubo, spesso e volentieri non si prendono le dovute precauzioni sia per negligenza e sia per incompetenza. Le motivazioni possono essere:
Guasti al disco rigido
Danni naturali
Attacchi ransomware
Per evitare queste problematiche, la strategia migliore è quella del 3 – 2 – 1 che consente di ottenere più versioni dei dati di backup e ci permette di essere tranquilli.
Cosa vuol dire 3-2-1?
Che devono essere disponibili almeno tre copie dei dati, una viene archiviata a livello locale e le altre due in posizioni differenti, ad esempio su un cloud.
Questa strategia è consigliata anche per gli utenti privati, permette di mettere in sicurezza tutti i dati e le informazioni critiche.
Ad agosto Google ha introdotto una novità riguardo i title delle pagine all’interno dei risultati di ricerca, al fine di renderli più leggibili e meglio ottimizzati per rispondere in maniera più adeguata alle query di ricerca degli utenti.
Perchè questi cambiamenti?
alcuni tag title non descrivono al meglio il contenuto di una pagina
alcuni tag title risultano troppo ripetitivi
alcuni tag title presentano una ridondanza di keyword
“Questo aggiornamento è progettato per produrre titoli più leggibili e accessibili per le pagine. In alcuni casi, potremmo aggiungere nomi di siti laddove ciò sia ritenuto utile. In altri casi, quando incontriamo un titolo estremamente lungo, potremmo selezionare la parte più rilevante invece di iniziare dall’inizio e troncare le parti più ostili”.
Come verranno generati i tag title secondo queste modifiche?
I tag <h1> o altri tipi di tag <h>
Nomi delle categorie e/o delle sottocategorie
Dati presenti all’inizio della pagina
Informazioni presenti nel body della pagina
Test alternativo presente nelle immagini
Come dobbiamo scriverli?
Non devo essere generici, fuorvianti e troppo lunghi.
Devono descrivere il contenuto della pagina
Non esagerare on il numero di keyword
Devono essere chiari e semplici
Inserire il nome del brand separandolo da un trattino
Dimensione minima di caricamento: 160 x 160 pixel. La foto visualizzata sarà di 160 x 160 pixel. La miniatura tra i post e in homepage sarà di 32 x 32 pixel.
Suggerisco di caricare un immagine in formato JPG di dimensioni maggiori o uguali a 180 X 180
Immagine di copertina
Dimesione minima: 828 x 315 pixel. Se inferiore verrà adatta e visualizzata sgranata. Suggerisco : carica un’immagine con larghezza di 828 pixel e altezza di 315 pixel, salvata in JPG RGB con dimensioni inferiori a 100Kb. Se l’immagine contiene testo o un logo è consigliabile utilizzare il formato PNG-24.
Foto condivisa
Dimensione di caricamento consigliata: 1200 x 1200 pixel. Verrà visualizzata nella sezione notizie (homepage) con una larghezza massima di 470 pixel (scalata sino ad un massimo di 1:1). Verrà visualizzata sulla pagina con una larghezza massima di 504 pixel (scalata sino ad un massimo di 1:1). Suggerisco di ridimensionare l’immagine se più piccola di 1200px, mantenendo la stessa proporzione.
Come molti di voi sapranno, i Core Web Vitals impongono ai siti web il rispetto di alcune specifiche che possono essere sintetizzate con: mobile first e siti veloci da navigare.
Perchè wordpress spesso è lento?
La risposta è molto semplice, molti costruiscono il sito da soli senza avere competenze specifiche, oppure si rivolgono a degli improvvisati che installano wordpress e scelgono un template grafico solamente perchè graficamente è accattivante e presenta livelli di difficoltà e di implementazione molto bassi.
Questo avviene perchè l’installazione di wordpress e la successiva installazione di un template grafico, è molto semplice, quasi alla portata di tutti. Stesso discorso per aumentare le funzionalità, esistono una miriade di plugin che permettono di creare e di aggiungere delle nuove funzionalità al sito web. Anche in questo caso, la scelta del componente aggiuntivo viene fatta seguendo delle logiche che non rispondono ad una corretta valutazione delle peculiarità del plugin, senza valutare e pesare bene quali sono i pro ed i contro di una determinata scelta.
Fatti non parole, di seguito un esempio concreto:
Un cliente si lamentava perchè il sito (wordpress) era troppo lento, utilizzando il tool di Google page speed, i risultati erano pessimi: appena l’8%. Considerate che il tool consiglia almeno un risultato attorno ai 90% (anche se ritengo che vada benissimo almeno un 75%).
Si trattava di capire il motivo di questa bassa prestazione, per cui il primo passo è stato quello di analizzare il server e di testare un clone del sito su dei server piu’ performanti:
Prima: Hosting condiviso
Dopo: Vps
La ripetizione del test sul clone, ha fatto aumentare le prestazioni di 16 punti, e credetemi, non sono pochi.
Sono stai analizzati tutti i componenti interni:
Erano presenti ben 35 plugin di cui utilizzati realmente 12.
Perchè tutti questi plugin? Semplice, chi ha realizzato il sito ha installato dei componenti esterni per fare delle prove, per proporre nuove funzionalità al cliente, per creare delle routine che potevano essere implementate tranquillamente modificando i file php e css di wordpress
Dopo aver tolto tutti i plugin inutili:
Da un valore di 8 nello speed test siamo passati a 65!
Ultima cosa da fare, analizzare il template.
Era stato installato AVADA, forse uno dei template più utilizzati per siti realizzati con woprdpress, molto accativamene e facile da gestire. Piccolo problema, il codice che genera questo template è “sporco”, molto pesante e con tempi di caricamento lenti.
Abbiamo quindi realizzato un template custom, modificando quello di default contenuto nel cms, ecco il risultato:
Un bel 95!
Ricapitolando, se il vostro sito wordpress è lento dovete:
analizzare le prestazione del server ed eventualente optare per una soluzione diversa
analizzare i plugin e chiedersi se sono realamente utili e se lo stesso risultato si possa ottenere in maniere diverse
Google ha annunciato nel suo blog ufficiale l’introduzione di una serie di metriche che valutano la user experience (UX) di un sito web e ritenute essenziali per una buona esperienza utente e un web più piacevole.
Questi fattori sono la base del progetto “Core Web Vitals 2020” e saranno integrate alla SEO attraverso un set di specifici indicatori di UX che diventeranno ufficialmente un fattore di ranking nel 2021.
Google è da tempo impegnato a rendere più semplice ed efficace l’usabilità dei siti web con l’obiettivo di facilitare l’esperienza di navigazione degli utenti e fornire risposte velocemente e in modo chiaro.
Come misurare le performance di un sito web
Ad oggi le performance di un sito possono essere misurate usando:
Questi strumenti si basano su dati raccolti dalla Chrome User Experience, un set di dati pubblici e metriche sull’esperienza utente provenienti dagli utenti che utilizzano Chrome in condizioni reali.
Tuttavia questi dati sono un campione perché comprendono solo quelli di utenti che hanno dato il consenso ad alcune condizioni come la sincronizzazione della cronologia e l’abilitazione dei report sulle statistiche di utilizzo.
Fortunatamente abbiamo a disposizione alcuni strumenti per tracciare questi dati che vedremo alla fine.
Cosa sono i Web Vitals I Web Vitals sono parametri standard per misurare la qualità dell’esperienza di navigazione di un utente su un sito web. Tra questi ce ne sono tre chiamati “Core” ritenuti fondamentali da Google e consistono in metriche e indicatori legati alla velocità, al tempo di risposta e alla stabilità del layout di un sito web.
Questi sono i tre fattori principali:
LCP: Largest Contentful Paint – Velocità di caricamento (loading) FID: First Input Delay – Interattività della pagina (interctivity) CLS: Cumlative Layout Shift – Stabilità visiva del caricamento (visual stability)
Largest Contentful Paint (LCP)
La metrica LCP indica il tempo di rendering dell’elemento più grande (Largest) visibile all’interno della schermo quando si carica il sito e misura la performance del caricamento.
Nel dettaglio può essere compreso tra:
elementi di tipo immagini elementi di tipo immagini dentro a elementi di tipo elementi di tipo video
Questa metrica presume che l’oggetto più grande visibile nella finestra sia il contenuto principale e penalizza contenuti invasivi come titoli molto grandi, immagini di apertura enormi, video, banner pubblicitari e pop-up. Nei due esempi che seguono, l’elemento più grande individuato sono le due immagini principali.
Per fornire una buona esperienza utente i siti dovrebbero caricare il contenuto “above the fold” entro i primi 2,5 secondi e sono considerati lenti già sopra i 4 secondi.
Da notare che non viene considerato il tempo di download ma la quantità di spazio che l’oggetto utilizza nella finestra dell’utente. Se gli elementi sono renderizzati sia sopra che sotto il limite della pagina, solo la parte visibile è considerata rilevante.
Lo stesso vale per gli elementi in scala. Un’icona di 800×800 pixel se ridotta a 50×50 pixel conta solo per 50 pixel. Se si ingrandiscono le immagini, è rilevante solo la dimensione dell’immagine originale.
Pertanto, come regola generale, è importante non inserire “above the fold” video o immagini superiori a 250 pixel di larghezza. Immagini di 300 pixel o banner pubblicitari di 336×280 o 300×250 comportano già penalizzazione importante.
Sono above the fold quei contenuti che riescono a riempire lo schermo del device dell’utente senza che questo debba fare alcun movimento di scroll ovvero senza che l’utente faccia niente né con il mouse né con il dito da mobile
First Input Delay (FID)
Il Cumulative Layout Shift misura lo spostamento degli elementi visibili e i cambiamenti di layout che arrivano all’improvviso e si verificano durante l’intera durata della visita della pagina causando uno shift dopo il caricamento dell’area del sito dovuto al ridimensionamento, con un effetto piuttosto fastidioso.
Il calcolo del CLS è piuttosto complicato e si esprime come il prodotto di due valori, la componente d’impatto e la componente di distanza utilizzando questa formula:
punteggio layout shift = componente impatto * componente distanza La componente d’impatto misura lo spazio normale occupato da un elemento nella finestra e quello che occupa dopo il suo spostamento. L’unione dell’area visibile dell’elemento prima e dopo lo spostamento decreta la percentuale della vista totale quindi la sua componente di impatto.
La componente di distanza è la distanza maggiore che un elemento instabile ha coperto nel riquadro durante lo spostamento (in orizzontale o in verticale) diviso per la dimensione più grande della finestra (larghezza o altezza, a seconda di quale sia maggiore) e si misura sempre in percentuale.
Il CLS è dunque il prodotto di queste due componenti e per una buona UX dovrebbe essere inferiore a 0,1.
L’immagine precedente mostra un blocco di testo – che occupa metà della parte visibile dello schermo – spostarsi in basso di un 25% dell’altezza della finestra. Il rettangolo rosso indica l’unione dell’area visibile dell’elemento prima e dopo lo spostamento, ossia 50% + 25% = 75% della finestra, quindi la componente d’impatto è 0,75.
E siccome l’elemento instabile si è spostato del 25% dell’altezza della finestra, il valore della componente di distanza è 0,25.
In base alla formula scritta in precedenza, il punteggio CLS è uguale a 0,75 * 0,25 = 0,1875 che risulta essere migliorabile.
La page experience
Gli sviluppatori di Google hanno elencato i criteri presi in esame per la valutazione di un sito e le metriche utilizzate dall’algoritmo per capire come un utente percepisce l’usabilità di una pagina web.
Alcuni fattori di posizionamento indispensabili che Google richiede sono:
ottimizzare per i dispositivi mobili minimizzare al massimo il caricamento delle pagine garantire la sicurezza con HTTPS strutturare adeguatamente gli annunci pubblicitari con gli interstitial (pagine pubblicitarie realizzate con JavaScript o Flash) Come migliorare i Core Web Vitals Google consiglia di correggere tutte le metriche etichettate come “Scarse” e alcune delle correzioni di pagina più comuni dovrebbero includere:
ridurre le dimensioni della pagina a meno di 500 KB. limitare il numero di risorse della pagina a 50. valutare l’introduzione di AMP Conclusioni Google ha creato una nuova libreria JavaScript dedicata ai Core Web Vitals e API che permettono di misurare ogni parametro e raccogliere dati degli utenti reali. In questo modo è possibile sfruttare le API per tracciare autonomamente il comportamento degli utenti sfruttando Google Tag Manager per trasferire le metriche su Google Analytics ed esportarle su Google Data Studio.
In definitiva possiamo dire che l’introduzione dei Core Web Vitals ci ricorda ancora una volta che l’obiettivo principale rimane quello di creare siti facili e veloci da navigare, soprattutto per gli utenti mobile. Sottovalutare questi aspetti non solo rischia di diminuire le conversioni del nostro sito ma il pericolo è rimanere confinato alle posizioni più basse della SERP.
