Liste veloci nei cruscotti con 100k righe: da dove cominciare

Perché le schermate lista rallentano man mano che i dati crescono

Una schermata lista di solito sembra ok finché non smette di esserlo. Gli utenti cominciano a notare piccoli blocchi che si sommano: lo scorrimento balbetta, la pagina si blocca un attimo dopo ogni aggiornamento, i filtri impiegano secondi a rispondere e vedi uno spinner dopo ogni click. A volte la scheda del browser pare congelata perché il thread UI è occupato.

100k righe è un punto di svolta comune perché mette sotto stress tutte le parti del sistema insieme. Il dataset è ancora normale per un database, ma è abbastanza grande da rendere evidenti piccole inefficienze nel browser e sulla rete. Se provi a mostrare tutto in una volta, una schermata semplice diventa una pipeline pesante.

L’obiettivo non è renderizzare tutte le righe. L’obiettivo è aiutare qualcuno a trovare quello che serve rapidamente: le 50 righe giuste, la pagina successiva o una fetta stretta filtrata.

Conviene dividere il lavoro in quattro parti:

• Network: quanti byte invii e quante volte.
• Database: quanti dati scansioni, ordini e aggregi per richiesta.
• Rendering nel browser: quanti nodi DOM crei, misuri e dipingi.
• Lavoro JavaScript: quante volte re-renderizzi, ricalcoli colonne o ricalcoli risultati.

Se anche una sola parte è costosa, l’intera schermata sembra lenta. Una semplice casella di ricerca può attivare una richiesta che ordina 100k righe, restituisce migliaia di record e poi forza il browser a renderizzarli tutti. Ecco perché digitare diventa lento.

Quando i team costruiscono strumenti interni rapidamente (anche con piattaforme low-code come Koder.ai), le schermate lista sono spesso il primo posto dove la crescita reale dei dati espone il divario tra “funziona su dataset demo” e “sembra istantaneo tutti i giorni”.

Scegli l’obiettivo di prestazioni giusto

Prima di ottimizzare, decidi cosa significa “veloce” per questa schermata. Molti team inseguono il throughput (caricare tutto) quando gli utenti hanno principalmente bisogno di bassa latenza (vedere qualcosa aggiornarsi rapidamente). Una lista può sembrare istantanea anche se non carica mai tutte le 100k righe, purché risponda rapidamente a scorrimento, ordinamento e filtri.

Un obiettivo pratico è il tempo alla prima riga, non il tempo per caricare tutto. Gli utenti si fidano della pagina quando vedono le prime 20–50 righe in fretta e le interazioni restano fluide.

Cosa misurare (e perché)

Scegli un piccolo set di numeri da tracciare ogni volta che cambi qualcosa:

• Tempo alla prima riga dopo l’apertura della pagina o il cambio filtro
• Tempo perché un filtro o ordinamento mostri i risultati aggiornati
• Dimensione della risposta (payload JSON approssimativo)
• Query lente (soprattutto COUNT(*) e SELECT ampi)
• Picchi sul main-thread del browser (scorrimento a scatti, lag nella digitazione)

Questi si mappano ai sintomi comuni. Se la CPU del browser impazzisce quando scorri, il frontend sta facendo troppo lavoro per riga. Se lo spinner aspetta ma lo scorrimento è ok dopo, di solito il problema è backend o rete. Se la richiesta è veloce ma la pagina si blocca, quasi sempre è rendering o pesante elaborazione client-side.

Un semplice test frontend vs backend

Prova questo esperimento: mantieni la UI identica, ma limita temporaneamente il backend a restituire solo 20 righe con gli stessi filtri. Se diventa veloce, il collo di bottiglia è la dimensione del caricamento o il tempo della query. Se resta lento, guarda il rendering, il formatting e i componenti per riga.

Esempio: una schermata Orders interna sembra lenta quando digiti nella ricerca. Se l’API restituisce 5.000 righe e il browser le filtra a ogni battitura, la digitazione laggherà. Se l’API impiega 2 secondi a causa di una query COUNT su un filtro non indicizzato, vedrai l’attesa prima che qualsiasi riga cambi. Fix diversi, stessa lamentela utente.

Fondamentali frontend: mantieni il rendering economico

Il browser è spesso il primo collo di bottiglia. Una lista può sembrare lenta anche quando l’API è veloce, semplicemente perché la pagina sta cercando di dipingere troppo. La prima regola è semplice: non renderizzare migliaia di righe nel DOM tutte insieme.

Anche prima di aggiungere la virtualizzazione completa, mantieni ogni riga leggera. Una riga con wrapper annidati, icone, tooltip e stili condizionali complessi in ogni cella ti costa a ogni scroll e a ogni aggiornamento. Preferisci testo semplice, un paio di badge piccoli e solo uno o due elementi interattivi per riga.

Un’altezza riga stabile aiuta più di quanto sembri. Quando ogni riga ha la stessa altezza, il browser può prevedere il layout e lo scorrimento resta fluido. Le righe con altezza variabile (descrizioni che vanno a capo, note espandibili, avatar grandi) attivano misurazioni aggiuntive e reflow. Se ti servono dettagli extra, considera un pannello laterale o un’area espandibile singola, non una riga multi-linea completa.

La formattazione è un’altra tassa silenziosa. Date, valute e pesante lavoro su stringhe si sommano quando ripetuti in molte celle.

Regola pratica

Se un valore non è visibile, non calcolarlo ancora. Cache i risultati di formattazione costosi e calcolali su richiesta, per esempio quando una riga diventa visibile o quando l’utente apre una riga.

Un rapido intervento che spesso dà un guadagno tangibile:

• Limita il render iniziale a una piccola pagina (o finestra virtuale) di righe
• Mantieni l’altezza riga fissa ed evita celle multi-linea
• Sposta UI pesante (tooltip, menu) su hover o click
• Memoizza o metti in cache formattazioni di date e valute per riga
• Evita di re-renderizzare tutte le righe quando cambia solo un filtro

Esempio: una tabella Invoices interna che formatta 12 colonne di valute e date balbetterà nello scroll. Mettere in cache i valori formattati per fattura e ritardare il lavoro per le righe off-screen può farla sembrare istantanea, anche prima di interventi più profondi sul backend.

Virtualizzazione: come scorrere 100k righe in modo fluido

La virtualizzazione fa sì che la tabella disegni solo le righe che puoi effettivamente vedere (più un piccolo buffer sopra e sotto). Mentre scorri, riusa gli stessi elementi DOM e sostituisce i dati dentro di essi. Questo evita che il browser cerchi di dipingere decine di migliaia di componenti riga contemporaneamente.

La virtualizzazione è adatta quando hai liste lunghe, tabelle larghe o righe pesanti (avatar, chip di stato, menu di azione, tooltip). È utile anche quando gli utenti scorrono molto e si aspettano una vista continua e fluida anziché spostarsi pagina per pagina.

Dove la virtualizzazione diventa complicata

Non è magia. Alcune cose spesso causano sorprese:

• Le altezze riga variabili (testo che va a capo, righe espandibili) possono rompere lo scorrimento fluido a meno di misurare le altezze o mantenere righe di dimensione consistente.
• Header sticky e colonne sticky possono entrare in conflitto con il contenitore virtualizzato se il layout usa CSS complesso.
• La navigazione da tastiera (su/giù, page up/down, focus nelle celle) richiede attenzione in più perché il focus non salti su righe non montate.
• Le azioni in blocco necessitano di una regola chiara: selezionare le righe visibili, selezionare attraverso i filtri o selezionare sull’intero dataset.

L’approccio più semplice è noioso: altezza riga fissa, colonne prevedibili e non troppi widget interattivi dentro ogni riga.

Virtualizzazione più paginazione (senza confondere gli utenti)

Puoi combinare entrambi: usa paginazione (o caricamento con cursore) per limitare ciò che prendi dal server e virtualizzazione per tenere economico il rendering dentro la fetta scaricata.

Un pattern pratico è prelevare una pagina normale (spesso 100–500 righe), virtualizzare all’interno di quella pagina e offrire controlli chiari per spostarsi tra le pagine. Se usi lo scroll infinito, aggiungi un indicatore visibile “Caricate X di Y” così gli utenti capiscono che non stanno vedendo tutto.

Scelte di paginazione che restano veloci

Se ti serve una lista che rimanga utilizzabile mentre i dati crescono, la paginazione è di solito il default più sicuro. È prevedibile, funziona bene per flussi admin (review, edit, approve) e supporta bisogni comuni come esportare “pagina 3 con questi filtri” senza sorprese. Molti team tornano alla paginazione dopo aver provato scroll più sofisticati.

Lo scroll infinito può sembrare gradevole per la navigazione casuale, ma ha costi nascosti. Le persone perdono il senso del punto in cui si trovano, il pulsante indietro spesso non riporta allo stesso posto e sessioni lunghe possono accumulare memoria man mano che si caricano più righe. Un compromesso è un pulsante Carica altro che comunque usa pagine, così l’utente resta orientato.

Offset vs keyset pagination

L’offset (page=10&size=50) è il classico approccio. È semplice, ma può rallentare su tabelle grandi perché il database potrebbe dover scorrere molte righe per raggiungere pagine successive. Inoltre può risultare strano quando arrivano nuove righe e gli elementi si spostano tra le pagine.

La keyset (cursor) pagination chiede “le prossime 50 righe dopo l’ultimo elemento visto”, di solito usando un id o created_at. Tende a restare veloce perché non deve contare o saltare molte righe.

Regola pratica:

• Usa offset per liste più piccole, dataset stabili e quando devi saltare a un numero di pagina esatto.
• Usa keyset per liste molto grandi, inserimenti frequenti e navigazione Next/Previous.

Mostrare i totali senza pagarli ogni volta

Agli utenti piace vedere i totali, ma un “count di tutte le righe corrispondenti” può essere costoso con filtri pesanti. Opzioni includono cache dei conteggi per filtri popolari, aggiornare il conteggio in background dopo il caricamento della pagina o mostrare un conteggio approssimato (es. “10.000+”).

Esempio: una schermata Orders interna può mostrare risultati istantanei con paginazione keyset, poi completare il totale esatto solo quando l’utente smette di cambiare filtri per un secondo.

Se stai costruendo questo in Koder.ai, tratta la paginazione e il comportamento dei conteggi come parte della specifica della schermata fin dall’inizio, così le query generate dal backend e lo stato UI non si pestano i piedi dopo.

Filtri e ricerca che sembrano istantanei

La maggior parte delle liste sembra lenta perché parte troppo aperta: carica tutto, poi chiede all’utente di restringere. Capovolgi l’approccio. Parti con valori sensati che restituiscono un set piccolo e utile (per esempio: ultimi 7 giorni, My items, Status: Open) e fai di “Tutto il periodo” una scelta esplicita.

La ricerca testuale è un altro tranello comune. Se lanci una query a ogni battitura, crei un backlog di richieste e una UI che sfarfalla. Debounce l’input di ricerca in modo da interrogare solo dopo che l’utente ha fatto una breve pausa e annulla le richieste vecchie quando ne parte una nuova. Regola semplice: se l’utente sta ancora digitando, non colpire il server.

I filtri funzionano solo quando sono chiari. Mostra le chip dei filtri in cima alla tabella così l’utente vede cosa è attivo e può rimuoverlo con un clic. Usa etichette umane, non nomi di campo grezzi (per esempio, Owner: Sam invece di owner_id=42). Quando qualcuno dice “i miei risultati sono scomparsi”, di solito c’è un filtro invisibile.

Pattern che mantengono le liste grandi reattive senza complicare l’UI:

• Default a filtri stretti e range di date brevi
• Debounce per la ricerca testuale e annullamento delle richieste in corso
• Mostra chip dei filtri e un’azione Cancella tutto
• Offri viste salvate per lavori comuni
• Gate per filtri costosi finché non è impostato almeno un filtro di restringimento

Le viste salvate sono l’eroe silenzioso. Invece di insegnare agli utenti a creare ogni volta combinazioni di filtri ad-hoc, dai loro preset che rispecchiano flussi reali. Un team ops potrebbe alternare Failed payments today e High-value customers. Quelli possono esserci con un click, comprensibili istantaneamente e più semplici da mantenere veloci sul backend.

Se costruisci uno strumento interno in un builder chat-driven come Koder.ai, tratta i filtri come parte del flusso prodotto, non come un’aggiunta. Parti dalle domande più comuni, poi progetta la vista predefinita e le viste salvate attorno a quelle.

Modellazione delle query: invia meno, calcola meno

Una schermata lista raramente ha bisogno degli stessi dati di una pagina dettaglio. Se la tua API restituisce tutto su tutto, paghi due volte: il database fa più lavoro e il browser riceve e rende più di quanto serva. La modellazione delle query è l’abitudine di richiedere solo ciò che la lista serve in quel momento.

Inizia restituendo solo le colonne necessarie per rendere ogni riga. Per la maggior parte dei cruscotti sono sufficienti id, un paio di etichette, uno stato, un owner e timestamp. Testi lunghi, blob JSON e campi calcolati possono aspettare che l’utente apra la riga.

Evita join pesanti per la prima pittura. I join vanno bene quando usano indici e restituiscono risultati piccoli, ma diventano costosi quando unisci molte tabelle e poi ordini o filtri sui dati uniti. Un pattern semplice: prendi la lista da una tabella velocemente, poi carica i dettagli correlati on demand (o batch-load solo per le righe visibili).

Limita le opzioni di ordinamento e ordina su colonne indicizzate. “Ordina per qualsiasi colonna” sembra utile, ma spesso forza ordinamenti lenti su dataset grandi. Preferisci poche scelte prevedibili come created_at, updated_at o status, e assicurati che quelle colonne siano indicizzate.

Stai attento con l’aggregazione server-side. COUNT(*) su un set filtrato enorme, DISTINCT su una colonna ampia o i calcoli delle pagine totali possono dominare il tempo di risposta.

Approccio pratico:

• Modella la risposta lista su 5–10 campi
• Recupera i dettagli riga solo quando la riga è aperta
• Permetti 2–4 opzioni di ordinamento, tutte supportate da indici
• Tratta COUNT e DISTINCT come opzionali; mettili in cache o approssimali quando possibile

Se costruisci strumenti interni su Koder.ai, definisci una query lista leggera separata dalla query dettaglio in fase di pianificazione, così l’UI resta reattiva man mano che i dati crescono.

Tattiche database per tabelle grandi

Se vuoi una lista che resti veloce a 100k righe, il database deve fare meno lavoro per richiesta. La maggior parte delle liste lente non è “troppi dati”, ma il pattern di accesso sbagliato.

Inizia con indici che corrispondono a ciò che gli utenti fanno davvero. Se la tua lista è solitamente filtrata per status e ordinata per created_at, ti serve un indice che supporti entrambi, in quell’ordine. Altrimenti il database potrebbe scansionare molte più righe del previsto e poi ordinarle, cosa che diventa costosa in fretta.

Fix che di solito portano i maggiori guadagni:

• Aggiungi indici compositi che rispecchino il filtro + ordinamento comune (es. tenant_id, status, created_at).
• Preferisci paginazione keyset (cursor) rispetto a OFFSET profondo. OFFSET fa camminare il DB passando molte righe solo per saltarle.
• Tratta il conteggio totale come opzionale. I totali esatti possono essere lenti su set filtrati grandi. Metti in cache i conteggi, precomputali o mostra “10.000+” quando i numeri esatti non sono richiesti.
• Mantieni le righe “sottili”. Non selezionare campi testuali grandi, blob JSON o oggetti annidati per la lista.
• Modella le query in modo da restituire solo ciò che l’UI rende: poche colonne, più il cursore della pagina successiva.

Esempio semplice: una tabella Orders interna che mostra nome cliente, stato, importo e data. Non fare join con tutte le tabelle correlate e non tirare fuori tutte le note d’ordine per la vista lista. Restituisci solo le colonne usate nella tabella e carica il resto in una richiesta separata quando l’utente clicca su un ordine.

Se costruisci con una piattaforma come Koder.ai, mantieni questa mentalità anche se l’interfaccia è generata dalla chat. Assicurati che gli endpoint API generati supportino paginazione a cursore e campi selezionabili, così il lavoro del database resta prevedibile mentre la tabella cresce.

Piano step-by-step per velocizzare una schermata lista esistente

Se una pagina lista sembra lenta oggi, non iniziare riscrivendo tutto. Parti definendo cosa è uso “normale”, poi ottimizza quel percorso.

Un piano pratico in cinque passi

1. Definisci la vista predefinita. Scegli filtri predefiniti, ordine e colonne visibili. Le liste rallentano quando cercano di mostrare tutto per default.

2. Scegli uno stile di paging che corrisponda all’uso. Se gli utenti scansionano soprattutto le prime pagine, la paginazione classica va bene. Se saltano in profondità (pagina 200+) o hai bisogno di performance stabili a qualsiasi profondità, usa keyset pagination (basata su un ordinamento stabile come created_at più un id).

3. Aggiungi virtualizzazione per il corpo della tabella. Anche se il backend è veloce, il browser può soffocare quando renderizza troppe righe insieme.

4. Rendi ricerca e filtri reattivi. Debounce sulla digitazione così non spari richieste a ogni tasto. Conserva lo stato dei filtri nell’URL o in uno store condiviso in modo che refresh, back button e condivisione della vista funzionino. Metti in cache l’ultimo risultato riuscito così la tabella non lampeggia vuota.

5. Misura, poi affina query e indici. Logga tempo server, tempo database, dimensione del payload e tempo di render. Poi sgronda la query: seleziona solo le colonne che mostri, applica i filtri presto e aggiungi indici che corrispondano al filtro + ordinamento predefinito.

Esempio: un cruscotto support con 100k ticket. Default a Open, assegnati al mio team, ordinati per i più recenti, mostra sei colonne e preleva solo ticket id, subject, assignee, status e timestamp. Con paginazione keyset e virtualizzazione, mantieni sia il database sia l’UI prevedibili.

Se costruisci strumenti interni in Koder.ai, questo piano si sposa bene a un flusso iterate-and-check: aggiusta la vista, testa scorrimento e ricerca, poi affina la query finché la pagina resta reattiva.

Errori comuni che rallentano le liste

Il modo più veloce per far sembrare una lista rotta è trattare 100k righe come una pagina normale. La maggior parte delle dashboard lente ha alcune trappole prevedibili.

Una grossa è renderizzare tutto e nasconderlo con CSS. Anche se sembra che solo 50 righe siano visibili, il browser paga comunque per creare 100k nodi DOM, misurarli e repaintare nello scroll. Se ti servono liste lunghe, rendi solo ciò che si vede (virtualizzazione) e mantieni i componenti riga semplici.

La ricerca può anche rovinare le performance quando ogni battitura scatena una scansione dell’intera tabella. Questo succede quando i filtri non sono indicizzati, quando cerchi su troppe colonne o quando fai query di contains su campi testuali grandi senza piano. Una buona regola: il primo filtro che l’utente raggiunge dovrebbe essere economico in DB, non solo comodo in UI.

Un altro problema comune è recuperare record completi quando la lista chiede solo riassunti. Una riga di lista di solito necessita di 5–12 campi, non dell’oggetto completo, non di descrizioni lunghe e non di dati correlati. Tirare dati extra aumenta lavoro DB, tempo di rete e parsing sul frontend.

Esportazioni e totali possono bloccare l’UI se li calcoli sul main thread o aspetti una richiesta pesante prima di rispondere. Mantieni l’UI interattiva: avvia esportazioni in background, mostra il progresso ed evita di ricalcolare totali a ogni cambio filtro.

Infine, troppe opzioni di ordinamento possono ritorcersi contro. Se gli utenti possono ordinare per qualsiasi colonna, finirai per ordinare grandi result set in memoria o costringere il DB in piani lenti. Limita gli ordinamenti a poche colonne indicizzate e fai in modo che l’ordinamento di default corrisponda a un indice reale.

Controllo rapido:

• Se puoi scorrere all’infinito senza caricare, probabilmente hai renderizzato troppo.
• Se digitare nella ricerca lagga, la query sta probabilmente scansionando.
• Se l’API della lista restituisce JSON enorme, stai overfetching.
• Se l’esportazione blocca la pagina, il lavoro sta avvenendo nel posto sbagliato.
• Se ogni ordinamento è lento, serve indicizzazione e riduzione delle opzioni di sort.

Checklist rapida e prossimi passi

Tratta le prestazioni della lista come una feature di prodotto, non come una correzione una tantum. Una schermata lista è veloce solo quando sembra veloce mentre persone reali scorrono, filtrano e ordinano su dati reali.

Usa questa checklist per confermare di aver sistemato le cose giuste:

• First paint veloce: la pagina carica un payload piccolo e mostra subito le prime righe.
• Scorrimento fluido: virtualizzazione attiva, CPU browser non picca e altezza righe prevedibile.
• Filtri reattivi: digitare o selezionare un filtro aggiorna i risultati rapidamente e i filtri non si resettano spostandosi tra pagine o ricaricando.
• Ordinamento sensato: permetti solo ordinamenti supportati da un indice o da un campo precomputato e mantieni l’ordine coerente tra le pagine.
• Richieste modellate: l’API restituisce solo le colonne che mostri, più ID stabili e cursori, non oggetti completi “se serve”.

Un controllo di realtà: apri la lista, scorri per 10 secondi, poi applica un filtro comune (es. Status: Open). Se l’UI si blocca, il problema è quasi sempre rendering (troppe righe DOM) o una trasformazione client-side pesante (ordinamento, raggruppamento, formattazione) che scatta a ogni aggiornamento.

Prossimi passi, in ordine, così non rimbalzi tra fix diversi:

1. Misura un flusso utente end-to-end (caricamento, scorrimento, filtro, ordinamento) e scrivi i tempi target.
2. Attiva la virtualizzazione e limita formattazioni costose nelle celle (date, valute, avatar).
3. Sposta filtraggio e ordinamento sul server e limita le opzioni a quelle che possono essere veloci.
4. Restringi le query e i payload, poi rimisura.

Se costruisci questo con Koder.ai (koder.ai), parti da Planning Mode: definisci esattamente colonne della lista, campi filtro e shape della risposta prima. Poi itera usando snapshot e rollback quando un esperimento rallenta lo schermo.