Pagination

Pagination

Technique de division des resultats en pages pour ameliorer les performances et l'experience utilisateur.

Qu'est-ce que la pagination ?

La pagination est une technique qui divise un grand ensemble de resultats en pages de taille fixe pour ameliorer les performances et l'experience utilisateur. Au lieu de charger 10 000 resultats d'un coup, on charge 20 elements par page. La pagination est presente partout : resultats de recherche Google, feeds de reseaux sociaux, listes de produits e-commerce, tables de donnees administratives.

Pagination par offset (traditionnelle)

La methode classique utilise OFFSET et LIMIT en SQL : SELECT * FROM products ORDER BY id LIMIT 20 OFFSET 40 pour la page 3. Simple a implementer et permet le saut direct a une page. Inconvenients : performance degradee sur les grandes tables (la base doit scanner toutes les lignes avant l'offset), resultats instables si des elements sont ajoutes ou supprimes entre deux pages (elements manques ou dupliques).

Pagination par curseur (keyset)

La pagination par curseur utilise la derniere valeur vue comme point de depart : SELECT * FROM products WHERE id > :last_id ORDER BY id LIMIT 20. Performante quel que soit la profondeur (utilise l'index directement), resultats stables. Le curseur est generalement encode en base64 et envoye au client. Inconvenient : pas de saut direct a une page, navigation uniquement sequentielle (precedent/suivant). Ideal pour les feeds infinis (scroll infini) et les API.

Pagination dans les API

Le pattern Relay (GraphQL) standardise la pagination par curseur avec edges (elements), pageInfo (hasPreviousPage, hasNextPage, startCursor, endCursor), et les arguments first/after et last/before. En REST, les conventions varient : Link header avec rel=next/prev, enveloppe JSON avec meta (total, page, per_page, next_cursor). Toujours inclure le nombre total d'elements (ou une indication s'il y a plus de resultats) pour l'affichage de la pagination.

Strategies pour les grandes tables

Pour les tables avec des millions de lignes, des strategies supplementaires sont necessaires. Estimated count : pg_class.reltuples dans PostgreSQL pour un comptage approximatif instantane plutot que COUNT(*) (qui parcourt toute la table). Materialized views : pre-calculer les listes paginees pour les requetes frequentes. Search engine : Elasticsearch ou Typesense pour la pagination de resultats de recherche avec facettes.

Pagination cote client

En frontend, la pagination prend differentes formes : pagination classique (boutons de page, adapte aux tables de donnees), scroll infini (chargement automatique avec IntersectionObserver, adapte aux feeds), load more (bouton "charger plus", compromis entre les deux). Le scroll infini doit gerer la performance (virtualisation des elements hors ecran), l'accessibilite (navigation clavier), et le SEO (les pages suivantes doivent avoir des URL indexables).

Besoin d'aide technique ?

Decrivez votre projet pour des conseils personnalises par nos experts.

Recevoir des conseils

Questions frequentes

Quelle methode de pagination choisir pour une API ?

Pagination par curseur pour les feeds et les grandes collections (performant, stable). Pagination par offset pour les tables de donnees avec navigation par page (simple, permet le saut). Si vous n'avez qu'une API, le curseur est generalement le meilleur choix. L'offset est acceptable pour les petites collections (moins de 100 000 elements) avec des besoins de navigation par page.

Comment paginer avec un tri sur une colonne non-unique ?

Utilisez un tri composite : ORDER BY created_at DESC, id DESC et un curseur sur les deux colonnes : WHERE (created_at, id) < (:last_date, :last_id). Cela garantit un ordre stable et unique. Sans la deuxieme colonne (id), les elements avec la meme date pourraient etre manques ou dupliques entre les pages.