Pagination, Load More or Infinite Scroll: Fast Listings

With the same number of products per section, all three patterns load the same product data on the first visit. The initial load still differs, namely in script and preloading. Pagination gets by with ordinary links, and the page works before any script has run. "Load more" needs a small script that fetches and inserts the next section. Infinite scroll additionally needs an observer at the end of the list, usually preloads the next section before anyone sees it and has to keep the address up to date. The mockup above shows this order schematically. The bigger lever, however, is the number of products per section: every tile brings an image, a price, markup and often its own scripts for wish lists or quick views.

In Shopware, the setting "Number of products per page" defines this number per sales channel. Without a value, the default of 24 products applies (Shopware source code). Through the limit parameter, at most 100 products can be requested per call (Shopware source code). 24 is a practical size because it divides by two, three, four and six: the last row is full in every common grid, and there are no half rows that stand out when more products load.

There is no single number that suits every shop. The trade-off is clear, though: fewer products per section mean less data and fewer images to render on the first load, while too few force constant paging. One workable approach is to combine "Load more" with lazy loading of product images: the section can then be larger without raising the initial load to the same degree. The field data of your own category pages shows which size works in your shop.

The weakest device sets the section size. 73 percent of online shoppers aged 16 and over in Germany shop on a smartphone (Bitkom 2025), and secondary pages perform worse on mobile in particular: only 69 percent of mobile secondary pages achieve a good INP, compared with 80 percent of home pages (HTTP Archive Web Almanac 2025). Category pages belong to these secondary pages. A fixed number per address still makes sense, even if desktop and smartphone can handle different amounts: if you want to show more on desktop, load the second section there automatically instead of changing the page size per device. That way, the same address shows the same products everywhere.

With a "Load more" button, the page stays in place and the next section is appended below. The Nielsen Norman Group sees this as a compromise: the button keeps the footer reachable, makes it clear that there is more content and helps on slow connections because less loads up front. In return, every section costs an extra click that briefly interrupts the flow (Nielsen Norman Group 2022). For search engines, the button is invisible at first: Google's crawlers do not click buttons and generally do not trigger script functions that require a user action (Google Search Central). That is why the button is, in the HTML, a link to the next section, for example ?p=2, which a script turns into a load-more button only in the browser.

For Cumulative Layout Shift, the click is an advantage. Layout shifts within 500 milliseconds of user input carry a flag and can be excluded from the calculation (web.dev). If the server takes longer, the shift counts when the new tiles push the footer down or images without dimensions slide in. For interactions that trigger a longer network request, web.dev recommends creating space right away and showing a loading indicator (web.dev). For "Load more", this means: right at the click, tile-sized placeholders appear for the whole section, and the real tiles replace them without changing the height. A good CLS is 0.1 or less (web.dev); further causes are covered in the article Avoiding Cumulative Layout Shift.

The click also counts toward Interaction to Next Paint. A good INP is 200 milliseconds or less (web.dev). The click handler therefore only sets the loading state and the placeholders and then yields the main thread. Fetching, inserting and tracking follow afterward. The insertion itself happens in one step, not tile by tile, and new tiles set up their scripts only when they are needed. How to break up long tasks is shown in the article Optimizing INP. The following example sums up the steps; the endpoint /listing/chunk stands for a route that delivers only the tiles of one section.

Two details decide whether the button also works with a keyboard and screen reader. After loading, focus moves to the first new tile; otherwise it stays on a button that has moved further down, and the new products sit unnoticed before it. And a status line with aria-live announces that new products are there. The button itself can state how many products are still to come, which Google lists as an advantage of this pattern (Google Search Central). With every click, however, the page tree grows. How to limit that is explained in the article Reducing DOM size; a simple limit is to switch to page numbers after a fixed number of sections.

Few paths in a shop are as common as list, product, back. According to Chrome usage data, 1 in 10 navigations on desktop and 1 in 5 on mobile are a back or forward navigation (web.dev). Landing at the top of the list on the way back is costly: anyone who has to find their position in a long list again loses time, and some visitors give up at this point. On mobile devices, this weighs more heavily because fewer tiles fit on one screen.

The fastest way back is the back/forward cache. It keeps the entire page, including the JavaScript heap, in memory and restores it on back navigation (web.dev), with all appended sections and the scroll position. This applies equally to all three patterns. The prerequisite is that the category page is allowed into the cache: no unload handlers, no unnecessary Cache-Control: no-store, no open connections when leaving (web.dev). How to check and establish eligibility is covered in the article on the back/forward cache.

If the cache does not apply, the browser reloads the page, and that is where an address per section proves its worth. With pagination, ?p=3 delivers the same page as before, and with history.scrollRestoration set to auto, the browser restores the scroll position itself (MDN Web Docs), provided the tiles have fixed dimensions and the height is already right at restore time. With "Load more" and infinite scroll, this basis is missing if the address stays unchanged. The address should therefore follow along on every "Load more" click, for example with history.pushState, so that the right part of the list can be loaded on the way back. The code example above uses replaceState: it keeps the address in sync just the same, but does not create a separate history entry per section.

A robust pattern for the way back without the cache looks like this: the address carries the section in which the clicked tile sits, and history.state remembers the product. On the way back, the server renders only this section, a "Load previous products" link sits above it, and a small script scrolls to the remembered tile. If you set the position yourself, turn off automatic restoration with history.scrollRestoration = "manual" (MDN Web Docs), so browser and script do not work against each other. The benefit for initial load: the way back loads one section instead of all the sections that were visible before.

The first page and a very deep page look the same, but they do not cost the database the same. The usual query with LIMIT and OFFSET does not skip the rows before it, it reads them. The MariaDB documentation works this through for a list of 50,000 items with ten items per page: for the last page, the database has to find all 50,000 rows, step over the first 49,990 and then deliver ten (MariaDB documentation). If a crawler requests all 5,000 pages, it touches about 125 million items along the way (MariaDB documentation). Depending on filtering and sorting, even the first page may require reading the whole list (MariaDB documentation).

In Shopware, counting comes on top. For the listing, Shopware requests the exact total number of hits (Shopware source code), because the pagination needs the last page number. The source code labels this mode as slow. Besides it, there is a mode that only checks whether further pages follow: it fetches at most six times the page size plus one row (Shopware source code). For "Load more" and infinite scroll, this information is enough, because the button only needs to know whether there is more. The MariaDB documentation describes the same idea for custom queries: query LIMIT 11 instead of LIMIT 10 and use the eleventh item to tell whether there is a next page (MariaDB documentation).

The basic recommendation of the MariaDB documentation is to avoid OFFSET and remember where the last page left off (MariaDB documentation). This fits "Load more" well, because the next section starts right after the last product shown anyway. Search servers have the same limit in a different form: by default, Elasticsearch pages through at most 10,000 hits with from and size, and for deeper results the documentation points to search_after (Elastic documentation). For a deep page, each shard has to load the hits of all previous pages into memory (Elastic documentation).

For running a shop, this means: serve deep pages from the HTTP cache where possible, limit the pagination to a window around the current page, as the Shopware theme does, and watch requests with high page numbers in the slow query log and the access log. How cache layers work together is explained on our page on caching strategies; how to find slow queries and speed them up with indexes is covered in the article on database query optimization.

Field data and a few targeted tests show whether the chosen pattern stays fast in practice. INP reveals how quickly a click on a page number or on "Load more" gets a response; which code slows it down is made visible by the Long Animation Frames API, described in the article on Long Animation Frames. For the rest, a short list helps:

In an analysis, we go through exactly these points for your category templates, with lab values for desktop and smartphone and, where available, field data from your category pages. The result is a recommendation for the loading pattern per template and an order of changes by impact. How we proceed is described under technical analysis. For Shopware shops, we implement the changes in the theme, from section size to the way back without the cache; more on the Shopware performance page. An overview of typical slowdowns in online shops is given on the page PageSpeed for e-commerce.