I contributori principali di WordPress sponsorizzati da Yoast e Google sono proponendo il progetto aggiungere un team di prestazioni per migliorare le prestazioni di base misurate da Vitali Web di Google metrica.

“Gli utenti si aspettano e preferiscono esperienze veloci (consapevolmente o meno)”, ha affermato Ari Stathopoulos, collaboratore principale a tempo pieno sponsorizzato da Yoast. “La ricerca mostra che i siti Web veloci possono fornire una migliore esperienza utente, aumentare il coinvolgimento, avvantaggiare la SEO, aumentare la conversione ed essere più rispettosi dell’ambiente e dal punto di vista economico”.

Non c’è dubbio che gli utenti si aspettano e possono beneficiare di prestazioni migliorate, ma ci sono una serie di variabili in gioco in un dato sito WordPress. Guardando esclusivamente alle prestazioni principali, Stathopoulos ha affermato che WordPress non regge la concorrenza.

“Rispetto ad altre piattaforme (ad es. Wix, Shopify, Squarespace), WordPress è in ritardo”, Egli ha detto. “Le altre piattaforme sono in media più veloci – e stanno diventando sempre più veloci – rispetto ai siti Web WordPress (vedi Il rapporto sui punti vitali Web principali dell’archivio HTTP), e stanno investendo attivamente in (e nel marketing) le prestazioni principali come funzionalità [1, 2].”

L’archivio HTTP, che fornisce un set di dati comune per coloro che conducono ricerche sulle prestazioni web, ha rilevato che solo il 21,5% dei siti valutati ha buoni punteggi Core Web Vitals a partire da settembre 2021. Sebbene tale percentuale sia aumentata nel tempo, i concorrenti che stanno già superando Anche i siti WordPress stanno rapidamente migliorando i loro punteggi. Stathopoulos lo ha descritto come un “divario crescente” tra WordPress e altre piattaforme.

Una delle sfide principali è che i proprietari di siti WordPress hanno molta libertà di utilizzare qualsiasi tema e plug-in desideri sui loro siti, il che rende le prestazioni più difficili da affrontare rispetto alle piattaforme ospitate citate per il confronto. La proposta afferma che “il raggiungimento di livelli di prestazioni ragionevoli non dovrebbe essere un territorio dei plugin, ma parte del core” e che gli utenti finali non dovrebbero diventare esperti di prestazioni.

“Il raggiungimento di livelli elevati di prestazioni richiede che le considerazioni tecniche siano ‘incorporate’ nell’intero stack; e poiché questo spesso non è il caso di temi/plug-in, le soluzioni per le prestazioni sono limitate a soluzioni per le prestazioni di “forzatura bruta” rispetto a comportamenti non performanti (ad es. buffering dell’output)” Stathopoulos ha detto.

La proposta ha ottenuto una forte risposta da contributori, consulenti SEO e rappresentanti di società di hosting, offrendo aiuto e suggerimenti.

Lo sviluppatore principale di WordPress Mark Jaquith, che ha un particolare interesse per questo argomento, ha affermato che i maggiori problemi che vede oggi sono legati alle prestazioni del frontend e alla pipeline delle risorse:

WordPress non ha supporto (diretto) per posticipare il caricamento dello stile. Non ha un sistema per gli stili dei temi critici. Per JavaScript, non ha supporto per defer, async, type="module", o nomodule. L’impostazione predefinita è caricare tutti gli script nell’intestazione. Lo stesso WordPress inserisce il suo codice extra per le emoji e la libreria di blocchi nell’intestazione. WordPress inietta codice JS e stili che evitano del tutto la pipeline delle risorse e si collegano direttamente a wp_head e wp_footer. I plugin emettono direttamente tag di script su misura che sono difficili da modificare. Nel momento in cui hai aggiunto 10 plugin al tuo sito, le tue probabilità di avere jQuery caricato (nell’intestazione) su ogni singolo caricamento di pagina sono estremamente alte. Nessuno è incentivato a essere un buon cittadino (incluso lo stesso WordPress) perché c’è sempre qualcun altro che inquina peggio di te. “Se jQuery è già accodato da qualcos’altro, immagino che sia meglio usarlo.”

Il riassunto di Jaquith descrive un problema più ampio dell’ecosistema e si conclude con un avvertimento che fa riflettere.

“È un problema enorme e risolverlo richiederà molto sforzo, forza di volontà e tempo”, ha detto. “Vale la pena farlo. Se le prestazioni del frontend di WordPress continuano a diminuire, il progetto cesserà di essere un’opzione praticabile per qualsiasi sito che si preoccupi della sua SERPS.

Un consulente per le prestazioni di WordPress, Eroan Boyer, ha suggerito di aggiungere uno strumento dedicato nella schermata Site Health che mostrerebbe quanto JS e CSS sono caricati su ciascun tipo di pagina (prima pagina, post, pagina, CPT) e da dove hanno avuto origine.

“Attribuire la provenienza di un determinato script o foglio di stile è qualcosa su cui ho lavorato molto nel contesto del plug-in AMP”, l’ingegnere di Google Weston Ruter. “Non so se l’implementazione nel plug-in AMP sarebbe adatta per il core, ma sono interessato a questo spazio.

“Se siamo in grado di correlare la provenienza di un dato markup all’impatto (negativo) sulle prestazioni della pagina, allora possiamo iniziare a evidenziare temi e plug-in offensivi per iniziare a fornire una certa responsabilità per ciò che viene aggiunto al frontend”.

L’ingegnere di Gutenberg Riad Benguella ha pubblicato alcune ricerche ad agosto su l’impatto delle prestazioni dei plugin sull’editor. I principali trasgressori tra i plugin popolari includevano WooCommerce, Yoast SEO e Jetpack. Questo è un altro aspetto delle prestazioni che colpisce gli utenti di WordPress più dei visitatori del sito. Sviluppatore web Takis Bouyouris suggerito la creazione di un framework di prestazioni che gli sviluppatori di plugin potrebbero seguire per evitare di realizzare prodotti che influiscano negativamente sulle prestazioni di base, sia sul frontend che nell’amministratore.

Finora la proposta non ha ricevuto grandi obiezioni e i contributori sembrano desiderosi di aiutare in ogni modo possibile. Stathopoulos ha affermato che i prossimi passi saranno creare un canale Slack, un programma di incontri e uno spazio su make.wordpress.org. Una volta che l’infrastruttura è a posto, i contributori possono iniziare a confrontare le prestazioni, definire i criteri di successo e identificare i progetti prioritari per i miglioramenti di Core Web Vitals.