I principali aspetti vitali del web non sono proprio il tuo problema?

Non sei solo se stai lottando per migliorare i punteggi di Core Web Vitals e stai arrivando a breve. Prove aneddotiche suggeriscono che ottenere prestazioni elevate di Core Web Vitals è difficile. Il motivo è perché gli editori e il SEO stanno cercando di riparare qualcosa che tecnicamente non è rotto.

Cambio di paradigma nella modalità di sviluppo dei siti

Siamo nelle fasi iniziali di un importante cambiamento di paradigma nel modo in cui vengono create le pagine web. Un host web più veloce è utile ma non risolverà i problemi di Core Web Vitals.

I principali dati vitali web vengono calcolati a valle sul dispositivo mobile che sta bevendo le tue pagine web su un telefono cellulare a velocità 3G o 4G. È da qui che provengono i dati di Core Web Vitals e un server Web veloce è di scarsa utilità a quel punto se il download viene limitato da una scarsa connessione Internet al telefono.

Migliorare Core Web Vitals riguarda meno l’hosting web e più la correzione del codice.

Riparare ciò che non è rotto

WP Rocket ha recentemente ridisegnato il proprio sito Web utilizzando Gutenberg. È stata una mossa coraggiosa e quasi sconsiderata considerando che Gutenberg non aveva funzionalità complete di modifica del sito in quel momento.

Hanno dovuto personalizzare il modo in cui WordPress gestisce CSS e JavaScript per migliorare i punteggi dell’esperienza della pagina di Google.

In altre parole, nel riprogettare il proprio sito Web per ottenere un buon punteggio per Core Web Vitals, WP Rocket ha dovuto personalizzare WordPress stesso, per renderlo qualcosa per cui non era stato progettato.

Principali dati vitali del web: poco amichevole

Gli standard principali di Web Vitals non sono qualcosa che gli sviluppatori di WordPress hanno in mente quando creano WordPress. Ecco perché l’incorporamento dei tweet in un post attiverà lo spostamento cumulativo del layout.

WordPress e temi non codificano per Google. Codificano per le esigenze degli editori che fino a maggio 2020 non erano un’esigenza degli editori.

Non è solo WordPress, neanche. La maggior parte degli altri sistemi di gestione dei contenuti non dispone delle migliori pratiche di Core Web Vitals integrate.

Ciò non significa che ci sia qualcosa di sbagliato in WordPress. Non c’è niente di sbagliato in WordPress perché Google dice che c’è qualcosa che non va.

Core Web Vitals non è un problema di WordPress

I Core Web Vitals sono un insieme di metriche sviluppate in modo indipendente da Google e inviate all’editore e alla comunità SEO con cui collaborare.

WordPress non c’entrava niente. Core Web Vitals è apparso a maggio 2020, apparentemente senza alcun coordinamento o consultazione con l’ecosistema degli sviluppatori.

Sul lato WordPress, lo sviluppo sta andando avanti come se i Core Web Vitals non esistessero. Mentre dal lato publisher e SEO sono gli utenti di WordPress ad essere gravati dal compito di “riparare” WordPress, Drupal, phpBB ecc.

In un mondo perfetto, il compito di creare un sistema che soddisfi le esigenze degli utenti spetta agli sviluppatori. Ma non sta succedendo.

WordPress non vede nemmeno Core Web Vitals come un problema di WordPress.

Quando qualcuno ha avviato un thread di supporto nei forum di WordPress su di esso, gli è stato detto di chiedere nel forum di supporto di Google.

“Dovresti chiedere su un forum di Google, poiché WordPress non ha nulla a che fare con questo.”

Editore e comunità SEO gravati dalla conformità

Gli editori di WordPress sono bloccati nel tentativo di rendere i siti Web conformi a uno standard che tali siti Web non sono mai stati progettati per rispettare.

Questo è il motivo per cui così tanti stanno lottando con Core Web Vitals. Gli editori e i SEO sono gravati dal tentativo di riparare qualcosa che idealmente dovrebbe essere corretto a livello di codice.

Migliorare i punteggi di Core Web Vitals può sembrare di provare a migliorare le prestazioni di una Honda Civic agli standard di una Chevy Corvette.

Gli sviluppatori non hanno costruito una Corvette. Hanno costruito una Honda Civic.

Ma Google chiede che i conducenti (non i produttori) migliorano le prestazioni a un livello Corvette. Ti sembra giusto?

È ragionevole chiedere agli utenti di un software di migliorarlo piuttosto che agli sviluppatori del software?

Il problema della conformità del software con Core Web Vitals esiste a livello di codice, non a livello di utente.

Allora perché gli editori e la comunità SEO sono gravati dal dover aggiustare qualcosa di cui sono solo utenti?

Google è utile?

Google fornisce molti strumenti per diagnosticare i problemi e offre articoli approfonditi che spiegano come risolvere questi problemi di codifica.

Ma questi sono problemi di codifica, non problemi dell’utente.

Un esempio della disconnessione tra la comunità di sviluppo e Google è il problema del Cumulative Layout Shift, dove la pagina web si sposta e si riorganizza man mano che gli elementi della pagina vengono scaricati.

Un motivo comune per lo spostamento cumulativo del layout è che le immagini non hanno dimensioni di altezza e larghezza dichiarate. Google consiglia soluzioni alternative esotiche come l’utilizzo di CSS per modellare le immagini utilizzando le caselle delle proporzioni.

L’editore medio e il SEO probabilmente non capiranno quali sono le caselle delle proporzioni e come calcolare le proporzioni a livello di sito in un modo che non interrompa il sito web.

Dai un’occhiata a questo e alla descrizione delle caselle delle proporzioni che Google collega e vedi se ha senso per te:

“I quadrati perfetti e le cose in 16: 9 sono fantastici, ma i valori utilizzati per questi sono solo semplici calcoli matematici. Le proporzioni possono essere qualsiasi cosa e di solito sono completamente arbitrarie. Un video o un’immagine può essere ritagliata a qualsiasi dimensione.

Quindi come facciamo a capire il padding-top per il nostro SVG 1127,34 × 591,44 sopra?

Un modo è usare calc (), in questo modo:

padding-top: calc (591,44 / 1127,34 * 100%); “

Bontà gentile!

Ecco un altro esempio. Molti modelli web impostano abitualmente la larghezza delle immagini tramite CSS in modo che sia automatica (larghezza: auto;) per fare in modo che le immagini come un logo ridimensionino le dimensioni per adattarsi a un modello indipendentemente dal fatto che sia visualizzato su un dispositivo mobile o desktop. Questa è una pratica di codifica comune che causa lo spostamento cumulativo del layout.

Questi sono i motivi per cui WP Rocket ha dovuto scavare e apportare modifiche al sito CSS e JavaScript.

Ad esempio, WordPress Gutenberg carica tutto il CSS esistente, indipendentemente dal fatto che sia necessario o meno. Quindi lo sviluppatore di WP Rocket ha dovuto codificare una soluzione per questo.

Ecco come WP Rocket ha spiegato cosa hanno fatto come parte della loro riprogettazione:

“… abbiamo deprecato diversi blocchi che non sono stati utilizzati. Abbiamo creato un sistema di accodamento personalizzato per caricare i blocchi CSS e JS solo quando necessario. Ci sono voluti solo pochi minuti per sviluppare questo sistema.

Abbiamo anche deciso di non utilizzare il file CSS di Gutenberg. Invece, abbiamo “migrato” il CSS di cui avevamo effettivamente bisogno nel nostro foglio di stile, in un file CSS dedicato. Questo ha funzionato. “

Un ripensamento del modo in cui vengono creati i siti

È importante comprendere il problema di Core Web Vitals. Google chiede che gli editori e i SEO si imbattano in soluzioni che la comunità di sviluppo CMS non mostra interesse ad affrontare.

Ecco un esempio dei tipi di compromessi che dobbiamo affrontare e di come Google sta cambiando il modo in cui sviluppiamo i siti web.

Parliamo di caratteri.

Il blocco del rendering delle risorse di terze parti può avere un impatto negativo su Largest Contentful Paint. Un collo di bottiglia comune è il download di caratteri da un sito di terze parti come Google Fonts.

Ci sono una serie di trucchi da applicare che sono la combinazione dell’uso dell’attributo precaricamento del collegamento e forse alcuni JavaScript, ecc. Che rendono il processo di download di caratteri di terze parti Core Web Vitals amichevole.

Ma ucciderebbe il tuo sito lasciare quel carattere stravagante dietro?

Una soluzione semplice che aiuterà a ottenere un punteggio migliore è quella di cambiare il carattere del sito web in un carattere sans serif che i dispositivi Apple, Windows e Android hanno già caricato nel loro sistema.

Passare a un font accattivante integrato nel dispositivo significa che il sito non deve più aspettare per scaricare un font di fantasia.

Un approccio può essere qualcosa del genere:

font-family: Helvetica, Tahoma, sans-serif;

Se Android non ha Helvetica o Tahoma già caricati nel browser, il dispositivo visualizzerà il sito utilizzando il carattere Roboto.

Screenshot dell’esempio di carattere Roboto

Per le persone abituate a usare caratteri fantasiosi, l’uso di caratteri di sistema potrebbe sembrare estremo. Ma è un esempio dei tipi di compromessi che un editore web potrebbe dover fare, in particolare gli editori che si trovano in nicchie altamente competitive.

Questo tipo di decisione è un gioco da ragazzi per un sito affiliato incentrato sulla velocità della pagina e sulle conversioni.

Un momento di transizione

Quello che sta accadendo oggi è che stiamo vivendo un momento di transizione. Le cose stanno cambiando da come abbiamo fatto le cose in passato a come gli sviluppatori faranno le cose (fuori dagli schemi) in futuro.

Gli sviluppatori hanno risposto alla domanda di siti ottimizzati per dispositivi mobili. Col tempo potrebbero iniziare a rispondere alla domanda di siti con un buon punteggio per Core Web Vitals.

Il modo in cui sono progettati i sistemi CMS, i modelli e i plug-in non ha soddisfatto le esigenze degli editori che richiedono la considerazione di Core Web Vitals.

Per il momento, i SEO tecnologici e la comunità degli sviluppatori sono bloccati a dover “aggiustare” ciò che non è rotto per farlo aderire all’idea di Google di come dovrebbe essere il web.

Ovviamente, una pagina che si carica velocemente e non si sposta è una buona cosa. Ma richiedere agli utenti di un software di migliorare il software stesso è un peso.

A questo punto l’onere di correggere il codice ricade sul utenti del software di pubblicazione e non su sviluppatori di quel software. Ti sembra giusto?

Quello che può accadere è che alcuni potrebbero trovare utile sistemare il più possibile e lasciare il resto per quando WordPress e altri software CMS raggiungono.