Velocità di interazione e latency UI

1) Che cos'è la velocità dell'interfaccia

1. Input latency - Dal gesto al gestore dell'evento.

2. Network latency - prima della risposta backend/cache.

3. Render latency - Elaborazione sul flusso principale (JS/CSS/layout/paint).

4. Animation latency - fluidità e stabilità dei fotogrammi.

Obiettivo: l'utente vede istantaneamente che l'azione è iniziata e dove si muove il processo; il risultato reale arriva prevedibilmente.

2) Soglie di percezione umana

50 ms - Lampo (eco di stampa, tasto premuto).
100 ms - «istantaneo» (click di risposta visiva).
200 ms sono ammissibili per la maggior parte delle reazioni UI.
≤ 1000 mc - tollerabile con un netto progresso/skeleton.

3) Modello RAIL e budget di destinazione

R (Response) - Risposta all'input

Click/tap ha una risposta visiva di 100 ms.
Focus/hover 80-120 mc.

A (Animal) - Fluidità

60 FPS ⇒ 16. 7 ms; operazioni pesanti da rimuovere dal fotogramma.
Animiamo solo 'transfer'/' opacity'.

I (Idle) - Operazioni di sfondo

Dividiamo in slot 50 mc, usiamo le finestre idle.

L (Load) - Caricamento

TTFB 200 mc, LCP 2. 5 c, INP a 200 mc, CLS a 0. 1.

4) KPI e alert di velocità

INP (Interaction to Next Paint): p75 <200 ms (ok), 200-500 (da migliorare).
Long Tasks (> 50 ms) - Percentuale di fotogrammi con LT <5%.
TTFB p75 <200 ms (kash/Edge), LCP p75 <2. 5 secondi.
First User Feedback (FUF) - Tempo fino alla prima conferma visiva dell'azione da 100 ms.
Time-to-Usable per i moduli: 1 da prima dell'immissione del primo campo.

5) Pattern UX di risposta immediata

1. Aggiornamenti ottimistici: cambiamo l'UI subito (bilanciamento/puntata/mi piace), e ripartiamo in caso di errore.
2. Scheletri al posto dello spinner, se la struttura è nota.
3. Progress/fase: un progredire determinato, se la lunghezza del processo è nota.
4. Suggerimenti locali: toast immediati/state Invia... 100 mc.
5. L'obiettivo è hover/visibilità «prefetch »/« pratoad».

6) Tecniche di riduzione dei ritardi

6. 1 Input → Render

Togliere 300 mc delay su mobile: '<meta name = "viewport" content = "width = device-width, iniziale-scale = 1"> ".
Ascoltatori passive per scroll/tac: 'addEventListener (' touchstart ', handler, {passive: true})'.
L'elaborazione del click è una microsadio o un' requestAnimationFrame "per disegnare rapidamente la conferma.
Evitare layout-thrash: lettura/scrittura layout - Battiti.

6. 2 JS e flusso principale

Separare i bandi (code-splitting) e scaricare lungo i percorsi.
Calcoli pesanti per Web Worker.
Usa'scheduler '. "/" "per le attività di fondo.
CSS-inline critico; JS с `defer`/`async`.
Virtualizzazione degli elenchi, 'content-visibility: auto', 'content: content'.

6. 3 Render e animazioni

Animare 'form/opacity'; non animare «height/left/box-shadow» su centinaia di elementi.
«will-change» mettere temporaneamente prima dell'animazione; Pulire dopo.
Sprite/vettore invece di enormi PNG; evitare heavy blur.

6. 4 Rete e cash

Edge-кеш (CDN), `cache-control`, `stale-while-revalidate`.
Precisnect ai domini critici Early Hints (103), HTTP/2/3.
Prefetch intento (hover/viewport).
Streaming/SSR + idrazione progressiva/isole.

7) Debouns/trottling e code

Debouns - Da ricercare durante l'input (150-300 ms).
Trottling - per scroll/resize (100-200 mc).
Code/batching degli aggiornamenti UI per eventi frequenti (dati live).

js const debounce = (fn, ms=200)=>{let t; return (...a)=>{clearTimeout(t); t=setTimeout(()=>fn(...a),ms)}}
const throttle = (fn, ms=120)=>{let t=0; return (...a)=>{const n=Date. now(); if(n-t>ms){t=n; fn(...a)}}}

8) Pattern download e feedback

Skeleton → Content (senza spostamenti, altezza fissa).
Shimmer 1200-1600 mc, ampiezza 20%.
Carta ottimistica: anticipo grigio + testo - Sostituisci quando arrivano i dati.
Errore: striscione retry corto, chiavi idempotency per ripetizioni.

9) Strategie di rete per una risposta rapida

• conferma UI subito (ottimista), backend - idempotent;
• quando il timeout (3-5 s) mostra lo stato «ricevuto, elaborato» + retrai di sfondo;
• WebSocket/SSE per gli stati, backoff 1-2-4-8.

Pre-dati - Cache warm-up pianificata, prefetch delle rotte più popolari.

Edge funzioni: validazioni/aggregazioni più vicine all'utente.

10) Codice-snippet UI veloce

js btn. addEventListener('click', () => {
btn. classList. add ('is-busy') ;//requestAnimationFrame instant visual response (async () => {
try {
const res = await fetch('/api/action', { method: 'POST', body: payload });
if (!res.ok) throw new Error('fail');
btn. classList. add('is-done');
} catch {
btn. classList. remove('is-busy'); btn. classList. add('is-error');
}
});
});

js const prefetch = url => fetch(url, { credentials:'include', priority:'low' }). catch(()=>{});
document. querySelectorAll('a[data-prefetch]'). forEach(a=>{
a. addEventListener('mouseenter', () => prefetch(a. href), { once:true });
const io=new IntersectionObserver(e=>{ if(e[0].isIntersecting){prefetch(a. href); io. disconnect();} });
io. observe(a);
});

css
.btn. is-busy { pointer-events:none; }
.skeleton { position:relative; background: var(--bg-elevated); overflow:hidden; }
.skeleton::after {
content:""; position:absolute; inset:0;
background: linear-gradient(90deg, transparent, rgba(255,255,255,.12), transparent);
animation: shimmer 1. 4s infinite;
}
@keyframes shimmer { from { transform: translateX(-100%);} to { transform: translateX(100%);} }

11) Diagnostica e monitoraggio

Campo: RUM (metriche di campo) p75 per paese/rete/dispositivo.
Traccia click: «input handler» network «paint».
Etichetta «zone rosse»: Lungo task marcatori, blocking-time, slow-route list.
Alert di degrado INP/LCP/TTFB.
Prove scenografiche: scrittura di un tempo di riferimento click per modificare il DON.

12) Specificità del iGaming

• UI: fissa istantaneamente lo stato del pulsante (pressed → busy), la ripresa è il toast «Ricevuto».
• Backend: chiave idempotent a tasso; stato - attraverso il WebSocket; timeout «pending» trasparente.
• Budget UI: FUF da 100 ms, conferma totale da 1 c (se più a lungo, mostra timer/causa).

• Accelerazione di 200 ms, rotazione uniforme, spegnimento di 300-500 ms; senza cicli infiniti.
• Gli stub vincitrici sono senza righe, testo/somma sono leggibili (AAA).

• Patch delta una volta ogni 250-1000 ms, batch;
• diff visivo (freccia/colore/spessore) senza sbalzi layout;
• aggiornamenti anti-drebising su hover/focus.

• Accantonamento del conto con batch 40-60 ms, numeri tabellari;
• cappello sticky, virtualizzazione delle righe.

13) Anti-pattern

Nessuna risposta immediata al click (in attesa della rete).
Animazioni pesanti «filter/box-shadow» su centinaia di elementi.
Una enorme banda JS> 1-2 MB su un percorso critico.
«Spinner nel vuoto» oltre 1-2 s senza progresso/skeleton.
Lettura/scrittura layout in una singola teca (layout thrashing).
Funzioni hover-only su mobile.

14) Token di velocità (sistema di progettazione)

json
{
"latencyBudget": {
"tapFeedbackMs": 100,
"keyEchoMs": 50,
"hoverMs": 120,
"pressMs": 90,
"modalInMs": 240,
"toastInMs": 200
},
"webVitalsTargets": { "INP": 200, "LCP": 2500, "CLS": 0. 1, "TTFB": 200 },
"animation": {
"easing": { "std": "cubic-bezier(0. 2,0,0. 2,1)", "acc": "cubic-bezier(0. 4,0,1,1)" },
"duration": { "hover": 160, "active": 90, "overlay": 240 }
}
}

15) QA-lista di velocità

Risposta

• Click/tap per una risposta visiva di 100 ms; l'eco di 50 ms.
• Non ci sono 300 ms di ritardo sui cellulari.
• INP p75 da 200 ms; La quota di Long Tasks è del 5%.

Caricamento

• TTFB da 200 ms; LCP ≤ 2. 5 c; CLS ≤ 0. 1.
• Scheletri/progresso invece di spinners «appesi».

Render

• Solo 'form/opacity'nelle animazioni; non ci sono ombre pesanti sui massi.
• content-visibility/virtualizzazione per elenchi lunghi.

Rete

• Edge-cash, preconnect, prefetch di intento.
• Idampotenza e retrai per azioni critiche.

A11y

• 'prefers-reduced-motion'supportato.
• I contenuti Hover sono disponibili tramite focus/tastiera.

16) Documentazione per il sistema di progettazione

Latency Budget: tabella delle soglie (tap, hover, modal, toast, modulo).
Istant Feedback - Pattern di ottimismo + ripristino.
Preferch by Intent - Hyde e utilità.
Performance Playbook - Assegni di profilatura e alert RUM.
«Do/Don't» è un esempio di script rapidi/lenti con numeri.

Breve riepilogo

La velocità di interazione è una risposta immediata e prevedibile. Tenere 100 ms come budget sacro per first-feedback, ottimizzare la rete (Edge/kash/prefetch), scaricare il flusso principale, animare solo le proprietà a basso costo e applicare pattern ottimistici. Allora l'interfaccia si percepisce viva, comprensibile e sostenibile - soprattutto in scenari con tassi elevati e tempo reale.