La consapevolezza di un audit manuale della performance

Quando si è un product owner o un product developer, probabilmente si ha un’idea piuttosto precisa di quali siano i core asset necessari per il funzionamento di un sito web, ma raramente questa idea ci dà il quadro completo. Quanto bene conosciamo ogni singola cosa che viene caricata sui nostri siti?

L’articolo prosegue sotto

Un occasionale audit della performance web, se fatto a mano, ci rende effettivamente coscienti di ogni singola cosa. Cosa c’è di così straordinario in questa cosa? Beh, tanto per cominciare, il processo fa aumentare la nostra consapevolezza di quello che stiamo davvero chiedendo ai nostri utenti. Inoltre, un po’ di “magheggi” con un foglio di calcolo ci permetteranno di dare forma a quello che abbiamo scoperto in un modo che abbia più significato per gli stakeholder. Ci permette di tradurre la nostra performance web in termini di scopo, così:

Illustrazione di un grafico a torta che mostra i risultati di un performance audit.

Volete fare qualcosa del genere? Continuate a leggere.

Un attimo, ma non ci sono i computer per questo tipo di cose?#section1

Un audit manuale potrebbe sembrare un noioso lavoro senza senso. Perché farlo a mano? Non possiamo automatizzarlo in qualche modo?

Questo è il punto: vogliamo diventare coscienti, non automatizzare tutto. Quando ci prendiamo del tempo per considerare ogni singola cosa che viene caricata su una pagina, otteniamo un’immagine più realistica del nostro lavoro.

Ci vuole una mente umana per osservare ogni asset su una pagina e assegnargli uno scopo. A sua volta, questo ci permette di dare forma ai nostri dati in un modo che siano significativi per le persone che non conoscono il significato di acronimi come CSS o WOFF. Oltre a ciò, a chi non piace un grafico a torta?

Ecco il procedimento, passo a passo:

  1. Mettete i vostri dati sulla performance in un formato malleabile.
  2. Estraete le informazioni necessarie.
  3. Fate passare ogni oggetto, assegnando ad ogni richiesta di asset uno scopo.
  4. Calcolate il totale e modificate i dati in unità facilmente comprensibili.
  5. Create dei piacevoli grafici a torta.

La prima volta che lo si fa in questo modo, l’audit potrebbe richiedere da mezz’ora a un’ora, ma con la pratica riuscirete a farlo in pochi minuti. Partiamo!

Raccogliete i dati sulla performance#section2

Per cominciare, capite quale URL volete valutare. Osservate le vostre statistiche e cercate di determinare quale sia il tipo di pagina più popolare. Non usate di default la vostra home page. Per esempio, se avete un sito di notizie, è probabile che il tipo di pagina più popolare siano gli articoli. Se state analizzando una app single page, determinate quale sia la view a cui si accede più comunemente.

Dovete ottenere l’attività di rete per quell’URL in un formato CSV/spreadsheet. Nella mia esperienza, il modo più semplice per farlo è usare WebPagetest, il cui funzionamento è semplice: dategli un URL e vi farà una valutazione che cerca di misurare la performance percepita.

Andate su WebPagetest e inserite il vostro URL nel grande campo sulla homepage. Comunque, prima di far partire il test, aprite il pannello Advanced Settings. Assicuratevi di fare un solo test e impostate Repeat View su First View Only. In questo modo sarete sicuri di non ricevere richieste duplicate nei vostri dati. Adesso fate partire il test: premete il grande pulsante “Start Test”.

Screenshot di WebPagetest

Una volta che avrete la pagina con i risultati, cliccate il link nell’angolo in alto a destra che dice “Raw object data”.

Screenshot di WebPagetest che mostra i raw object data

Potrete scaricare un file CSV con le vostre network request elencate in uno spreadsheet che potete manipolare.

Navigate nei dati e sistemateli#section3

Ora, aprite il file CSV nel vostro editor di spreadsheet preferito: Excel, Numbers, o – personalmente il mio preferito – Google Sheets. Il resto di questo articolo sarà scritto tenendo a mente Google Sheets, sebbene risultati simili sono sicuramente possibili con altri programmi per fogli di calcolo.

Sulle prime probabilmente vi sembrerà che tale file contenga una quantità esagerata di informazioni, ma noi siamo interessati solo ad una piccola parte di questi dati. Ecco le tre colonne che ci interessano:

  • Host (colonna F)
  • URL (colonna G)
  • Object Size (colonna N)

Potete semplicemente ignorare le altre colonne, nasconderle o cancellarle. O ancora meglio: selezionate queste tre colonne, copiatele e incollatele in un nuovo spreadsheet.

Ispezionate ogni asset request#section4

Nel vostro spreadsheet ridotto, inserite una nuova prima colonna ed etichettatela “Purpose” (fine, scopo). Potete anche includere una colonna Descrizione/Commento, se volete.

Screenshot di un audit spreadsheet

Poi, esaminate ciascuna riga ed assegnate un purpose ad ogni asset request. Suggerisco qualcosa di questo tipo:

  • Contenuto (e.g., il documento HTML centrale, immagini, media: le cose che interessano agli utenti)
  • Funzione (e.g., file JavaScript funzionali che avete creato, CSS, webfonts)
  • Statistiche (e.g., Google Analytics, New Relic, etc.)
  • Ads (e.g., Google DFP, qualsiasi ad network, etc.)

I nomi del Purpose possono essere quelli che preferite, l’importante è che le etichette per ogni purpose siano consistenti, per quel che riguarda le maiuscole e per tutto il resto. Si devono poter raggruppare appropriatamente per generare grafici ricercati in seguito. (Pro tip: usate la data validation su questa colonna per garantire la consistenza nel vostro spreadsheet).

Ma come si determina il purpose? Tipicamente, l’indizio maggiore è la colonna “Host”. Comincerete, molto rapidamente, dal riconoscere quali host forniscono cosa. Il vostro URL root sarà da dove proviene il vostro documento, ma troverete anche:

  • URL dei CDN come cloudfront.net o cloudflare.com. A volte questi hanno immagini (che tipicamente sono contenuti), a volte ospitano i file CSS o JavaScript (la funzionalità).
  • URL delle statistiche come googletagservices.com, googletagmanager.com, google-analytics.com o js-agent.newrelic.com.
  • URL degli ads come doubleclick.net o googlesyndication.com.

===

Se doveste essere insicuri riguardo a un URL, provatelo voi stessi nel vostro browser o fate letteralmente la ricerca dell’URL in Google. (Suggerimento: se non riconoscete subito l’URL, molto probabilmente è collegato a un ad).

Consapevolezza#section5

Già fare gli step descritti prima probabilmente sarà una rivelazione: fermarsi a considerare ciascun asset su una pagine e perché si trova lì vi aiuterà a prendere coscienza di ogni singola cosa che viene caricata dalla pagina.

La prima volta che farete queste cose potreste avere delle sorprese: potrebbero saltar fuori alcuni item inattesi. Potrebbe essere che uno script venga caricato più di una volta. Quella social widget potrebbe avere un grosso peso per la pagina. Le richieste provenienti dagli ads potrebbero essere più numerose di quel che pensate. Questo è il motivo per cui ho suggerito una colonna Descrizione/Commento: potete segnarvi delle note come “WTF?” e “Posso eliminarlo?”.

Incrementare i vostri dati#section6

Prima di poter generare dei graziosi grafici a torta, dovrete lavorare ancora un po’ sullo spreadsheet. Uomo avvisato mezzo salvato: state per incontrare della nerditudine estrema riguardante i fogli di calcolo.

Per prima cosa, dovete tradurre le dimensioni delle richieste in kilobyte (KB) perché vengono inizialmente fornite in byte e nessun umano parla in termini di byte. Poi, nella colonna “Object Size” inserite un’altra colonna chiamata “Object Size (KB)”. Poi inserite una formula nella prima cella, simile a questa:

=E2/1000

Dettaglio dello spreadsheet dell'audit

Traduzione: state semplicemente dividendo la quantità nella cella della colonna precedente (E2, in questo caso) per 1000. Potete evidenziare questa nuova cella e poi trascinare l’angolo verso il basso per tutta la lunghezza della colonna per fare la stessa cosa con ogni riga.

GIF animata del processo di un spreadsheet

Sommate le richieste#section7

Ora, per capire quante HTTP request sono collegate ad ogni Purpose, dovete fare un tipo di conteggio speciale. Inserite altre due colonne, una etichettata “Etichette dello Purpose” e la seconda “Request dello Purpose”. Sotto Etichette dello Purpose, nella prima riga, inserite questa formula:

=SORT(UNIQUE(B2:B),1,TRUE)

Dettaglio dello spreadsheet

Questo supponendo che la colonna con la valutazione dello scopo sia la B. Se non lo è, sostituite la “B“ in questo esempio con il nome della vostra colonna. Questa formula scorrerà lungo la colonna B e darà in output un risultato se è unico. Dovete solo inserirla nella prima cella della colonna. Questo è uno dei motivi per cui è importante avere consistenza nella colonna Purpose.

Ora, sotto la seconda colonna che avete creato (Request dello Purpose) nella prima cella, inserite questa formula:

=ARRAYFORMULA(COUNTIF(B2:B,G2:G))

Dettaglio dello spreadsheet

Anche questa formula scorrerà lungo la colonna B e farà un conto se si abbina a qualcosa nella colonna G (supponendo che la colonna G sia la colonna Etichette dello Purpose). Questo è il modo più semplice per fare il totale di quante richieste HTTP ricadono in ciascun purpose.

Sommare la dimensione di download per scopo#section8

Infine, potete ora sommare anche i dati (in KB) per ogni scopo. Inserite un’altra colonna e chiamatela Purpose Download Size. Nella prima cella, inserite la formula seguente:

=SUM(FILTER($F$2:F,$B$2:B=G2))

Questa sommerà la dimensione dei dati nella colonna F se il suo scopo nella colonna B si abbina (match) G2 (ossia, il vostro primo Purpose Label dalla sezione sopra). Al contrario delle ultime due formule, dovrete copiare questa formula e modificarla per ogni riga, facendo abbinare (match) l’ultima parte (“G2”) alla riga in cui si trova. In questo caso, la seguende finirà in “G3”.

GIF animata che mostra uno spreadsheet process

Preparate i grafici fancy#section9

Con i vostri asset raggruppati per scopo, con i dati tradotti in KB, con il numero di richieste contate e avendo sommato le dimensioni di download, sarà piuttosto semplice generare alcuni grafici.

Il grafico delle HTTP request#section10

Per realizzare un grafico delle HTTP request, selezionate le colonne Purpose Label e Purpose Reqs (colonne G e H nel mio esempio), e poi andate su Insert > Chart. Scorrete nell’elenco di grafici possibili e scegliete quello a torta. Assicuratevi di spuntare il box contrassegnato da “Use column G as labels.”

Screenshot che mostra il Chart Editor di Google Sheets

Sotto il tab “Customization”, modificate il Title in “HTTP Requests”; sotto “Slice” assicuratevi che “Value” sia selezionato (il default è “Percentage”). Facciamo questo perché il numero delle richieste è quello che vogliamo comunicare in questo caso.

Screenshot che mostra il Chart Editor di Google Sheets

Andate avanti, modificate i colori a vostro piacimento. E già che ci siete, lasciate perdere Arial.

Grafico della dimensione dei download#section11

Il grafico a torta del Purpose “dimensione del download” è molto simile. Selezionate le colonne Purpose Label e Purpose Download Size (colonne G & I nel mio esempio), poi andate su Insert > Chart. Scorrete la lista di possibili grafici e scegliete un grafico a torta. Assicuratevi di spuntare il box contrassegnato da “Use column G as labels”.

Nel tab “Customization”, modificate il Title in “Download Size”. Sotto “Slice” assicuratevi anche di aver selezionato “Value”. Lo facciamo per poter indicare la somma in KB per ogni purpose.

Oppure, potete prendere un template pronto. Se volete vedere un assessment completo, guardate quello che ho fatto per un articolo di A List Apart. Ho anche creato un file vuoto con molte delle cose più delicate degli spreadsheet già fatte.. Andate pure su File > Make a Copy così potete giocarci un po’. Dovete solo ottenere i dati della vostra pagina da WebPagetest e copiarci le tre colonne. Dopo di che, potete cominciare la vostra valutazione riga per riga.

Distinguere il bene dal male#section12

Se mostrate i vostri dati a uno stakeholder, potrebbe rimanere sorpreso da quanto peso della pagina web sia dovuto a cose come gli ads o le statistiche. D’altro canto, potrebbero rispondere chiedendo a cosa dovremmo puntare. È un po’ più difficile rispondere a questa domanda.

Alcuni benchmark sono un po’ vaghi: 1 MB o meno, un WebPagetest Score di 1000, un punteggio di Google PageSpeed di più di 90, e così via. Tuttavia si tratta di parametri molto arbitrari e, a seconda del vostro progetto, potrebbero essere ideali irraggiungibili.

Il mio suggerimento? Fate un assessment come questo sui vostri competitor. Se tornate dai vostri stakeholder e mostrate loro come si posizionano due o tre competitor e quello che state facendo, andrete molto più lontano nel sostenere la performance.

Ricordate che la performance non è mai “finita”: può solo migliorare. Quello che potrebbe aiutare la vostra azienda è fare assessment come questo nel tempo e presentare la performance della pagina come una serie continua di grafici a barre. Con un po’ di sforzo (e fortuna), dovreste essere in grado di dimostrare che le cose che stanno a cuore alla vostra organizzazione stanno migliorando continuamente. In caso contrario, presenterete un caso molto più persuasivo a sostegno delle cose che devono cambiare in meglio.

E così abbiamo dei grafici carini. E adesso?#section13

L’utilità dei vostri grafici varierà a seconda delle esigenze di business precise della vostra azienda e delle politiche della vostra organizzazione.

Per esempio, supponiamo che siate sviluppatori e un project manager vi chieda di aggiungere un altro script per le metriche degli ads al vostro sito. Dopo aver completato una valutazione come quella di cui sopra, potreste essere in grado di tornare dal project manager e dire: “Gli ads costituiscono già il 40% del peso della nostra pagina. Vuole davvero aggiungerne altro?”

Dal momento che avete attribuito un purpose, uno scopo, alle vostre asset request, sarete in grado di offrire dati come questo. Una volta ho lavorato con un project manager che aveva cominciato a respingere tali richieste perché ero in grado di dargli dei dati facili da capire come questi. Non sto dicendo che succederà sempre così, ma dovete dare ai decision maker delle informazioni che possano carpire.

Ricordatevi, inoltre, che siete voi i responsabili della colonna Purpose. Potete inventare qualsiasi scopo vogliate. Siete interessati all’impatto che hanno i file movie sul vostro sito rispetto a tutto il resto? Create un purpose “Movies”. Volete confrontare i file dei framework rispetto a quelli che avete redatto personalmente? Fatelo!

Spero che questo articolo vi faccia prendere in considerazione, per poi riconsiderare, ogni singola cosa che scaricate su una data pagina. Ogni singola richiesta. E, mentre lo fate, spero che siate equipaggiati per evidenziare per scopo ogni item che chiedete ai vostri utenti di scaricare. Questo vi permetterà di parlare lo stesso linguaggio con i vostri stakeholder e vi aiuterà a sostenere scelte migliori per la performance.

Ulteriori letture:

Sull’autore

Chip Cullen

Chip Cullen è senior front-end developer in PBS. Ha molto a cuore la performance, l'accessibilità e i design system. Ha cominciato la sua carriera come designer e, facendo alcune tappe durante il percorso, è passato allo sviluppo. Vive fuori Washington, DC, dove gli piace correre, scatenarsi con i suoi figli, cucinare con sua moglie e dipingere acquerelli.

Nessun commento

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Altro da ALA

Webwaste

In questo estratto da World Wide Waste, Gerry McGovern esamina l'impatto ambientale di siti web pieni zeppi di asset inutili. Digital is physical. Sembra economico e gratis ma non lo è: ci costa la Terra.
Industry