ne 6.8, gli utenti di WordPress che volevano aggiungere lo speculative loading ai loro siti web potevano utilizzare il plugin Speculative Loading del WordPress Performance Team. Questo plugin offre i vantaggi in termini di prestazioni della Speculation Rules API precaricando o prerenderizzando automaticamente gli URL del frontend di WordPress.
Con la versione 6.8, lo Speculative Loading entra nel core di WordPress con due nuove funzioni, un filtro e un’azione:
La nuova funzione wp_get_speculation_rules_configuration() restituisce la configurazione attuale delle regole speculative (mode – prefetch/prerender – e eagerness – conservative/moderate/eager). Per minimizzare il consumo di risorse ed evitare effetti indesiderati, i valori predefiniti sono prefetch e conservative. Secondo la nota di sviluppo, “è in linea con la configurazione utilizzata da Cloudflare nella sua funzione di caricamento speculativo e riduce al minimo la possibilità di carichi speculativi senza una successiva navigazione verso l’URL”.
Il codice che segue è un esempio di utilizzo della funzione wp_get_speculation_rules_configuration() che si può aggiungere in un plugin o nel file functions del tema attivo:
add_action( 'wp_footer', function() {
$config = wp_get_speculation_rules_configuration();
echo '<pre>';
print_r( $config );
echo '</WordPress 6.8 apporta significativi miglioramenti alle prestazioni e alla sicurezza. Grazie alla nuova Speculation Rules API, le pagine di WordPress possono essere caricate più velocemente prevedendo le azioni degli utenti. Allo stesso tempo, il passaggio all’algoritmo bcrypt per la protezione delle password rende il sistema più sicuro contro gli attacchi informatici.
1. Speculative loading in WordPress 6.8
Lo Speculative loading è una tecnica di ottimizzazione delle prestazioni dei siti web che consente di eseguire il prefetching o il prerendering delle pagine o delle risorse prima che l’utente vi acceda, riducendo i tempi di caricamento e migliorando l’esperienza utente.
Lo Speculative loading si basa sulla Speculation Rules API, un’API sperimentale che consente agli sviluppatori di specificare le regole per il prefetching o il prerendering degli URL in base alle interazioni previste dall’utente attraverso un’interfaccia definita in JSON.
La Speculation Rules API è attualmente supportata da un numero limitato di browser, principalmente quelli basati su Chromium 121+, come le versioni più recenti di Chrome, Edge e Opera.
Gli utenti dei browser che attualmente non supportano la Speculation Rules API (Firefox e Safari) non saranno penalizzati se un sito utilizza regole di caricamento speculativo. Semplicemente non beneficeranno dei miglioramenti delle prestazioni resi possibili dall’API.
Ci sono alcune importanti differenze tra il prefetching e il prerendering:
- Prefetching: le regole di
prefetchall’interno di un elemento<script type="speculationrules">o di un’intestazioneSpeculation-Rulesforzano il browser a scaricare il corpo della risposta delle pagine specificate, ma senza eseguire il rendering di tali pagine. Il prefetching non include il caricamento di sotto-risorse e l’esecuzione di JavaScript. I risultati sono conservati in una cache specifica, che viene svuotata quando l’utente si allontana dalla pagina. Se l’utente se ne va senza aver visitato le pagine precaricate, ci sarà un certo spreco di risorse, ma sarà comunque minore rispetto al prerendering. - Prerendering: le regole di
prerenderall’interno di un elemento<script type="speculationrules">o di un’intestazioneSpeculation-Rulesforzano il browser a recuperare, renderizzare e caricare il contenuto in una scheda invisibile, memorizzata in una cache in-memory per documento. Quando si utilizza il prerendering, tutte le sotto-risorse vengono caricate e tutto il codice JavaScript viene eseguito. I risultati sono conservati in una cache dedicata che viene svuotata quando l’utente lascia la pagina, ad eccezione della pagina verso cui l’utente naviga. Il prerendering offre notevoli vantaggi in termini di prestazioni, ma utilizza la memoria e la larghezza di banda della rete e può avere un costo elevato in termini di risorse.
Le regole possono essere inserite in un elemento inline <script type="speculationrules"> o in file esterni a cui fa riferimento l’header HTTP Speculation-Rules. Ecco un esempio di utilizzo in un tag script:
{
"prefetch": [
{
"source": "list",
"urls": ["firstpage.html", "secondpage.html"]
}
]
}Prima della versiopre>';
} );L’implementazione nel core di WordPress abilita il caricamento speculativo nel front-end di tutti i siti, tranne quando un utente è connesso o quando i permalink sono disabilitati.
Abbiamo testato il caricamento speculativo in WordPress 6.8 e abbiamo ottenuto il seguente risultato:
{
"prefetch": [
{
"source": "document",
"where": {
"and": [
{
"href_matches": "/*"
},
{
"not": {
"href_matches": [
"/wp-*.php",
"/wp-admin/*",
"/wp-content/uploads/*",
"/wp-content/*",
"/wp-content/plugins/*",
"/wp-content/themes/twentytwentyfive/*",
"/*\?(.+)"
]
}
},
{
"not": {
"selector_matches": "a[rel~="nofollow"]"
}
},
{
"not": {
"selector_matches": ".no-prefetch, .no-prefetch a"
}
}
]
},
"eagerness": "conservative"
}
]
}La funzione wp_get_speculation_rules() genera l’intero oggetto JSON delle regole di speculazione in base alla configurazione.
È possibile utilizzarla come nell’esempio seguente:
add_action( 'wp_footer', function() {
if ( function_exists( 'wp_get_speculation_rules' ) ) {
$rules = wp_get_speculation_rules();
if ( ! empty( $rules ) ) {
echo '<h4>Speculation rules:</h4>';
echo '<pre>';
echo esc_html( json_encode( $rules, JSON_PRETTY_PRINT ) );
echo '</pre>';
} else {
echo '<p>Speculation rules are empty or invalid.</p>';
}
} else {
echo '<p>wp_get_speculation_rules() not available.</p>';
}
});È possibile utilizzare il nuovo filtro wp_speculation_rules_configuration per modificare la configurazione predefinita, ad esempio cambiando l’eagerness in moderate o eager o forzando un comportamento specifico.
È possibile utilizzare il filtro wp_speculation_rules_configuration per eseguire il prerender solo degli articoli correlati aggiungendo un elenco di URL con source = list invece di document, come nell’esempio seguente:
add_filter('wp_speculation_rules_configuration', function( $config ) {
$config['mode'] = 'prerender';
$config['eagerness'] = 'eager';
$config['urls'] = [
'source' => 'list',
'urls' => [
home_url('/page-1/'),
home_url('/page-2/')
]
];
return $config;
}L’azione wp_load_speculation_rules permette di aggiungere regole personalizzate oltre alla regola principale di speculazione, mentre il filtro wp_speculation_rules_href_exclude_paths permette di escludere altri percorsi dal caricamento speculativo.
Secondo la nota di sviluppo, i siti web che adottano lo speculative loading hanno migliorano il Largest Contentful Paint (LCP) di circa l’1,9% a livello mediano. Si tratta di un risultato considerevole, considerando che si tratta del risultato di una singola implementazione.
Per un’analisi approfondita dello speculative loading, si legga il nostro tutorial approfondito. Per i dettagli sul caricamento speculativo in WordPress 6.8 con esempi di utilizzo, si legga il track ticket #62503 e la nota ufficiale di sviluppo. Si veda anche Caricamento speculativo in WordPress di Felix Arntz.
2. Bcrypt per l’hashing delle password in WordPress 6.8
La versione 6.8 cambierà l’algoritmo utilizzato da WordPress per proteggere le password degli utenti. Attualmente WordPress utilizza phpass, che non è considerato il migliore algoritmo in termini di sicurezza. WordPress 6.8 passa al più sicuro algoritmo di crittografia bcrypt.
La differenza principale è che bcrypt richiede più tempo e risorse per essere decifrato, rendendo meno efficaci gli attacchi informatici.
Inoltre, le password delle applicazioni, le chiavi di reimpostazione delle password utente, le chiavi di richiesta dei dati personali e la chiave della modalità di recupero passeranno da phpass all’algoritmo di hashing BLAKE2b, più sicuro e veloce.
Non è richiesta alcuna azione da parte dell’utente per implementare questa modifica:
Quando un utente accede per la prima volta dopo l’aggiornamento, o quando cambia la password, la sua password viene automaticamente rielaborata con bcrypt e salvata nel database. Le password delle applicazioni e le chiavi di sicurezza non verranno automaticamente rielaborate, ma un hash esistente rimarrà valido se è stato generato prima di WordPress 6.8 e utilizzato prima della sua scadenza.
Le password dei post continueranno a utilizzare phpass per il momento, ma questo potrebbe cambiare in futuro.
Per un’analisi più approfondita dell’adozione di bcrypt con WordPress 6.8 per gli sviluppatori, si veda la nota di John Blackbourn.