In this article, we will explain why you need to stop building websites with infinite scroll. But to start, let's look at a brief history of scrolling.

A brief history of scrolling

To understand what scroll really is, let’s see where the term scroll comes from.

scroll (n.): c. 1400, “roll of parchment or paper”

Scrolls originally were used for when information became lengthy (like religious contents). So much content became difficult to manage, read and write.

When computers came into our lives we still needed a way to navigate through large pieces of content.

The evolution of scrolls in computers

1. Lines (and columns)In the early years of the internet, UX designers invented/explored many ways of paging/scrolling the content. Before the web was popular, we were scrolling lines on our screen.

Horizontal scrolls made scrolling a tool not only for reading the content but also a way to navigate on the computer screen.

2. Windows (not the OS one)

Using scrolls to navigate the screen encouraged people to create windows. Using windows, you would be able to view multiple pieces of content at one time.

Windows 3.1 “Program Manager” has multiple scrolls.

3. Web pages

Scrolling solves a very fundamental problem we have while browsing web pages. However, scrolling can cause many issues for users and can negatively impact the user experience. Let's take a closer look.

The experiences invented to navigate web pages

I’m going to try to define how developers and designers created experiences to navigate users in their web pages.

Let’s start by learning some back-end pagination systems:

Offset-based pagination

This is the most known pagination system. In this technique, first, we have to find how many items we have to paginate:

-- All posts count
SELECT COUNT(*) AS total FROM posts

After counting all the items, we have to calculate the pages. Let’s assume we’ll show 10 items per page:

-- First page items
SELECT * FROM posts LIMIT 10

And if we want to skip to the page 3, we need to skip first 30 items using OFFSET:

Metafizzyalso created a tool to help developers build infinite scrolls.

Infinite scrolling makes users scroll the page to the infinity.

Stop building websites with infinite scroll!

Up until this section, we have reviewed how we got here. Now let's talk about why here sucks.

Finding footer

Footer is a very basic unit of web page anatomy, just like a header. Sites keep some detailed information and links in the footer such as phone numbers, addresses, help and support links. If users are searching for this detailed information, they mostly scroll down to the find footer.

With infinite scrolls, users can have a hard time trying to find the footer. Infinite scroll makes finding the end of the page impossible. Not being able to reach the bottom of a website can make the user stressed (which is not great).

The sites with an infinite feed (like Twitter) solve the footer problem putting this required information and links in the sidebar. The sidebar is a solution to this issue, but not a good one. Footer should stay on footer.

Twitter’s footer on the right sidebar.

Do not use infinite scroll if you do not have a timeline or feed

Social media applications work with time. The users’ intention is to navigate the past. In this case, infinite scroll makes the navigation easier. Here, infinite scroll is good for performance, especially in mobile.

But if you have an e-commerce, news, magazine or a blog website and the user's intention is to move around the items or articles, infinite scroll becomes a nightmare for them. In a timeline based list, people mostly don’t look for a date or unique moment. On item based lists, the user wants to find an item. Infinite scrolls make your items almost impossible for your users to find.

Give users more control

Users generally do not like the UIs when they feel they cannot control it.

A scroll event is not very intentional to do something. People navigate the page, and if they want to call an action they mostly click or touch (known as triggers). They inform the UI about their decision. But scroll is triggered without any decision.

Infinite scrolls make the pages less controllable for the users. Users can also encounter jumping glitches.

Instead of infinite scrolling, put a “load more” button, which is a trigger. This will give control to the user. (I’d prefer old style numbered pagination but we assume we use cursor based pagination right now).

Allow users to go wherever they want

People navigate between pages, bookmark some of them, and share pages with their friends, etc.

However, infinite scrolls cannot keep the state by its design. Users cannot share their current state. Which also means you cannot track users’ actions using analytics tools.

If your back-end pagination technique is cursor-based it’s almost impossible to allow your users to go wherever. If you have an e-commerce website, give users control to navigate to the products they want.

Additionally, if you have a “sort by” functionality in your listing, you must show the user a pagination. In an alphabetically ordered list, you mustn’t force users to scroll down to products starting with K. They will go mad with this experience.

You should allow users to see where they are. Users scroll for a time and because it's a stateless design they do not know how many times the “next page” loaded. When they refresh the page, they will reset all the way back to the original page. The user will then have to scroll back down to find where they were before.

Conclusion

Infinite scrolls are nice in a few cases but they are usually not problem solvers but problem makers. UX people shouldn’t consider infinite scrolling as a silver bullet to solve their pagination issues. Stop building websites with infinite scroll.

LogRocket is a frontend logging tool that lets you replay problems as if they happened in your own browser. Instead of guessing why errors happen, or asking users for screenshots and log dumps, LogRocket lets you replay the session to quickly understand what went wrong. It works perfectly with any app, regardless of framework, and has plugins to log additional context from Redux, Vuex, and @ngrx/store.

In addition to logging Redux actions and state, LogRocket records console logs, JavaScript errors, stacktraces, network requests/responses with headers + bodies, browser metadata, and custom logs. It also instruments the DOM to record the HTML and CSS on the page, recreating pixel-perfect videos of even the most complex single page apps.