mavimo

Come visto negli articoli precedenti riguardanti le chiamate cookieless e le ottimizzazioni del front end di Drupal ci sono diversi modi per migliorare il modo in cui è possibile effettuare l'ottimizzazione del frontend. Ora vedremo come integrare alcune delle cose viste nei due articoli precedenti e come migliorare ulteriormente le performance con Drupal.

Come abbiamo visto nell'articolo precedente è cosa buona e giusta che le richieste effettuate per la ricezione di file statici (immagini, css e js) avvengano attraverso chiamate a cui non sono impostati cookies, in modo da ridurre il traffico generato e le richieste effettuate. Questo è consigliato sia da Yahoo che da Google. Un modo molto semplice è usare un dominio differente o un sottodominio andando ad impostare i cookies in modo che questi non rispondano al dominio indicato.

Spesso, però, questo non è proprio così semplice da realizzare a causa dei sistemi di tracciamento utilizzati. Vedremo come risolvere questo problema per i più comuni.

L'altro giorno, mentre assieme a Tommaso stavamo controllando un problema di performance su alcuni script JS, per puro sbaglio mi è capitato di vedere usare jQuery con dei selettori usati in maniera che credevo essere impropria, a prima vista mi sembrava un errore, per questo motivo ho fatto alcuni test per vedere se lo era e i risultati sono stati inaspettati.

La volta scorsa, nel parlare di ottimizzazione del frontend di siti generici (e Drupal in particolare) avevamo
affrontato alcune delle problematiche principali, tra cui appunto la generazione di sottodomini per lo smistamento degli asset statici [1], così da parallelizzare il più possibile il caricamento della pagina.

Ora vedremo come ottimizzare e mettere in pratica i suggerimenti che YSlow (ma anche PageSpeed) ci danno.

NOTA: con il nome di assett intendendo con questo nome quelle informazioni che non variano o variano molto poco nel corso del tempo e che consideriamo opportuno far gestire su sottodomini differenti per ottimizzare le performance del frontend per gli utenti finali (ed eventualmente per suddividere la gestione di questo tipo di dati ai server).

A chi capita di relaizzare siti, dopo la fase iniziale di produzione e prima configurazione non può tralasciare al seconda fase, ma non meno importante, di messa a punto del sistema. Per fare questo uno strumento che non può mancare è FireBug con l'accoppiata di YSlow.

Dopo l'installazione di base lanciandolo sul nostro sito vediamo che se abbiamo usato un buon sistema di pubblicazione, allora otterremo un discreto punteggio già di partenza, una installazione di prova ha rilevato che è possiblile raggiungere come base un punteggio di circa 77 punti. Vediamo ora come portare il nostro punteggio (e quindi la velocità percepita dagli utenti) a livelli ben più alti.