I'm designing a blog home page that lists posts in reverse chronological order. The current page transfers about 18 KB compressed and is 54 KB on the server, so bandwidth is not a concern yet. Images are lazy-loaded, and every post has its own permalink.
How should I decide when the list is too long? Should I focus on total scroll height, DOM and rendering performance, or whether users feel overwhelmed by the amount of content? If pagination makes sense, is traditional page-based navigation better than a "Load more" button or infinite scrolling? What approach generally works best for a blog archive?
3 Answers
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.
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.
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.
That makes sense. A title-and-date archive could probably show around 100 entries, while thumbnails and longer summaries might make 30–40 feel heavy much sooner.
A Load more button seems like a good compromise, as long as it still exposes real page URLs underneath and doesn’t make the footer impossible to reach.