How Long Should a Blog Feed Be Before Adding Pagination?

The practical limit is usually the number and complexity of DOM nodes, not the transfer size. A simple list of titles and dates can comfortably hold many more items than a feed with thumbnails, excerpts, or embedded media. On phones, a few hundred complex cards may become sluggish even when the payload is small. For a blog, traditional pagination is usually the safest choice. It preserves stable URLs, makes browser history work predictably, lets readers reach the footer, and gives search engines crawlable archive pages. As a rough starting point, try 20–30 substantial cards, or perhaps 50–100 very lightweight entries, then test on mid-range mobile devices.

The most important issue is what happens when someone opens a post and presses Back. With an endlessly loaded feed, they may return to the top and lose their position—or the previously loaded items may disappear entirely. Numbered pages avoid that problem because page 3 remains page 3. If you prefer a “Load more” experience, keep the loaded content in the DOM and update the URL or history state as more items are added. That gives the browser a chance to restore the reader’s position while retaining the benefits of a usable archive.

Choose the page size based on how much vertical space each entry takes rather than using one universal item count. For a compact title-and-date list, two or three screens might mean roughly 30 items. For cards with images and excerpts, 10–12 posts may already be enough. I would avoid pure infinite scrolling for a blog archive. It can feel smooth, but it makes older posts harder to find, weakens navigation and history behavior, and effectively hides the footer. A longer first page followed by an “Older posts” link is a simple, durable alternative.