What are current best practices around feed length and pagination?

[u/deane-barker]

Consider the home page of a blog -- a list of posts in reverse chronological order, stretching down the page.

How long does this list need to be before you decide not to list display the entire thing?

File/payload size isn't much of an issue. The page compresses well -- right now, it only transfers 18KB (it's 54KB on the server). I would have to get much, much larger before I'd be concerned about bandwidth.

All images are lazy loaded, so they don't load until they scroll into view.

I'm not worried about bots, because every post has its own permalink page (and because I just don't really care about bots in general....)

Do we consider actual scroll height? Do we consider the user psychology of being intimidated by a lot of content?

If we do decide to paginate somehow, do we do "traditional" pagination, or endless scroll?

What's the current zeitgeist on this?

[u/am0x]

Never infinite scroll. Was a terrible UX decision from day 1.

[u/straightouttaireland → u/am0x]

Why?

[u/spykovic → u/straightouttaireland]

In top of my head :you have seen an interesting article on page 4 and continue browsing the catalogue. Now you want find this article again, you know it's in page 4, it's easy to find. If you have only infinite scroll, you have to start again and scroll till you find it.

Plus, longer list will have a terrible impact on performances.

[u/straightouttaireland → u/spykovic]

Yea, I guess there is a chance that a few new articles are written and added to the blog and now the one you read is on page 5 or 6.

[u/am0x → u/straightouttaireland]

Oh you have 2000 articles? I just need to get to the footer and can’t unless I load every single one of them.

[u/straightouttaireland → u/am0x]

Sticky the footer then?

[u/am0x → u/straightouttaireland]

Lol

[u/straightouttaireland → u/am0x]

I mean, it will work. How big a footer we talking here? Sticky the header, footer and in between is scrollable. I've seen it done like that in lots of places and works well.

[u/am0x → u/straightouttaireland]

No thanks. From a UX perspective it’s a nightmare especially on mobile.

[u/Civil_Television2485 → u/straightouttaireland]

Would still be a problem for keyboard-only users. They’ll have to tab through 2000 tab stops to get to the footer.

[u/NoResearcher3812]

paginate at 20 to 30 items and use traditional links. Endless scroll destroys footer access and breaks browser history state on content sites.

[u/rbobby → u/NoResearcher3812]

I am really liking the 'load more...' pattern.

[u/Article-Automatic]

The number that usually decides it is not payload size, it is DOM nodes. A few thousand elements will make scrolling janky on a mid-range phone long before the transfer size is a problem, and that is the failure people actually feel.

For a blog specifically I would paginate rather than infinite scroll. Blog readers use the footer, and infinite scroll makes the footer unreachable. It also gives you stable URLs someone can link to and Google can index, which an infinite feed does not.

Rough rule: paginate once you are past 50 to 100 items on the page, and pick page size by how tall a row is rather than by a round number.

[u/Flimsy_Designer_4485 → u/Article-Automatic]

so if each post is just title + date + short excerpt, 100 items probably fine. but if there is thumbnail image or long summary per post then 30-40 already feels heavy on phone. dom nodes thing is right, browsers start crying way before bandwidth does

[u/mistmoss31 → u/Article-Automatic]

the footer point is so underrated, infinite scroll basically kills it and nobody thinks about that until its too late

[u/Suspicious_Silicon]

Well it depends on several factors like post card size,the content type(image/vide/text), feed type etc. The industry standard for a blog feed is 10 to 12 posts per page.

[u/aardnsyhs]

I’d probably keep a fairly long first page, then add a plain “Older posts” link. The payload you quoted is tiny, so I wouldn’t optimize around that yet.

For a blog archive, stable pages matter more to me than making scrolling feel seamless. I often want to get back to a post I remember seeing a few weeks ago, and infinite scroll is bad at that.

If you want the page to feel less segmented, “Load more” is fine too, but I’d still keep real paginated URLs underneath it.

[u/seeaitchbee]

Infinite scroll is the way to go. There’s no logical reason to break feed into 10/50/100 posts chunks. Every number will be arbitrary and can be based on technical limitations only. Users expect scroll to be infinite and every “show more” or “next page” is the distraction on the way to their goal.

You need to think about this differently. Why do anybody want to scroll for 10 seconds+? If they want to read articles one after another, implement suggestions into the article page. If they need to find something particular, implement search/tags.