No results found
di Riccardo Gallazzi
Wordpress è un sistema di gestione dei contenuti (CMS) estremamente utilizzato, perché ad oggi si stima che il 30% dei i siti web sono gestiti con tale piattaforma, in tanti campi. Questo dimostra che è una piattaforma con numerosi vantaggi e anche dal punto di vista delle prestazioni, se ci si sa muovere correttamente, si possono ottenere dei buonissimi risultati; viceversa, facendo le cose in maniera sbagliata può diventare una piattaforma che deprime enormemente il vostro sito.
Oggi avere un sito veloce è importante per almeno due motivi:
Attenzione però a non ritenere solo la velocità del sito il punto fondamentale per migliorare la User Experience, perché un transito veloce non implica necessariamente una buona User Experience, che invece ha come componenti altre cose. Per comprenderlo basti pensare che una decina d'anni fa fu pubblicato un sondaggio negli Stati Uniti in cui veniva chiesto quale sito fosse più veloce tra Amazon e Craigslist: le persone interpellate propendevano per una velocità percepita maggiore sul sito di Amazon a discapito di craiglist, ma ciò perché si trattava di un sito abbastanza scarno come interfaccia grafica e come funzioni rispetto a Craiglist; in realtà era molto più veloce di Amazon.
Questo ci dice ci dice che l'utente valuta in particolare la User Experience, tralasciando la velocità effettiva.
Per prima cosa bisogna analizzare le prestazioni e dopo si può passare alla fase di ottimizzazione.
Allo scopo occorre capire bene cosa succede tra server e browser; ebbene, ad ogni richiesta del client corrisponde una risposta del server web. Il server, nel caso di Wordpress, deve eseguire gli script PHP di codice PHP che eseguono delle query su database e viene creata la pagina da servire /inviare al client). La pagina viene quindi servita e consegnata al client.
Per prima cosa vengono letti e degli Header, che sono delle intestazioni caratteristiche del protocollo http, le quali determinano alcuni elementi ci interessano relativamente; ci interessa maggiormente quello che accade dopo.
Quindi con il documento HTML si comincia a leggere il documento e dopo la lettura degli header avviene la costruzione di DOM (Document Module, HTML) e CSSOM (CSS, ossia CSS Object Model), prima che avvenga il rendering della pagina.DOM e CSSOM sono due modelli ad oggetti necessari per il rendering grafico della pagina; nella fattispecie, i byte del file HTML vengono convertiti i caratteri con determinate caratteristiche e da questi vengono creati i nodi che contengono tutti i vari elementi della pagina web questo, secondo questo:
Byte => caratteri => token => nodi => modello a oggetti
Completata la struttura di rendering, viene definito il layout degli oggetti e si può stampare a schermo da pagina.
Questo è quello che viene Critical Rendering Path (CRP); bisogna notare che ci sono alcune risorse che vengono scoperte e quindi lette dal browser man-mano che legge i file HTML; tali risorse vengono definite render-blocking, perché fermano il rendering della pagina. Queste sono risorse HTML CSS e JavaScript, quindi quando il browser incontra tali risorse, la costruzione del DOM e del CSSOM vengono fermate, per poi riprendere quando è stata completata l'elaborazione delle risorse CSS e JavaScript presenti.
In realtà, con alcune tecniche si può ottenere una sorta di posticipazione della lettura ed esecuzione di queste risorse render-blocking, però di fatto non se ne può abusare, quindi bisogna valutare attentamente le risorse CSS e JavaScript, con lo scopo di ridurre il numero di risorse critiche, numero di byte critici e lunghezza del CRPHTML, CSS e JS (se non async) che sono risorse critiche render-blocking.
Questo impone degli sforzi in fase di progettazione sia del sito che della pagina, notevoli in WordPress; il compito è più semplice se si ha pieno controllo del sito, ma significa anche, da un punto di vista operativo, fare alcune scelte che consentono di contenere il CRP a valori accettabili.
Quando analizziamo un sito che abbiamo in gestione dobbiamo considerare alcune metriche; in particolare conviene basarsi principalmente su metriche user-centric, ossia centrate sull'utente, quindi sull' esperienza d'uso (User Experience).
Ci sono anche metriche machine-centric, ossia concentrate su server e browser, che sono certamente valide, ma che hanno un peso minore rispetto alle metriche incentrate su utente; in particolare possiamo definire delle metriche definite:
L’ultima corrisponde all'assenza di compiti implicanti script che richiedono diverso tempo per essere eseguiti; bisogna poi eseguire anche dei test basati sul’esperienza d'uso su dispositivi sia mobile che desktop.
Stabilite le metriche, vediamo quali strumenti si possono utilizzare per la misura dei parametri: ci sono vari strumenti per misurare le prestazioni ed in particolare alcuni basati su servizi online, come ad esempio:
Esiste anche lo strumento per sviluppatori di Chrome o Firefox (si apre premendo F12 dal browser) accessibile da pannello Network o Timeline; qui viene visualizzata una linea del tempo con tutte le informazioni relative alle risorse caricate, indicando quando vengono caricate e a che punto è il relativo al caricamento nella pagina, quanto tempo ci mettono a caricare e così via. Tutte informazioni utili a fare importanti valutazioni.
Gli strumenti creati da Google sono molto interessanti: PageSpeed Insights, che è disponibile anche su RocketWeb, e Lighthouse, disponibile principalmente con il browser Chrome.
Vale la pena di evidenziare che la velocità è espressa dal numero “Speed of” che sostanzialmente più è elevato, più il sito è veloce; ebbene, è importante non focalizzarsi eccessivamente su quel numero, perché valuta relativamente la User Experience e soprattutto è un numero che ha un significato abbastanza relativo.
Invece una cosa molto utile in PageSpeed Insights è invece l’elenco di ottimizzazioni da implementare nel sito: per ogni testo che segue Speed, dice quali ottimizzazioni sono state rilevate e quale ottimizzazioni vengono proposte. Inoltre viene fornito anche un link alla documentazione del blog tecnico di Google Developers.
Ora vediamo concretamente come migliorare le prestazioni, intervenendo sia lato server che lato Wordpress. Serve quindi un lavoro congiunto su entrambi gli aspetti.
Per alzare le prestazioni, sul Web Server bisogna adottare alcuni accorgimenti, che sono:
Per quanto riguarda l’utilizzare php 7, rispetto a php5 è più veloce e sicuro; l'unico motivo per cui si può non utilizzare php7 è se un programma ha problemi di compatibilità con l'applicazione, ma a quel punto se l'applicazione supporta solo php5 evidentemente vanno fatti degli aggiornamenti.
Inoltre con php7 vengono gestiti meglio i certificati SSL, soprattutto sotto l’aspetto del tempo di caricamento, quindi si possono utilizzare i certificati senza pregiudicare le prestazioni.
Quanto alla compressione, l'impostazione è specifica per il Web Server che si sta utilizzando: in genere se si usa Apache oppure ngnix si può pensare di abilitare una cache lato server e anche lato browser.
I tool per abilitare la cache lato server implementano una cache che permette di memorizzare i file richiesti più frequentemente, in modo che vengono serviti più velocemente.
Ricordiamo che con WordPress ogni pagina viene generata al momento della richiesta, quindi quando nella schermata del browser premiamo invio, viene inviata una richiesta al Server per una pagina specifica; allora il server raccoglie tutti gli elementi necessari dal database e dai file immagine, quindi lo script PHP dedicato di Wordpress assembla l'immagine che viene consegnata lato browser.
Succede una cosa analoga se visitiamo frequentemente un sito, allorché possiamo tenere in memoria alcuni elementi come ad esempio i file JavaScript e CSS, che in teoria non cambiano, cosicché quando accediamo a quella pagina abbiamo già il locale le risorse e quindi sono già disponibili per l'elaborazione da parte del browser.
Con l’utilizzo dei certificati SSL viene abilitato https, http 2; senza, non si può utilizzare.
Http 2 è uno standard recente che estende il vecchio http 1.1, che è il protocollo utilizzato e che verrà utilizzato possibilmente ancora per degli anni per gestire la comunicazione tra server e client. La versione 2 è compatibile con la 1.1 e non ci sono problemi di compatibilità; assicura una migliore gestione della sicurezza e delle prestazioni, che vengono migliorate ad esempio grazie alla compressione degli Header e all’introduzione di frame pesati. I frame sono sostanzialmente delle unità relative alla comunicazione tra client e server; in questo modo si dà una priorità ad alcuni frame rispetto ad altri, che così arrivano prima.
Questa è la grande novità di http2: con la versione 1.1 la comunicazione è sostanzialmente sequenziale e bisogna aspettare che uno finisca di “parlare” per poter parlare a sua volta, mentre con http 2 si hanno due linee di comunicazione. In questo modo, automaticamente il server e il browser decidono quali file sono prioritari e devono arrivare prima, quindi si può costruire più rapidamente la pagina web su rendering e poi si può abilitare anche quello che viene chiamato server Push. Il server Push è una tecnica di http 2 che consiste nell'invio di alcune risorse senza una richiesta esplicita del client, per cui quando il browser riceve una pagina, oltre ad essa riceve delle risorse associate che con http 1.1 avrebbe ricevuto in seguito, facendo un’ulteriore richiesta al server e vedendo così allungarsi il la durata della comunicazione.
Insomma http 2 migliora notevolmente la sicurezza e le prestazioni, per cui vale la pena adottarlo; l'adozione necessita di un certificato SSL e poi occorre una certa configurazione del file di configurazione del web server Apache or nginx.
Passando alla gestione ottimale del database: qui bisogna controllare la dimensione delle tabelle perché a volte ci sono tabelle che hanno delle dimensioni esagerate e in quel caso le performance vengono penalizzate; quindi se si trova una tabella di dimensione ottimale sospetta, bisogna analizzare la cosa.
Altra operazione consigliata è minimizzare (minification) codice JavaScript e CSS e prendere in considerazione l’adozione di un CDN, se necessario.
Conviene anche limitare il numero di versioni (revisioni) dei post nei blog e forum, cosa che si può fare tramite il file wp-config.php; e poi è buona regola svuotare regolarmente il cestino e la coda dei commenti spam.
Queste tre pratiche consentono di ridurre le dimensioni del database e di snellirlo.
È anche opportuno eseguire “Check & Repair” periodici tramite phpMyAdmin o Plesk: il check-in, sostanzialmente controlla tutto il database alla ricerca di tabelle incomplete, corrotte o senza riferimenti, che hanno qualche problema, quindi il server cerca di ripararle.
Ultimo accorgimento consigliato è monitorare il tempo medio di una query (Query Monitor, ecc.)
tramite strumento dedicato, in modo da capire se nel tempo sorgono dei problemi nelle query a database, che vengono eseguite ogni qualvolta che viene richiesta una pagina.
Passiamo adesso all’ottimizzazione attraverso la gestione dei plug-in: la prima cosa da considerare è che alcuni temi sono semplici e ben progettati, quindi si possono utilizzare tranquillamente da un punto di vista delle prestazioni.
Altri invece hanno una miriade di funzioni che non vengono utilizzate ma che caricano ugualmente risorse JavaScript; ebbene, quando si usa un tema del genere perché sono questi i temi che deprimono particolarmente le prestazioni. Conviene inoltre disabilitare l’opzione di ridimensionamento automatico di alcuni temi (alcuni temi hanno un'opzione per cui un immagine caricata viene ridimensionata a varie risoluzioni).
Quanto ai plug-in, ricordarsi che ogni plugin aggiunto aumenta il carico di lavoro del server, quindi conviene limitarsi a quelli strettamente necessari e disinstallare quelli che non vengono utilizzati, anche perché ogni plug-in aggiunto aumenta l’esposizione agli attacchi degli hacker.
Attenzione anche ai plugin e temi che eseguono query complesse sul databese.
Altro accorgimento è quello di ridurre il numero di richieste HTTP per risorse esterne, che permette di accorciare il CRP e consente anche di avere una pagina che ha una dimensione minore.
A proposito delle immagini, esse vanno ottimizzate, intendendo con ciò che bisogna innanzitutto scegliere un formato compresso JPEG web per le immagini raster ed SVG per le icone vettoriali; la differenza fra immagine raster e vettoriale sta sostanzialmente in come viene costruita: le immagini vettoriali sono costituite da un certo numero di poligoni e linee associati a colori, mentre le immagini JPEG sono delle immagini in cui il file viene diviso in una griglia, a ciascun quadratino della quale viene assegnato un colore.
Se provate ad ingrandire un'immagine JPEG o un altro tipo di immagine raster, man-mano che ingrandite vedete che l'immagine sgrana; invece l’immagine vettoriale non sgrana, per cui scegliete anzitutto il formato corretto, ricordando che TIFF, PNG e BMP sono da evitare perché non sono formati compressi.
In particolare per il JPEG potete scegliere un’impostazione di qualità minore di 85, chroma sampling 4:2:0, formato progressivo, no metadati; infatti l'occhio umano non percepisce un apprezzabile degrado dell'immagine.
Inoltre assicuratevi di aver caricato l'immagine con le dimensioni giuste; potete eseguire questo tipo di azioni con un plugin specifico come WP-smash o EWWW, ovvero con uno dei tanti altri disponibili.
Oppure potreste utilizzare uno strumento dedicato su computer prima del caricamento; il vantaggio, in questo caso, è che non aggiungete un carico di lavoro al web server. Se invece utilizzate un plug-in specifico avete una procedura automatizzata, che però impone un certo carico di lavoro sul server per cui.
Potete anche scegliere di ritardare il caricamento delle immagini fintanto che non sono visibili; questo avviene tramite un particolare attributo del tag relativo all'immagine in codice HTML. Per ottenere ciò sono disponibili plug-in come BJ Lazy Load, ecc.
A questo punto vediamo come Plesk (una soluzione utilizzata su RocketWeb) può aiutare ad avere un sito in Wordpress più veloce.
Nella figura seguente proponiamo una semplice e comune installazione di Wordpress vista dalla plancia di controllo di plesk, da cui possiamo gestire il nostro sito.
Ad esempio da Database possiamo verificare che nel periodo in cui si sta eseguendo non ci siano errori; al verificarsi di errori viene prodotto un avviso che invita a tentare di correggere gli stessi e lo strumento li avrebbe corretti automaticamente.
L’immagine seguente ci mostra come accedere a PHP My admin e da qui valutare le dimensioni delle tabelle, cosa utile se ci si trovasse una tabella che misura centina di megabyte o addirittura gigabyte.
Possiamo gestire le impostazioni per capire anche la versione di PHP utilizzata e gestire le impostazioni relative al web server Apache o nginx, aggiungere delle intestazioni aggiuntive, servire file statici e le immagini, i file JavaScript e CSS tramite nginx.
Utilizzare questo Smart Processing consente a nginx di processare le risorse statiche al posto di Apache; questo perché ngnix è più veloce a fare questo lavoro (immagine seguente).
Quanto ai certificati SSL, in questo caso è davvero facile gestirli: ad esempio per la creazione basta specificare un indirizzo e-mail, indicare se selezionare anche i sottodomini www. Facendo clic sul pulsante Install viene installato il certificato SSL Let's encrypt gratuito (vedere l’immagine seguente).
Si può anche scegliere di utilizzare un certificato SSL proveniente da un altro servizio a pagamento: questo va selezionato nella sezione Security Advisor.
Infine, per quanto riguarda la gestione di Wordpress abbiamo uno strumento integrato (Toolkit Wordpress) che ci consente di gestire direttamente dall’interno di Plesk la nostra installazione Wordpress.
Facendo clic su Wordpress nel menu di Plesk, in particolare, accediamo a una schermata dalla quale possiamo controllare i plug-in in uso, i temi e verificare anche se ci sono aggiornamenti, ad esempio, di tutti i plug-in installati.
