So You Think You’ve Built a Good Infinite Scroll

Animated GIF showing mouse and keyboard scrolling efforts with infinite scroll on Pew Research site.
So you’re saying there’s a chance … that I’ll make it to the footer.

TL;DR (added 12 December 2020):

  1. Can the user hit “back” and return to the exact same place?
  2. Is there paging for when the JavaScript breaks?
  3. Does the page have a footer?
  4. Can a keyboard user access all other content on the page?
  5. Can you share a URL to a specific place on the page?
  6. Can a user easily jump ahead a few “pages” to quickly get to content much further down the list?
  7. Does the memory footprint of the page dramatically increase after just a couple new “pages?”
  8. Is there a way to disable automatic infinite scrolling and lean on standard paging?
  9. Have you conducted any user tests?
  10. Are you satisfying a use case that has come from research or user request?
  11. Do you have any analytics/tracking to measure success?

Now back to the original post…

Last week Derek Featherstone posted Automatic infinite scrolling and accessibility, a quick rundown of why having your page just keep going without user input to do so can be such a hassle for users. Also, don’t do it.

In the comments someone trotted out an example of his own automatic infinite scroll that he felt was effective and was developed with the user in mind. I got a bit ranty and suggested otherwise. That wasn’t as productive as it could be, partly because I was commenting on one example that other developers might feel doesn’t apply to their own efforts at similar implementations.

I think maybe this could all be made a bit easier by offering a quick checklist of what to test, expect, and review if you attempt your own version of an automatic infinite scroll. Here is my attempt at one, but please feel free to suggest others (or corrections) in the comments below.

1. Can the user hit “back” and return to the exact same place?

There’s nothing quite so infuriating as loading a few screenfuls of content, following a link, and then coming back only to find you have to reload those screenfuls of content all over again. Not only is it a waste of time, it’s a waste of bandwidth.

2. Is there paging for when the JavaScript breaks?

Everybody surfs without JavaScript while the page is loading, and that load time can be extended by network lag. In addition, broken third-party scripts can take down your own script. Can the user still get past page one if the JavaScript has fallen down?

3. Does the page have a footer?

Now you’re just being a tease. The user will never get there, so don’t lie by showing the footer and implying he or she can get there. You might as well just remove it. It’s at least honest.

4. Can a keyboard user access all other content on the page?

Unless the content that keeps updating is (or contains) the last focus-able element in the source order (the linearized version of your page), then a keyboard user (as well as screen reader users) will never be able to get to that content. Just like the footer you might as well remove it altogether.

5. Can you share a URL to a specific place on the page?

After you’ve gone a few screenfuls deep you may have found a few links of interest. Can you copy the address from the browser and email it (or even tweet it) and expect the recipient will come to exact state of the page (a few screenfuls in and with that content visible in the viewport)? Remember, an anchor is useless if it hasn’t loaded yet (or has been co-opted by your script).

6. Can a user easily jump ahead a few “pages” to quickly get to content much further down the list?

Consider a list of news. After a couple screenfuls you might glean that each screen loads a week (or a month or whatever time period). You want content from a few weeks ago (or a few time periods ago). In a traditional paged navigation you could jump ahead a few screens to more quickly get further down the timeline. If your approach doesn’t afford users this control, you’re wasting your users’ time and bandwidth.

7. Does the memory footprint of the page dramatically increase after just a couple new “pages?”

Keep your favorite memory monitoring tool open and load a few screenfuls. Then a few more. Then perhaps all. Take a look at how much memory this requires and then compare to available memory on other devices (such as smart phones). Remember that a mobile browser may reclaim memory by dumping other resources from working memory, potentially purging the rest of your site and its assets from the user’s cache, resulting in more bandwidth overhead and longer download times on subsequent pages.

8. Is there a way to disable automatic infinite scrolling and lean on standard paging?

Can the user easily disable the infinite scroll? Forget browser configuration acrobatics, instead look for a very visible single-click/tap option for the user to disable infinite scrolling and move on.

9. Have you conducted any user tests?

Before you roll this out, make sure some real users sit down in front of it. Nobody from your organization. Nobody who is an IT professional, developer, or whose paycheck depends on making you or your boss happy.

10. Are you satisfying a use case that has come from research or user request?

Did this feature request come from users, or the client? Or your boss? Or your desire to flex your scripting muscles? If you don’t have a compelling use case or feature request to add it, you may want to put your efforts toward features that truly have value, like print styles.

11. Do you have any analytics/tracking to measure success?

If you do decide to launch your perfect automatic infinite scroll feature, don’t forget to put some tracking scripts in place to determine how many screens deep your users go, and how often they click. There are other things you can measure (like if the footer ever gets clicks on that page). After all, success isn’t measured by you launching, but by whether or not it works well.

Google’s Own Recommendations

The Google Webmaster Blog has its own list of recommendations, some of which overlap with those I listed above. If you consider your Google placement to be more important than how your users feel once they get to your site, then I guess you can just pay attention to these.

  1. Before you start:
    • Chunk your infinite-scroll page content into component pages that can be accessed when JavaScript is disabled.
    • Determine how much content to include on each page.
      • Be sure that if a searcher came directly to this page, they could easily find the exact item they wanted (e.g., without lots of scrolling before locating the desired content).
      • Maintain reasonable page load time.
    • Divide content so that there’s no overlap between component pages in the series (with the exception of buffering).

  2. no alt provided by Google
    The example on the left is search-friendly, the right example isn’t — the right example would cause crawling and indexing of duplicative content.

  3. Structure URLs for infinite scroll search engine processing.
    • Each component page contains a full URL. We recommend full URLs in this situation to minimize potential for configuration error.
      • Good:
      • Good:
      • Less optimal:
      • Test that each component page (the URL) works to take anyone directly to the content and is accessible/referenceable in a browser without the same cookie or user history.
    • Any key/value URL parameters should follow these recommendations:
      • Be sure the URL shows conceptually the same content two weeks from now.
        • Avoid relative-time based URL parameters:

      • Create parameters that can surface valuable content to searchers.
        • Avoid non-searcher valuable parameters as the primary method to access content:

  4. Configure pagination with each component page containing rel=next and rel=prev values in the <head>. Pagination values in the <body> will be ignored for Google indexing purposes because they could be created with user-generated content (not intended by the webmaster).

  5. Implement replaceState/pushState on the infinite scroll page. (The decision to use one or both is up to you and your site’s user behavior). That said, we recommend including pushState (by itself, or in conjunction with replaceState) for the following:
    • Any user action that resembles a click or actively turning a page.
    • To provide users with the ability to serially backup through the most recently paginated content.

  6. Test!

Update: July 14, 2014

Update: November 11, 2014

I left this list as a comment on the SitePoint article The UX of Infinite Scroll: The Good, the Bad, and the Maybe. Mostly because there is no good. There is only bad.

Update: February 13, 2015

Another post that proclaims the benefits of infinite scroll, with nothing at all to back them up: Infinite Scrolling: Pros and Cons It does list some issues, but it’s a woefully short list.

Update: December 13, 2015

Web Designer Depot has gotten on board with criticizing infinite scroll in the post How infinite scrolling breaks UX.

Update: March 4, 2016

Baymard Institute has a post at Smashing Magazine, Infinite Scrolling, Pagination Or “Load More” Buttons? Usability Findings In eCommerce, that is worth a read to see what conclusions they’ve come to from some real-world tests.

Update: May 9, 2016

I stumbled upon a post at Medium (ok, some company’s blog that is housed at Medium) that claims to take a look at infinite scroll from the perspective of UX: UX: Infinite Scrolling vs. Pagination

It lists some pros and cons for each, but when its pros aren’t well grounded and its cons completely fail to even reference accessibility issues, I am pretty quick to dismiss the entire piece. I did, of course, leave a comment (in what has to be the most confounding commenting interface I’ve seen in a while).

Update: September 7, 2018

The ARIA Authoring Practices aims to be a single-stop resource for developers who want to build common patterns in an accessible way. You can find patterns for accordions, tab controls, and even an infinite scroll (as a feed).

To further reinforce how hard it is to do an infinite scroll correctly, the example feed contains a big problem — it puts a control after the feed, meaning a keyboard user can never get to it.

I discovered this when I referenced it for a client and then went to confirm its example was good (I have raised issues in the past with some of them). I promptly filed an issue.

As always, if you think you have a good example or are building a pattern library, be sure to test.

Update: March 22, 2019

You can probably ignore item #3 in Google’s list above. Google will start ignoring rel/prev for SEO.

Update: October 2, 2019

I filed a pull request to fix the broken APG feed example since it has sat for over a year. With the APG, perfect is the enemy of good.

As noted on the documentation page, this example is an early draft that still needs work.

The design of the display page is not complete. It needs content both before and after the feed to illustrate how to nest feeds in a page.

There is a keyboard feature for moving past the feed. On this example, it is ctrl+end. See the example documentation page. One problem, of course, is that there is nothing present in the experience that helps the user know that.

Update: March 12, 2020

This post was referenced in a research paper, A usability evaluation of Web user interface scrolling types. The abstract:

This paper details a usability evaluation of scrolling techniques on Web sites. The scrolling methods evaluated were normal scrolling (with default pagination), infinite scrolling, infinite scrolling with a load more button and infinite scrolling with pagination. The four scrolling types were evaluated in the context of tasks that involved either serendipitous type tasks or goal-oriented type tasks. The evaluation was principally about the ‘raw’ performance and participant perceptions. This is because it was felt that the greatest gap in knowledge concerned these aspects. The evaluation was done by means of an experiment and the data collected was statistically analysed. The results were mixed in nature, where no single scrolling method stood out as being the most usable.

Sushil Sharma and Dr. Pietro Murano

The nice thing is that the research validates the stuff I say above, six years after I wrote it.

Update: March 12, 2020

This post was referenced (not linked) and I was quoted (along with a couple others) in Infinite Scroll: What Is It Good For?. It borrows a few of my tips above.

Update: June 17, 2022

At Hamburger Footer: Reaching the Bottom of Infinite Scroll the author suggests something novel. Putting the footer links in the header is one way to address a user never being able to reach the footer. It does not, of course, address a user deep into a page who wants to get to the header. Still, interesting approach that does not solve the infinite scroll problem, but at least looks at it a bit differently.

Update: April 5, 2024

Back in 2022 I was interviewed by Built In for the post Infinite Scroll Advantages and Disadvantages: When to Use It and When to Avoid It. They never linked to this site, so I didn’t feel it necessary to link to them. But I just stumbled across the article and figured I could link to them with the rel="nofollow noreferrer" attribute. Which I have no done.




In response to joeclark. Reply

Hi, Joe, long time no chat!

I opted not to use a list at all because with the amount of content I figured headings were an appropriate fit (though I did consider an opening list with anchor links to each heading). Ate you suggesting I wrap the entire post in an OL and put headings/content in each LI?


Ugh, it's Joe Clark. Joe Clark, everybody.


Nice article. You should take a look at infinite scroll at our RSS reader – It has various keyboard shorcuts implemented…

In response to Radenko Zec. Reply


It's an app. Keyboard shortcuts or not, are you suggesting it honors all the rules I outline above, or is this just spam? I'll ask on Twitter before I delete this.

In response to Radenko Zec. Reply

Hi Adrian.
I wanted to point out that you should look at our implementation. I think it covers lot of from your checklist.
It is not spam.

In response to Radenko Zec. Reply

At your prompting I signed up and tried it out.

1. The back button doesn't apply as all links open in a new window, so kudos for bypassing that one.

2. The page doesn't render without JavaScript (even after enabling JavaScript just to log in), so it fails #2.

3. There is no footer, so you PASS #3.

4. As I tab through the page, partway into a second post my keyboard focus jumps back to the first post. Consistently (Chrome 35 Win). It fails #4.

5. I cannot share a URL, though that point may not apply as this is a page behind a login.

6. I cannot jump ahead a few screenfuls, so it fails #6.

7. I only loaded about 20 items, but the memory did increase and will do so even more for longer blog entries. I say it fails #7.

8. I see no option to disable the auto infinite scroll. It fails #8.

9. Have you conducted user tests?

10. Was this feature driven by a clear need or request?

11. Are you measuring (not just tracking) how well this works for users?

Out of 11 items, it passes only 1. Your example fails 5, doesn't apply to 2 more, and the remaining 3 only you know the answer.

I don't consider a ~50% failure rate (or ~10% pass rate) something that covers "a lot" from my checklist.

I'm not sure why you posted it. It's a pretty quick process for you to check it and you have to see it doesn't pass any more than one item, Four items (out of eleven) if you can make a case for your user testing.


Back in Feb Google posted some advice to make infinite scroll mode search engine friendly.

In response to Jonathan Worent. Reply

Forgot about that, thanks for posting it. Note that Google has its own checklist of items just to make your infinite scroll indexable. Add those 6 to my 11 above, and you've now got 17 items to check.


IMHO I would offer an “unload first shown items” button. This way you could also manage the dynamic range of items you would like to show via the following URL parameters: first-item, last-item.

This way you can save memory (if the user unloads items, manually or automatically after scrolling) without forcing a paginated list.

Think for example that the user wants to list items 3 to 7 of a list with 8 items. With a paginated list I think it is not possible, even allowing him to choose the amount of items that can be shown in each page.

Replacestate would be the last ingredient. Pushstate is not interesting, because the list has not a unique sorting criteria, the user can choose it.

In response to ant. Reply

I appreciate that you are thinking about solutions in the context of the JavaScript-driven infinite scroll. The particular issue you cite can be addressed without all the client-side scripting, however. Allowing users to choose how many items per page can let users see groupings that might span pages in a paginated view, all without the script hassle. Both client-side and server-side will suffer from not being able to show only a very specific range without additional user interface elements.

aroselli; . Permalink

feedly (RSS reader) executed infinity scroll the right way.

In response to Ran. Reply

By “the right way,” do you mean in your opinion or in mine? My opinion is clearly laid out above, and while I do not have a Feedly account, a few minutes on the marketing site does not give me high hopes it does a good job of infinite scroll.


[…] (inspiré entre autres de Adrian Roselli, So you think you built a good infinite scroll). […]


[…] (inspiré entre autres d’Adrien Roselli). […]

Scroll, baby, scroll ? – ANEXFI – NEWS; . Permalink

I am happy to see someone actively criticising infinite scrolling and offering a checklist for implementation.

I have hated infinite scrolling since its invention some 5 or 6 years ago. Can’t find anything useful in it at all.
Nowadays I avoid sites which implemented infinite scrolling.

A good read why it usually is a bad idea is the NN article from 2014 on its usability issues:

Alf; . Permalink

Adrian ARIA introduced role=feed. What are your thoughts on infinite scroll now. Is it still bad?

In response to Raghavendra Satish Peri. Reply

Yes. It is still bad. Not only does role=feed not address any of the issues I raise in my post, user agent support is still poor and even the ARIA Authoring Practices 1.1 does not have consensus on how to implement it.

Even if it is made truly accessible, it will still be unusable for all the reasons in this post.


Hi Adrian, I read your article as a reminder of a couple of good practices in terms of infinite scrolls. Just wanted to point out that the link from LevelAccess seems to not be working anymore.

Annick Primard; . Permalink
In response to Annick Primard. Reply

Thanks for the heads up. I tweeted Level Access to let them know their redirects are broken.

Leave a Comment or Response

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>