Calcul d’une pagination JS
Calculez instantanément le nombre de pages, l’offset, la plage d’éléments affichés et la fenêtre de navigation idéale pour une pagination JavaScript moderne, performante et lisible.
Guide expert du calcul d’une pagination JS
Le calcul d’une pagination en JavaScript paraît simple à première vue, mais il devient rapidement stratégique dès que le volume de données augmente, que l’interface doit rester fluide et que l’expérience utilisateur exige une navigation claire. Dans la pratique, on ne se contente pas de diviser un total par un nombre d’éléments par page. Il faut aussi gérer l’offset, le bornage de la page courante, la construction de la liste des pages visibles, l’accessibilité du composant, la synchronisation avec le back-end, la stabilité des URLs et les performances de rendu. Une pagination bien conçue améliore la recherche d’information, réduit la charge cognitive et limite les ralentissements liés au rendu de longues listes.
En JavaScript, la pagination intervient dans plusieurs contextes : tableaux de données côté client, listes filtrées dans un catalogue e-commerce, résultats d’une recherche interne, composants React ou Vue, ou encore rendu vanilla JS avec une API distante. Le principe reste identique : on dispose d’un ensemble d’éléments, on choisit une taille de page, puis on calcule la page active et la portion de données à afficher. Ce calcul doit être fiable même si l’utilisateur saisit une page hors limites, si le nombre total change après un filtre, ou si la dernière page contient moins d’éléments que les pages précédentes.
La formule fondamentale d’une pagination JavaScript
Le premier calcul consiste à déterminer le nombre total de pages. On utilise la formule suivante :
const totalPages = Math.ceil(totalItems / itemsPerPage);La fonction Math.ceil() est essentielle, car elle arrondit au supérieur. Si vous avez 250 éléments avec 12 éléments par page, vous obtenez 20,83 pages théoriques, donc 21 pages réelles. Sans cet arrondi, vous perdriez la dernière page partielle.
Ensuite, on calcule l’offset, c’est-à-dire la position de départ de la tranche à afficher :
const offset = (currentPage – 1) * itemsPerPage;Avec une page courante égale à 5 et une limite de 12, l’offset est de 48. Cela signifie que l’affichage commence au 49e élément en logique humaine, mais au 48e index en logique JavaScript. C’est ici que beaucoup d’erreurs apparaissent : l’interface parle souvent en base 1 alors que les tableaux JavaScript sont indexés en base 0.
Différence entre pagination côté client et côté serveur
La pagination côté client s’appuie sur un tableau déjà chargé dans le navigateur. On utilise généralement slice(offset, offset + itemsPerPage). C’est pratique pour des volumes modestes et des interactions rapides, mais cela devient coûteux si l’on charge des milliers de lignes inutilement. La pagination côté serveur, elle, envoie au back-end la page et la limite, puis laisse la base de données ou l’API retourner uniquement la tranche utile. Pour de gros volumes, c’est presque toujours le meilleur choix.
| Approche | Volume de données | Temps de premier chargement | Consommation mémoire navigateur | Cas d’usage recommandé |
|---|---|---|---|---|
| Pagination côté client | 100 à 2 000 éléments | Très rapide si les données sont déjà présentes | Modérée à élevée selon la taille du JSON | Filtres instantanés, tableaux internes, petits catalogues |
| Pagination côté serveur | 1 000 à plusieurs millions d’éléments | Optimisé car seule une tranche est transférée | Faible | E-commerce, moteurs de recherche, dashboards volumineux |
| Pagination hybride | 500 à 50 000 éléments | Bon compromis avec cache local | Maîtrisée | Applications riches avec mise en cache et préchargement |
Comment calculer correctement les éléments affichés
Une bonne pagination ne doit pas seulement afficher une liste de pages. Elle doit aussi indiquer clairement à l’utilisateur quels éléments sont actuellement visibles. Les deux valeurs les plus utiles sont :
- Début affiché :
offset + 1en logique utilisateur - Fin affichée :
Math.min(totalItems, offset + itemsPerPage)
Dans un exemple avec 250 résultats, 12 éléments par page et une page 21, l’offset vaut 240. Le début affiché est 241 et la fin affichée est 250. La dernière page n’affiche donc que 10 éléments. Ce détail est essentiel pour le texte d’interface du type Affichage des résultats 241 à 250 sur 250.
Le calcul des boutons de page visibles
Sur des interfaces modernes, on n’affiche pas toujours toutes les pages. Si vous avez 487 pages, une liste complète serait illisible. Il faut donc calculer une fenêtre de pagination centrée autour de la page active. Le principe est le suivant :
- Définir un nombre maximum de boutons visibles, par exemple 7.
- Calculer une plage autour de la page active.
- Décaler la plage si l’on est proche du début ou de la fin.
- Conserver les bornes entre 1 et le nombre total de pages.
Exemple : si la page active est 5, le maximum visible est 7 et le total est 21, la plage visible peut être 2 à 8. Si l’utilisateur se trouve à la page 1, la plage devient 1 à 7. S’il est à la page 20, elle devient 15 à 21. Ce mécanisme rend la navigation prévisible et réduit l’encombrement visuel.
Statistiques pratiques sur les tailles de page
Dans les projets web réels, le choix d’une taille de page influence directement l’ergonomie et les performances. Une taille trop faible multiplie les clics. Une taille trop élevée surcharge la page et ralentit le rendu. Le tableau suivant synthétise des mesures courantes observées lors de tests fonctionnels sur des listes de contenu, de produits et de lignes tabulaires.
| Éléments par page | Nombre moyen de clics pour parcourir 240 éléments | Poids visuel perçu | Usage courant | Évaluation UX |
|---|---|---|---|---|
| 10 | 24 pages | Très léger | Résultats administratifs, tables denses | Excellent pour la lisibilité, plus coûteux en navigation |
| 12 | 20 pages | Léger | Grilles produits mobiles et desktop | Très bon compromis visuel |
| 20 | 12 pages | Modéré | Blogs, catalogues, fiches synthétiques | Souvent optimal pour desktop |
| 50 | 5 pages | Élevé | Exports, back-office, data grids | Efficace pour utilisateurs experts, plus lourd sur mobile |
Les erreurs les plus fréquentes en pagination JS
- Ne pas borner la page courante et accepter une page 0 ou une page supérieure au total réel.
- Oublier d’arrondir le nombre total de pages au supérieur.
- Confondre index tableau et numérotation visible par l’utilisateur.
- Ne pas recalculer la page après l’application d’un filtre qui réduit fortement le total.
- Afficher des liens de pagination non accessibles au clavier ou non annoncés correctement par les lecteurs d’écran.
- Créer une pagination sans mise à jour de l’URL, ce qui empêche le partage et nuit au référencement.
Pagination, accessibilité et expérience utilisateur
Une pagination n’est pas seulement un outil de calcul. C’est aussi un composant d’interface soumis à des exigences d’accessibilité. Les utilisateurs clavier doivent pouvoir parcourir les contrôles facilement. Les lecteurs d’écran doivent comprendre où se situe la navigation et quelle page est active. Une bonne pratique consiste à encapsuler les liens de pages dans un élément nav avec un label explicite, puis à utiliser des états clairs pour la page active. Sur mobile, il faut conserver des zones tactiles suffisamment larges et éviter un trop grand nombre de boutons comprimés.
Pour approfondir les dimensions d’accessibilité, d’ergonomie et de conception d’interface, vous pouvez consulter des ressources institutionnelles utiles comme Section508.gov, Usability.gov et Washington.edu Accessibility. Ces références aident à construire des composants plus robustes, y compris pour la pagination.
Exemple logique en JavaScript vanilla
Le schéma de calcul standard peut se résumer ainsi :
const totalPages = Math.max(1, Math.ceil(totalItems / itemsPerPage)); const currentPage = Math.min(Math.max(1, requestedPage), totalPages); const offset = (currentPage – 1) * itemsPerPage; const startItem = totalItems === 0 ? 0 : offset + 1; const endItem = Math.min(totalItems, offset + itemsPerPage); const pageItems = allItems.slice(offset, offset + itemsPerPage);Cette logique protège contre les valeurs invalides et garantit que l’interface ne casse pas. Dans un composant plus avancé, vous pouvez aussi calculer hasPrev, hasNext, prevPage et nextPage, puis générer les boutons automatiquement. Le calcul de la plage visible suit le même principe de bornage avec un startPage et un endPage.
Quand préférer l’infinite scroll à la pagination
L’infinite scroll est parfois présenté comme une alternative moderne, mais il n’est pas toujours préférable. Pour une consultation linéaire, comme un flux social, il peut fonctionner. En revanche, pour des recherches ciblées, une comparaison de résultats, un catalogue ou un back-office, la pagination garde de solides avantages. Elle donne un repère, favorise le retour à un état précis et permet d’estimer la taille du jeu de données. D’un point de vue analytique, elle simplifie aussi le suivi des comportements par page.
Bonnes pratiques de performance
- Ne rendez que la tranche utile si vous travaillez côté client.
- Préchargez la page suivante uniquement si le contexte le justifie.
- Mémorisez l’état de pagination dans l’URL ou le stockage local si l’utilisateur revient souvent à une liste.
- Évitez de recalculer toute la structure DOM lorsque seule la page change.
- Associez la pagination à un tri stable afin que les résultats restent cohérents entre deux chargements.
Conclusion
Le calcul d’une pagination JS repose sur quelques formules simples, mais leur mise en œuvre sérieuse demande une attention particulière aux bornes, à l’ergonomie, à l’accessibilité et à la performance. Si vous maîtrisez le calcul du nombre total de pages, de l’offset, de la plage d’éléments affichés et des boutons visibles, vous disposez du socle technique nécessaire pour bâtir une expérience fiable. Le calculateur ci-dessus vous permet de vérifier rapidement ces valeurs et d’obtenir une lecture opérationnelle de votre pagination avant intégration dans votre projet JavaScript, WordPress, application métier ou interface e-commerce.