Prestazioni: quando misurare e quando aspettare

Questa lezione appartiene al Modulo 18 — Qualità del sistema.

Obiettivo della lezione

Capire quando vale la pena misurare le prestazioni del Registro e quando invece è meglio aspettare. Conoscere gli strumenti concreti per misurare (senza ottimizzare prematuramente).

Alla fine sai usare console.time per misurare un’operazione specifica e conosci le soglie pratiche da usare come riferimento.

Perché serve nel percorso

L’ottimizzazione prematura è la fonte di molti problemi nei progetti: si rendono complesse cose semplici per guadagnare millisecondi invisibili all’utente. Nel Registro scolastico, la maggior parte delle operazioni su localStorage con 50-200 strumenti è già abbastanza veloce.

Nel Registro del laboratorio

Il Registro ha due tipi di operazioni che vale la pena misurare:

1. Operazioni che l’utente attende attivamente (soglia: 100ms)

Se l’utente clicca un bottone e il risultato non appare in 100ms, percepisce il sistema come lento. Questo include: la ricerca degli strumenti, il caricamento della lista.

2. Operazioni in background (soglia: 10ms)

localStorage è sincrono — se un’operazione di salvataggio o lettura richiede più di 10ms, può bloccare il thread principale. Con 50 strumenti, questo non dovrebbe mai accadere.

Come misurare con console.time:

// src/application/cercaStrumenti.js
export function cercaStrumenti(filtri, archivio) {
  console.time("cercaStrumenti"); // inizia il timer

  const tutti = archivio.trovaTutti();
  const risultato = tutti
    .filter(s => corrispondeAlNome(s, filtri.nome))
    .filter(s => corrispondeAllaCategoria(s, filtri.categoria))
    .filter(s => corrispondeAlloStato(s, filtri.stato));

  console.timeEnd("cercaStrumenti"); // stampa il tempo: "cercaStrumenti: 0.8ms"
  return risultato;
}

Rimuovi il console.time dopo la misurazione — non lasciarlo in produzione.

Come misurare con DevTools Performance:

1. Apri DevTools → Performance.
2. Clicca “Record”.
3. Esegui l’operazione lenta nel Registro.
4. Clicca “Stop”.
5. Leggi il grafico: cerca i blocchi gialli (JavaScript) più lunghi.

Procedura guidata

1. Usa il Registro con 50+ strumenti finti in localStorage.
2. Esegui una ricerca con filtro e misura il tempo con console.time.
3. Esegui un caricamento della lista completa e misura il tempo.
4. Se i tempi sono sotto 10ms: non ottimizzare — il sistema è già veloce.
5. Se un’operazione supera 100ms: identifica il collo di bottiglia prima di ottimizzare.

Attività in classe

Aggiungi 100 strumenti finti in localStorage con questo script (eseguilo nella console del browser):

// Script per popolare localStorage con dati di test
const strumenti = Array.from({ length: 100 }, (_, i) => ({
  id: `str-${String(i).padStart(3, "0")}`,
  name: `Strumento ${i}`,
  category: ["Misura", "Elettronica", "Utensile", "Informatica"][i % 4],
  status: ["disponibile", "in_prestito", "guasto"][i % 3]
}));
localStorage.setItem("registro_strumenti", JSON.stringify(strumenti));
console.log("100 strumenti aggiunti");

Poi misura:

• tempo di caricamento della lista completa;
• tempo di ricerca per nome (“str-0”);
• tempo di filtro per categoria (“Misura”).

Compila la scheda:

## Misure di prestazione

Strumenti in localStorage: 100

Caricamento lista completa: __ ms
Ricerca per nome: __ ms
Filtro per categoria: __ ms

Soglie superate (>100ms)? sì/no
Azione intrapresa:

Spiegazione guidata per studiare

Le soglie pratiche per il Registro:

Operazione	Soglia accettabile	Azione se supera
Caricamento lista strumenti	< 100ms	Verifica se ci sono operazioni inutili
Ricerca con filtro	< 50ms	Verifica se il filtro è inefficiente
Salvataggio in localStorage	< 10ms	Normale — localStorage è sincrono
Rendering della lista HTML	< 50ms	Verifica se crei troppi elementi DOM

Con 50-200 strumenti, nessuna di queste operazioni dovrebbe avvicinarsi alle soglie su un browser moderno. Se le supera, il problema è quasi sempre nel rendering HTML (troppi innerHTML annidati), non nel JavaScript o in localStorage.

Quando NON ottimizzare:

• le operazioni sono sotto soglia ma vuoi renderle ancora più veloci “per sicurezza”;
• vuoi aggiungere paginazione o lazy loading senza aver misurato che servono;
• vuoi usare IndexedDB invece di localStorage perché “scala meglio” — per 200 strumenti non fa differenza.

Quando ottimizzare:

• hai misurato e una specifica operazione supera la soglia;
• l’utente ha segnalato che il sistema è lento in uno scenario specifico;
• stai aggiungendo una funzione nuova che processa molti dati (es. report di tutti i prestiti).

Il rendering è spesso il vero collo di bottiglia:

// Lento: ricostruisce tutto l'HTML ad ogni aggiornamento
function mostraStrumenti(strumenti) {
  const lista = document.getElementById("lista-strumenti");
  lista.innerHTML = strumenti.map(s => `<li>${s.nome}</li>`).join(""); // ok per 200 elementi
}

// Raramente necessario: solo se hai migliaia di elementi
function mostraStrumentiVirtualizzati(strumenti) {
  // implementazione complessa per grandi dataset
}

Per il Registro con 50-200 strumenti, innerHTML con template literals è abbondantemente sufficiente.

Passo per passo nel progetto

1. Aggiungi 100 strumenti in localStorage usando lo script di test.
2. Misura i tempi delle 3 operazioni principali con console.time.
3. Leggi i valori e confrontali con le soglie.
4. Se tutto è sotto soglia: rimuovi i console.time e passa oltre.
5. Se qualcosa supera la soglia: identifica la riga costosa con DevTools Performance.
6. Documenta la misurazione nel README: “testato con 100 strumenti, tutte le operazioni sotto 10ms”.

Prova di comprensione

• Qual è la soglia percettibile dall’utente per il feedback di un’azione?
• Perché console.time va rimosso dopo la misurazione?
• In quale scenario del Registro potrebbe diventare rilevante la prestazione?
• Qual è il collo di bottiglia più probabile con 200 strumenti?

Errori da evitare

• ottimizzare senza misurare — si perde tempo su cose che già funzionano bene;
• lasciare console.time nel codice di produzione — appesantisce la console;
• aggiungere IndexedDB o Web Workers perché “potrebbero servire” — overengineering;
• misurare in locale con 5 strumenti e concludere che il sistema è lento.

Prodotto da consegnare

Le misure di prestazione per le 3 operazioni principali del Registro con 100 strumenti, la conclusione motivata (“le prestazioni sono accettabili / c’è un collo di bottiglia in X”), e la documentazione nel README.

Checklist di chiusura

• le misure sono state fatte con un dataset realistico (almeno 50 strumenti)
• le misure sono state fatte con console.time o DevTools Performance
• le soglie sono state confrontate con i risultati
• i console.time sono stati rimossi dopo la misurazione
• la conclusione è documentata nel README con i valori misurati

Risultato atteso

Ho aggiunto 100 strumenti di test in localStorage.
Ho misurato: caricamento lista 3ms, ricerca per nome 1ms, filtro per categoria 2ms.
Tutte le operazioni sono abbondantemente sotto soglia.
Non è necessaria alcuna ottimizzazione per il Registro con il dataset attuale.
Ho rimosso i console.time e documentato le misure nel README.