{"id":167258,"date":"2025-06-30T09:00:00","date_gmt":"2025-06-30T09:00:00","guid":{"rendered":"https:\/\/gtechgroup.it\/blog\/tablepress-tabelle-grandi-migliaia-righe\/"},"modified":"2026-05-30T10:00:00","modified_gmt":"2026-05-30T08:00:00","slug":"tablepress-tabelle-grandi-migliaia-righe","status":"publish","type":"post","link":"https:\/\/gtechgroup.it\/blog\/tablepress-tabelle-grandi-migliaia-righe\/","title":{"rendered":"TablePress: Gestire Tabelle Grandi con Migliaia di Righe"},"content":{"rendered":"

TablePress: Gestire Tabelle Grandi con Migliaia di Righe<\/h2>\n

Quando il tuo dataset cresce oltre le poche decine di righe, le sfide tecniche si moltiplicano. Una tabella con migliaia di righe può rallentare drammaticamente il caricamento della pagina, rendere l’ordinamento e il filtro lenti e consumare memoria del browser fino a causare crash su dispositivi meno potenti. TablePress<\/strong> offre diverse strategie per gestire efficacemente tabelle di grandi dimensioni, e in questa guida le esploreremo tutte, dalla configurazione base alle tecniche avanzate della versione Premium.<\/p>\n

Quando una Tabella Diventa “Grande”<\/h2>\n

La definizione di “tabella grande” dipende dal contesto. Per TablePress, una tabella inizia a richiedere attenzioni speciali quando supera le 200-300 righe<\/strong> nella versione gratuita o le 500-1000 righe<\/strong> nella versione Premium. Al di là di queste soglie, le performance lato client (nel browser del visitatore) possono degradare significativamente.<\/p>\n

I fattori che determinano le performance non sono solo il numero di righe, ma anche il numero di colonne, la quantità di HTML nelle celle (immagini, link, formattazione), il numero di tabelle nella stessa pagina e la potenza del dispositivo del visitatore. Una tabella con 500 righe e 3 colonne di testo semplice è molto più leggera di una con 200 righe e 10 colonne contenenti immagini e link.<\/p>\n

I sintomi di una tabella troppo grande includono: tempo di caricamento della pagina superiore a 3-4 secondi, ritardo percepibile quando si ordina o si filtra, scrolling a scatti invece che fluido e, nei casi peggiori, il browser che segnala “La pagina non risponde”. Se riscontri uno di questi problemi, è il momento di ottimizzare.<\/p>\n

\"Gestione<\/p>\n

Paginazione: La Prima Linea di Difesa<\/h2>\n

La paginazione<\/strong> è la strategia più semplice e immediatamente efficace per gestire tabelle grandi. Quando la paginazione è attiva, TablePress mostra solo un numero limitato di righe alla volta (ad esempio 25 o 50), riducendo drasticamente la quantità di HTML che il browser deve renderizzare.<\/p>\n

Per attivare la paginazione, apri la tabella in modalità modifica, scorri fino alle opzioni DataTables e seleziona la checkbox “Paginazione”. Specifica il numero di righe per pagina: per tabelle molto grandi, 20-25 righe sono un buon compromesso tra usabilità e performance. Puoi anche abilitare il selettore che permette agli utenti di scegliere quante righe visualizzare.<\/p>\n

La paginazione da sola non risolve il problema delle performance di DataTables, perché la libreria carica comunque tutti i dati in memoria per permettere ordinamento e filtro. Tuttavia, riduce il rendering DOM iniziale, che è spesso il collo di bottiglia più evidente. Per tabelle fino a 1000-2000 righe, la paginazione combinata con il rendering differito è solitamente sufficiente.<\/p>\n

Rendering Differito (Deferred Rendering)<\/h2>\n

Il rendering differito<\/strong> è una funzionalità di DataTables che cambia il modo in cui le righe vengono create nel DOM. Normalmente, DataTables crea tutti gli elementi HTML per tutte le righe al caricamento della pagina, anche se sono nascoste dalla paginazione. Con il rendering differito, gli elementi HTML vengono creati solo quando diventano necessari (quando la riga deve essere visualizzata).<\/p>\n

Questa ottimizzazione può ridurre il tempo di inizializzazione di una tabella con 5000 righe da diversi secondi a meno di un secondo. L’ordinamento e il filtro rimangono rapidi perché operano sui dati in memoria, non sugli elementi DOM. Il rendering differito è disponibile nella versione Premium di TablePress e si attiva dalle opzioni avanzate della tabella.<\/p>\n

Il rendering differito è trasparente per l’utente: la tabella si comporta esattamente come prima, ma il caricamento è molto più rapido. È la prima ottimizzazione da attivare per qualsiasi tabella con più di 500 righe.<\/p>\n

Server-Side Processing: La Soluzione Definitiva<\/h2>\n

Per tabelle veramente grandi (oltre 5000-10000 righe), la soluzione definitiva è il server-side processing<\/strong>, disponibile nella versione Premium di TablePress. Con questa modalità, l’ordinamento, il filtro e la paginazione vengono eseguiti sul server tramite query al database MySQL, e solo le righe necessarie vengono inviate al browser.<\/p>\n

Il funzionamento è il seguente: quando l’utente carica la pagina, il server invia solo la prima “pagina” di dati (ad esempio 25 righe). Quando l’utente ordina una colonna, il browser invia una richiesta AJAX al server che esegue una query ORDER BY e restituisce le righe ordinate. Lo stesso avviene per il filtro e il cambio pagina.<\/p>\n

Questo approccio elimina virtualmente qualsiasi limite al numero di righe gestibili. Tabelle con 50.000 o 100.000 righe funzionano con la stessa velocità di tabelle con 50 righe, perché il browser gestisce sempre e solo un piccolo sottoinsieme dei dati. L’unico requisito è che il server abbia performance ragionevoli per le query al database.<\/p>\n

\"Importazione<\/p>\n

Ottimizzare l’Importazione di Grandi Dataset<\/h2>\n

Quando importi file CSV o Excel con migliaia di righe, potresti incontrare limiti del server. Il limite di upload di PHP (upload_max_filesize<\/code>), il limite di memoria PHP (memory_limit<\/code>) e il tempo massimo di esecuzione (max_execution_time<\/code>) possono impedire l’importazione di file grandi.<\/p>\n

Per risolvere questi problemi, puoi aumentare i limiti PHP nel file php.ini<\/code> o nel file .htaccess<\/code>:<\/p>\n

upload_max_filesize = 64M\npost_max_size = 64M\nmemory_limit = 256M\nmax_execution_time = 300<\/code><\/pre>\n
Se non hai accesso a queste impostazioni, puoi suddividere il file in parti più piccole e importarle una alla volta, scegliendo l’opzione “Aggiungi” invece di “Sostituisci” per accodare i dati alla tabella esistente. Un’altra opzione è utilizzare l’importazione da URL, che non è soggetta al limite di upload ma richiede che il file sia accessibile via HTTP.<\/p>\n
Suddividere i Dati in Più Tabelle<\/h2>\n
A volte la soluzione migliore non è ottimizzare una tabella gigante, ma suddividere i dati<\/strong> in più tabelle più piccole e gestibili. Questo approccio è particolarmente efficace quando i dati possono essere naturalmente partizionati per categoria, anno, regione o altro criterio logico.<\/p>\n
Ad esempio, un catalogo prodotti con 5000 articoli può essere suddiviso in tabelle per categoria (Elettronica, Abbigliamento, Casa, ecc.), ciascuna con poche centinaia di righe. L’utente può navigare tra le categorie tramite link o tab, e ogni tabella si carica rapidamente.<\/p>\n
Puoi anche utilizzare un approccio ibrido: una tabella principale con dati riassuntivi (nome prodotto, prezzo, categoria) che funziona da indice navigabile, con link a tabelle di dettaglio per ogni categoria o prodotto. Questo simula un’esperienza di navigazione database senza richiedere funzionalità server-side.<\/p>\n
Ottimizzare il Contenuto delle Celle<\/h2>\n
Il contenuto delle celle influisce significativamente sulle performance. Ogni tag HTML aggiunge peso al DOM e rallenta il rendering. Per tabelle grandi, segui queste linee guida per minimizzare l’overhead.<\/p>\n
Evita immagini inline<\/strong> nelle tabelle grandi. Se ogni riga contiene un’immagine, una tabella con 1000 righe genererà 1000 richieste HTTP per le immagini, con un impatto devastante sui tempi di caricamento. Se le immagini sono necessarie, utilizza il lazy loading o la paginazione per caricare solo le immagini visibili.<\/p>\n
Riduci l’HTML nelle celle<\/strong> al minimo necessario. Invece di usare <span style=“color:red;font-weight:bold”>Esaurito<\/span><\/code> in ogni cella, definisci una classe CSS .stato-esaurito<\/code> e usa <span class=“stato-esaurito”>Esaurito<\/span><\/code>. La classe CSS viene definita una volta sola, mentre lo stile inline viene ripetuto per ogni cella.<\/p>\n
Evita di inserire shortcode WordPress<\/strong> all’interno delle celle di tabelle grandi. Ogni shortcode deve essere elaborato da WordPress durante il rendering, e l’elaborazione di centinaia di shortcode può rallentare significativamente il tempo di caricamento della pagina.<\/p>\n
\"Opzioni<\/p>\n
Caching e Tabelle Grandi<\/h2>\n
Il caching<\/strong> è un alleato fondamentale per le tabelle grandi. Se utilizzi un plugin di caching come WP Rocket, W3 Total Cache o LiteSpeed Cache, le pagine contenenti tabelle TablePress vengono memorizzate nella cache come qualsiasi altra pagina. Questo significa che il rendering della tabella avviene una sola volta e i visitatori successivi ricevono la versione cached, molto più rapidamente.<\/p>\n
Tuttavia, il caching ha una limitazione con il server-side processing: poiché le richieste AJAX per l’ordinamento e il filtro sono dinamiche, non possono essere memorizzate nella cache tradizionale. Assicurati che le URL AJAX di DataTables siano escluse dalla cache per evitare che gli utenti vedano dati obsoleti o errati.<\/p>\n
Un’altra opzione è il caching lato browser<\/strong>. Se i dati della tabella non cambiano frequentemente, puoi configurare header HTTP appropriati per permettere al browser di memorizzare le risorse JavaScript e CSS di DataTables, riducendo il tempo di caricamento nelle visite successive.<\/p>\n
Monitoring delle Performance<\/h2>\n
Per gestire efficacemente tabelle grandi, è importante monitorare le performance nel tempo. Utilizza strumenti come Google PageSpeed Insights<\/strong>, GTmetrix<\/strong> e il pannello Performance<\/strong> degli strumenti per sviluppatori del browser per misurare l’impatto delle tabelle sui tempi di caricamento.<\/p>\n
Presta particolare attenzione a queste metriche: il Largest Contentful Paint<\/strong> (LCP), che può essere influenzato da tabelle grandi nel viewport iniziale; il Total Blocking Time<\/strong> (TBT), che aumenta quando DataTables inizializza tabelle grandi; e il Cumulative Layout Shift<\/strong> (CLS), che può essere causato dal rendering ritardato delle tabelle.<\/p>\n
Se le metriche mostrano degradazione, applica le ottimizzazioni descritte in questa guida in ordine di impatto: prima la paginazione, poi il rendering differito, poi l’ottimizzazione del contenuto delle celle e, se necessario, il server-side processing.<\/p>\n
Limiti Tecnici e Considerazioni<\/h2>\n
Anche con tutte le ottimizzazioni, ci sono limiti tecnici da considerare. L’editor di TablePress nella dashboard di WordPress può diventare lento con tabelle che superano le 3000-5000 righe, poiché deve caricare tutte le celle nell’interfaccia di modifica. Per tabelle molto grandi, è più efficiente gestire i dati in un foglio di calcolo esterno e reimportarli periodicamente.<\/p>\n
Il database MySQL ha i propri limiti: la dimensione massima di un campo TEXT è di 65.535 byte, e TablePress salva l’intera tabella in un singolo campo. Tabelle estremamente grandi (oltre 100.000 righe) potrebbero richiedere la modifica del tipo di campo a LONGTEXT. Consulta un amministratore di sistema prima di apportare modifiche al database.<\/p>\n
\n
Leggi anche gli altri articoli della serie TablePress<\/h3>\n