Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Infinite Scrolling, Pagination Or “Load More” Buttons? Usability Findings In eCommerce

What is the best UX pattern to display products on an e-commerce website: pagination, a “Load more” button or infinite scrolling? At Baymard Institute, we’ve conducted several year-long large-scale usability studies of more than 50+ leading e-commerce websites. We tested (among other things) these three design patterns for loading products, both on desktop and mobile.

Further reading on Smashing: Link

Pagination is still the most popular way to load new items on a website because it ships by default in almost every single e-commerce platform. However, our usability test sessions found “Load more” buttons combined with lazy-loading6 to be a superior implementation, resulting in a more seamless user experience. We found that infinite scrolling can be downright harmful to usability — in particular, for search results and on mobile. However, it’s not black and white, because the performance of each method varies according to the context of the page.

In this article, we’ll present Baymard Institute’s usability research findings for both “Load more” buttons, infinite scrolling and pagination, including for both mobile and desktop. We’ll see how search results need to be implemented differently from category navigation, along with several pitfalls with implementation and examples from leading e-commerce websites.

The Test Findings Link

Throughout our large-scale usability study of e-commerce product lists and filtering7, numerous test subjects explicitly complained about pagination. Test subjects generally perceived pagination to be slow, and the presence of more than a handful of pagination links would often discourage them from browsing the product list. More importantly, test subjects were observed to browse much less of the total product list than on websites that rely on “Load more” buttons or infinite scrolling. On the upside, they spent relatively more time on the first page of results.

Many subjects used the number of pagination links, seen here on Macy’s9, to gauge the total number of results. While pagination links offer more control for jumping to a particular set of results, very few subjects actually used these during testing. Instead, they almost exclusively used the “Next” and “Previous” buttons. (View large version10)

With infinite scrolling11, sometimes referred to endless scrolling, the user largely experiences the page as if all products are loaded at once (regardless of whether they actually see all of the products), but without the performance penalty of potentially hundreds of products loading. Therefore, when infinite scrolling is implemented well, it can make for an incredibly smooth and seamless experience. The user can just scroll the list of products without any interruption. No interaction is needed — products simply appear as the user scrolls down the page. It should come as no surprise, then, that subjects browsed vastly more products on websites with infinite scrolling than on websites with either pagination or “Load more” buttons. However, initial results received relatively less exposure. Infinite scrolling is, therefore, ideal for quickly showing the breadth of an entire category; but because users aren’t naturally halted when scrolling, they tend to scan more and focus less on individual products on the list.

infinite scrolling12
Notice the length of the scrollbar. On websites with infinite scrolling, test subjects often browsed a hundred or more products, which they virtually never did on websites with pagination and only rarely did on websites with “Load more” buttons. While this proved efficient for the first 50 to 150 products, some subjects would just continue scrolling a list without really focusing on individual products if the list didn’t stop, turning the initial benefit of infinite scrolling into a liability. (View large version13)

Infinite scrolling also impedes the user’s access to the website’s footer in some cases. This is one of the major design challenges of infinite scrolling: Because results continually load as the user approaches the bottom of the list, the user will see the footer for a second or two until the next set of results is loaded and suddenly inserted, pushing the footer out of view. If many items are in the list (which is often the case with search and high-level categories), this effectively prevents the user from ever reaching the footer. This can be highly problematic because the footer often holds links to vital help pages, cross-navigation, inspirational category content, and information about customer support, shipping, and returns.

Only a few of the websites tested used a “Load more” button, but they were well received by subjects. In fact, when benchmarking14 the top 50 US e-commerce websites, we found only 8% use the “Load more” approach. “Load more” is a very simple design that doesn’t burden the user with having to figure out which page to go to, but rather simply asks, “Do you want to see more results?” This makes for a very simple interface and probably the smallest cognitive load possible for on-demand loading of additional items. Subjects generally browsed more products on websites with a “Load more” button than on those with pagination links, but because loading additional products still required an active choice and click, subjects did tend to read the displayed items much more closely than on websites with infinite scrolling.

urban outfitters15
On websites with “Load more” buttons, like American Eagle Outfitters16, users explored more products than on websites with pagination, but they didn’t quickly scan as they did with infinite scrolling. Furthermore, product exploration was observed to be significantly easier because users were able to inject additional products into the current list. (View large version17)
urban outfitters18
Urban Outfitters (View large version19)

One of the benefits of the “Load more” and infinite scrolling implementations is that the product list grows, instead of results being replaced. “Load more” allows the user to compare more easily products across an entire list. Having one consolidated list of goods made it significantly easier for users to evaluate which products would be the best to navigate to and, consequently, increased the overall product discoverability rate.

So, which loading method should you use? Ideally, you should use multiple variations of “Load more,” as it turns out. Testing showed that no single method was perfect in all instances; different contexts warranted one of three different implementations of the “Load more” approach. We’ll cover these three variations for the remainder of this article:

  • For categories, use a combination of “Load more” and lazy-loading.
  • For search, use the “Load more” button, ideally with a dynamic number of results returned based on relevancy scores.
  • On mobile, use the “Load more” button, but loading a lower number of products by default.

Note: These findings are from testing e-commerce websites. Performance might vary on other types of websites.

“Load More” For Categories Link

In our large-scale usability study on e-commerce home page and category navigation20, we found the optimal solution for loading new products in categories to lie at the intersection of the “Load more” button and infinite scrolling in the form of lazy-loading: Show 10 to 30 products on initial page load, and then lazy-load another 10 to 30 products, until you reach 50 to 100 products, and then display a “Load more” button; once that button is clicked, load another 10 to 30 products, and resume lazy-loading until the next 50 to 100 products have loaded, at which point show the “Load more” button once again. The “Load more” button threshold of 50 to 100 items determines when to interrupt the user, while the lazy-loading threshold is merely a performance optimization to reduce loading time and server load.

Note that the number of products to load is purposely a range here. Testing shows that the ideal number will depend on your website’s context and industry. For lists with more spec-driven products (most consumer electronics, hardware, parts and supplies), use the lower range. In contrast, testing showed that users can deal with a higher number of items when the list contains more visual products (apparel, furniture, decor, etc.)

(For lazy-loading, a heap of code and plugins is available as a point of departure, just two of which are Mika Tuupola’s Lazy Load21 for jQuery and LazyLoad XT22.)

Crutchfield24 implements a “Load more” button in conjunction with lazy-loading. First, 20 products load by default; once users scroll to the 10th product, Crutchfield lazy-loads an additional 20 products. After the 40th product, the user is presented with a “Load more” button. (View large version25)

This way, pages load quickly because very few products are loaded initially. More importantly, for small and medium-sized categories, lazy-loading will let the user browse the breadth of products without interruption. In effect, it will be as though “View all” is enabled for most well-defined categories — in particular, when filters are applied. For longer lists, the user will be met with a “Load more” button, which makes it very easy to continue viewing more products if the user wishes to do so, but provides a healthy break from scrolling, giving the user to easy access to the footer and giving them a moment to consider whether applying filters would be better than continuing to scroll hundreds of products.

One of the weaknesses of lazy-loading, and infinite scrolling in particular, is that the page’s height continually lengthens; if the user drags the scroll bar to the bottom, they will reach the footer and see it for a second or two as the next items load. The new items will then be appended to the list, and the footer will be pushed down and the scroll bar extended. During testing, this resulted in a jagged page experience. With the “Load more” combination, this is largely resolved because a break comes after just a jump or two. However, if you’re looking to perfect your implementation, consider “faking” the height of the page by multiplying the height of a list item by the number of rows until the next “Load more” button — even if those product rows haven’t loaded yet. This faux page height will give the scroll bar the appropriate space from the beginning and, therefore, is a more accurate representation of the actual height of the list. It also gives the user access to the footer without any jumps whatsoever. And lazy-loading will continue to load products as before — only now they are taking up the empty space instead of extending the page.

“Load More” For Search Results Link

Due to the open-ended-ness of search, it tends to have far more results than category browsing. In our usability study on e-commerce search26, hundreds of search results were not an uncommon sight, and on mass merchant websites, search queries often return thousands of results.

Furthermore, with search, results are sorted by relevance. So, the fifth result is typically a lot more relevant to the user than the hundredth result. This means users shouldn’t have to scan upwards of a hundred products when searching — rather, they should be encouraged to examine the first items carefully. Search results should, therefore, load only 25 to 75 products by default, and infinite scrolling should never be used for the search results. (Interestingly, Etsy’s famous A/B split test of infinite scrolling also documented27 a significant hit to the search experience.) Pagination or a “Load more” button would be better for search results, then, because they don’t encourage quick scanning of a large number of products, but instead nudge the user to focus more on exploring the first set of results. Indeed, because of the fewer results, lazy-loading isn’t a requirement (but, if implemented for category navigation, may just as well be reused here).

With “Load more,” seen here on L.L. Bean29, users get a natural break because the relevance of results decreases (unlike infinite scrolling), but they still have the option to compare the first set of results to the second (unlike with pagination). (View large version30)

To take things to the next level, the threshold for how many products are loaded by default may be dynamically adjusted based on the relevancy scores of search results. Most search engines will rank each result with a relevancy score and return those with the highest relevance first. These scores can be used to determine a dynamic threshold that increases or decreases the number of products loaded according to whether the user should be encouraged to scan only the first few results or browse a wider breadth of items.

In practice, this can be done by detecting sudden drops in relevancy scores for the user’s search results and, based on these drops, determining an optimal number of the outcome to be returned for that particular search query. For example, if relevancy scores begin to drop steeply after the first 28 results, then the number of products loaded can be lowered to increase focus on those items. However, if the first 100 results all have very high relevancy scores, then the number of products loaded may be increased to encourage broader exploration.

“Load More” Buttons For Mobile Link

mobile toysrus31
Pagination links are often difficult to hit because they are placed close together. Additionally, mobile users are averse to waiting for page reloads and prefer to avoid pagination. (View large version32)
mobile endless scrolling33
Infinite scrolling for long product lists can make the footer inaccessible as new results are continually loaded in, constantly pushing down the footer. (View large version34)

In our year-long study of mobile e-commerce35, we found that pagination links can be tough to tap accurately and will typically result in a new page load. Meanwhile, infinite scrolling proved very effective at getting subjects to explore many products (in fact, test subjects scrolled through more than twice as many products on test websites with infinite scrolling as they did on those with pagination). However, as mentioned, it can make the footer inaccessible. During mobile testing, it rendered vital mobile footer links — such as “Desktop site,” “FAQ” and “Shipping,” general cross-navigation, and similar elements — inaccessible to the test subjects, who all had clear expectations of these links being available in the footer.

lowes mobile36
A “Load more results” button, as used on Lowe’s37, offers many of the benefits of infinite scrolling while keeping the footer accessible. (View large version38)

The best solution, therefore, is to have a single large “Load more” button at the end of the product list. However, mobile come with some unique constraints:

  • Less screen real-estate
    Because a mobile screen is much smaller, list items will take up a relatively largely portion of the screen, with typically only two to three items being displayed in the list-view layout. Therefore, 50 items would take up many more viewport heights on a mobile device than on a desktop computer. In other words, the user will have to interact (i.e. scroll) a lot more on a mobile device than for a comparable product list on the desktop.
  • Scrolling constraints
    On a touch device, the user can usually scroll only by dragging and swiping with their finger. Contrast this with a desktop, where the user typically has numerous inputs for scrolling, such as the mouse’s scroll wheel (or a trackpad swipe), a draggable UI scrollbar, and various keyboard inputs (the up and down arrows, the page up and down keys, the spacebar, etc.).
  • Slow scrolling
    Furthermore, in our tests, subjects demonstrated less control over continuous product-list scrolling. On the one hand, some would scroll too slowly by having to continually drag their finger across the screen; in this case, a list of even 50 products would take a long time to browse. On the other hand, some would scroll the list too fast because they would inadvertently invoke momentum scrolling by swiping in rapid succession; in this case, they would miss out on a lot of products whizzing by them.
  • JavaScript events
    Finally, the way JavaScript events are fired on most touch devices means that the dynamic lazy-loading technique often can’t be implemented as well. JavaScript events fire only once the user’s scrolling ends; therefore, products can’t be fetched while the user is scrolling, only once scrolling stops.

For these reasons, we’d recommend loading only 15 to 30 products on mobile devices before showing the “Load more” button, and then simply loading them all at once (not lazy-loading).

Key Detail: Back Button Support Through history.pushState Link

In our seven years of usability testing, we’ve consistently observed how the technical implementation of loading a new page and the user’s expectation of a new page loading don’t always align on e-commerce websites. Dynamically loading content such as overlays, accordions, filters and AJAX-loaded products will often subvert the user’s expectation of how their back button works. (See our full research findings on the user’s back-button expectations39.)

The “Load more” method requires careful consideration of back-button behavior. It’s critical that after a user has visited a particular product page from the product list, they are taken back to the same spot on that list upon clicking the browser’s back button. Of the e-commerce websites we benchmarked that have the “Load more” button, over 90% get this wrong. This necessarily impedes the user’s from jumping back and forth between the product list and product pages using the same browser tab — a severe navigational limitation.

Skechers actively addresses the back-button issue by rewriting the URL each time a user clicks the “Load more” button. Consequently, when a user clicks to go back from a product page, they are taken to the correct position in the product list. (View large version41)
Skechers (View large version43)
Skechers (View large version44)

HTML5’s History API allows us to honor the user’s expectation. Specifically, the history.pushState() function enables us to invoke a URL change without reloading the page, thus matching the browser’s back-button behavior to the user’s expectation. The browser will remember the user’s scroll position, but we need to ensure that any “Load more” clicks are loaded by default when the user goes back.

Note that if you don’t have the technical resources to support proper back-button behavior, we recommend not experimenting with “Load more” at all, but rather sticking with the inferior pagination model.

“Load More” Shouldn’t Be Your Top Priority Link

While the debate over “Load more” versus infinite scrolling versus pagination has been debated for years, the product loading method shouldn’t be the first thing that most e-commerce vendors spend their development resources on.

Over the last seven years, we’ve documented plenty of severe UX issues on the vast majority of e-commerce websites. A selection of these issues have been explored in our past articles here on Smashing Magazine, including those on e-commerce search45, category navigation46, filtering47, checkout48 and the mobile experience49. Many of these issues, which are just as impactful, require significantly less design and technical resources to address than developing a solid “Load more” implementation.

That’s not to say the loading method is not critical. It is, and we observed during testing that it can change product exploration significantly. It just shouldn’t be at the top of the list of changes for most websites that still have plenty of low-hanging fruit that promise a better return on investment. “Load more” is thus reserved for those websites striving for UX perfection.

“Load More” Vs. Infinite Scrolling Vs. Pagination Link

In short, in our usability testing, the “Load more” button solved the usability issues observed with pagination (whereby users explored less of a product list, and comparison of products across pages of results was difficult), and it solved the severe issues observed with infinite scrolling (whereby users superficially scanned products and were often unable to reach the footer).

However, “Load more” buttons perform better only when the issue with the browser’s back button is dealt with — for example, through history.pushState() — and, ideally, when the implementation is adjusted based on the user’s context. In particular, the following three contextual adjustments were observed to be key to performance:

  • For category navigation, use a combination of the “Load more” button and lazy-loading. Set the threshold for the “Load more” button to 50 to 100 items.
  • For search results, use the “Load more” button, but set the threshold to 25 to 75 results only. Ideally, you would dynamically adjust the threshold for each unique list of search results based on any drops in the relevancy scores for the results.
  • On mobile, use the “Load more” button but set the threshold to 15 to 30 products because of scrolling and screen size issues. Furthermore, because of how JavaScript events fire and the lower threshold, load all products at once, instead of lazy-loading.

You can find all 93 test findings on product list usability in our (not publicly available) report “Product Lists and Filtering50.”


Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
  41. 41
  42. 42
  43. 43
  44. 44
  45. 45
  46. 46
  47. 47
  48. 48
  49. 49
  50. 50

↑ Back to top Tweet itShare on Facebook

Christian Holst is the co-founder of Baymard Institute where he writes bi-weekly articles with their research findings on web usability and e-commerce optimization. He's also the author of the E-Commerce Checkout Usability and Mobile E-Commerce Usability research reports.

  1. 1

    Implementing a Load More button or full infitinte scrolling, without impacting SEO is easy with Infinite AJAX Scroll (

  2. 2

    I always open links on an infinite scroll page in new tab, through fear of losing my place, though I know not many people will do this and get frustrated. Are there any good frameworks that take care of this?

    Another irritation includes not being able to instantly jump to the end of the content (although Discourse does this nicely, and is even bound to the button)

    The Instagram website has a nice mix where you press Load More and everything after that is an infinite scroll.

    • 3

      Will, I share your habit. Most of the time infinite scrolling looks cool but is a pain for ordering multiple products from the same list.
      My field studies – by watching my wife getting angry with ecommerce websites – show that customers get frustated quite fast by not having a proper “back to list” functionality. In some cases when you go back to an extremely long list it takes ages to reload.

      • 4

        Christian Holst, Baymard Institute

        March 1, 2016 2:35 pm

        The History Push State technique is of course equally applicable to infinite scrolling implementations:

      • 5

        Exactly my thought – while browsing for a product, I am already willing to take a higher cognitive load, because its my own money on the line if I make a wrong decision. So, I do a lot of bookmarking and/or shortlisting if the website offers it (this is solely so that I dont “lose” track of the item) and get back to all/some of them before making the final decision – even if I dont bookmark, I am willing to remember the page no. or product name so that I can exactly get back to it easily rather than being lost in the sea of product again.

        If the website instead used that semi-infinite scrolling (“load more”) approach, I fear that the url pagination (in the huge list) part will often be broken as its hard to do it right and I will totally get lost in the product sea and might lose track of products. Also to repeat the “own money” part, I think that the load more approach might be more suited for casual browsing when you are just aimlessly looking at products to see if something attracts your eyes and at that time, we really dont like higher cognitive load – but I also suspect that this will promote the casual mindset and will lead to lower sales – maybe because the test users were not operating under real-life situation where you have a product and budget in mind, they preferred the casual browsing approach.

    • 6

      Hi Will,

      Yes absolutely I share the same habit, and my clients are interpret this likewise; it’s not just about SEO points here, it’s that you’re putting your customers in the wrong state of mind. Absolutely, you will be frustrating many a customer by having them ‘lose’ their ‘place’ every time they return to search results from clicking a product.

      It’s a GREAT topic and an important article, though and the discussion is all good!

  3. 7

    It interesting which method can increase sales ?
    not just products views

    • 8

      I was thinking the same through the whole article—who cares if people browse more if they wind up purchasing less? That’s a fail for both the business and the user, since neither of them have accomplished their objectives.

      It seems like there’s a good chance this is the case, too, since plenty of test data shows that too many options lowers conversions.

  4. 9

    Stomme poes

    March 1, 2016 3:57 pm

    Also curious along Dimitru’s question– users *saw* more products, but did they *interact* more?

    On pages that lazy load or even with a load-more button, I am usually not willing to actually click anything, because I will lose my place. Also if I saw something earlier on the list, and return to the list and it starts all over again (a la Twitter), my browser search doesn’t work anymore.

    For lazy-load of products, I still want the text of the products loaded (so I can search them) but lazy-loading the *images* often makes sense– those are the slow loaders and byte munchers. The text, not so much.

  5. 10

    With the concepts of mobile first framework based development and with the likes of twitter bootstrap framework, I think infinite scrolling has a major issue on mobile view when used with bootstrap. I used it on my site but had to revert.

  6. 11

    “Never Ending Scrolling”

    “Call my name… Bastian, Please!”

  7. 12

    Peter Tellenbach

    March 1, 2016 11:24 pm

    It’s critical that after a user has visited a particular product page from the product list, they are taken back to the same spot on that list upon clicking the browser’s back button.

    Format this sentence in red and extra bold!

    I absolutely hate it if I can’t use the back button because I will loose my position in the list. On a site like this, I only click a detail link if it seems really very important to me…

  8. 13

    For e-commerce, forcing the user to take action to see more results might be better, but when it comes to searching the Web, so-called “infinite” scrolling is superior. By default, Google loads 10 (10!) results, which is not nearly enough, then requires me to press the little Next button in the corner. One search engine that gets it right is DuckDuckGo. It has infinite scrolling, but it also splits these results up into sections (pages) with a line divider and a page number after each one. I have never had any problems with losing the place.

  9. 14


    March 2, 2016 2:56 am

    Amazingly said!
    “One of the benefits of the “Load more” and infinite scrolling implementations is that the product list grows, instead of results being replaced”

    Load more button should be the magic button that solves all problems. Perfect time for me to read that post!


  10. 15

    The article defines how load more button solves the page load issues along with product display usability. Thanks for sharing your insights. Important article to be bookmarked

  11. 16

    Have anyone thought that “Load more” can be actually combined with pagination? And you can take it even further and add “Number of items to display” as well

    • 17

      I was thinking this myself – this gives the user additional context!

    • 18

      Seems to depend on the purpose of the app and the medium of the user. Are you browsing hundreds of items on your “celephone” while you wait at the dentist on a slow connection?… or do you want a blue jacket, size large, under 200 that can be shipped express in the final minutes of your lunch break from your PC?

      It’s not really about what we want the user to do, its about what the user wants to do. If you can understand this from your user’s goals and align your model to fit theirs, the content chunking/delivery solution will be more obvious.

      ….Of course user testing is more cost-effective in the long run, than worrying about what other e-commerce sites are up to. I remember when old Jake Nielsen actually said you should not use red text, in some test it did badly… Only some years later I was amazed at the amount of red text he used and the additional studies he did that flipped the best practice.

  12. 19

    پنل اس ام اس

    March 2, 2016 1:17 pm

    great post thank you for share

  13. 20

    Kirsten Miller

    March 3, 2016 4:40 am does a nice job of Load More combined with context about how many total items exist and how many have been loaded so far. See and scroll down to the bottom.

    • 21

      Lubos Kmetko

      March 9, 2016 5:01 pm

      Thanks for sharing this, that’s a really nice implementation. What I don’t like about the infinite scrolling is that I don’t know where it ends. However, they also don’t have the back button ideally implemented, it jumps back to the ‘page’ but not to the exact position.

      • 22

        The lack of correct back placement completely negates whatever additional usability this implementation provides. I would go so far as to say it’s completely broken. It’s such an important point.

  14. 23

    Joseph Higgins

    March 3, 2016 5:18 am

    Honestly, I think has the best infinite scroll implementation.

  15. 24

    Great article!

  16. 25

    I really, really dislike infinitesimal scrolling. I get anxious from it. I woumd prefer paginstion, IF the numbers gave a preview of the content, like in encyclopedias. Vol. 1, AAA – CCC.

    The issue with inf scrolling, for me, is Fear Of Missing Out. I need to go from start to finish, to get än overview, opening interesting products in a new tab.

    My preferred method is to get everything dumped on one page. If there are a thousand products, i want a thousand products on my screen.

    Added benefit of not having a kying scrollbar.

  17. 26


    March 3, 2016 1:43 pm

    There should be a “load more” for these monstrously long but fascinating Baymard usability articles………..

  18. 27

    Nice article, but I’m a bit surprised that the performance hit of having too many element on the same page is not even considered at all. At some point when loading more and more results (be it with infinite scrolling or a load more button), you will eventually end up with a slow app that is a bad experience for the user.

  19. 28

    I know personally I prefer an infinite scrolling. I will skip over products but if the company does a good job of catching my eye with a good image then I will scroll back carefully. I don’t want to click multiple times to find something that I’m looking for, even if I’m just “window shopping”, so to say.

    Also as a note, the image labeled as Urban Outfitters is incorrectly labeled and should actually be American Eagle outfitters.

  20. 29

    I don’t see how anyone could come to the conclusion that “‘Load more’ allows the user to compare more easily products across an entire list.” This doesn’t make any sense at all, especially in the context of mobile. If I want to compare a product at the top of page 1 to a product at the bottom of page 4, isn’t that a lot of scrolling? How is that good usability?

    As a user, I never want “load more” or infinite scrolling. Even if you “fix” the implementation by modifying the History state so that my back button still works properly, there is still the problem of having too many elements in memory/on the page causing a significant performance problem.

  21. 30

    Interestingly, I can’t see where to comment unless I scroll to the end of ALL comments! #uxfail

    IMHO people don’t use pagination some of the time because of poor design/ implementation of pagination. As shown in the example screen in the article, pagination is usually an afterthought implemented by UI developers. Witness the forcing of users to target a single digit to go the a page, incredibly frustrating. Most people, incl. myself, abandon such pages really fast and move on.

  22. 31

    Lauri Kieksi

    March 6, 2016 10:35 am

    These studies are interesting, and without fail focus on essential usability concerns, but also (I suppose tellingly) omit or obfuscate the study size. Yeah, this is qualitative research, so the number of test subjects isn’t as relevant as long as it was more than, like, four. But what kind of user profiles did they represent? Were all the users who participated the same for every website that you tested?

    Also, when you say “8 % of top 50 US e-commerce websites”… well, eight percent of 50 is exactly four discrete stores, so why not state it as such. To my ears your phrasing sounds like deliberate obfuscation of study scope and size.

  23. 32

    I’d also like to see the context of faceting and navigation UX presented along side these results in an extended study. Lazy load and show more buttons are great but it doesn’t answer the frustration of non-sticky filtering capability at all breakpoints. Many of the times users aren’t given a choice to refine continuous load results due to the filtering UX being fixed under the top navigation, so why not keep scrolling. This doesn’t mean it’s the right experience given the lack of choice to refine. Having to scroll back to the top of the page to refine or search is just as critical a topic as back navigation IMO. I’m constantly thinking about the right mix of browsing functionality and noise reduction. Art and science.

  24. 33

    Great Article!

    From an ecommerce perspective, the site should aim to help the buyer narrow down on options so that they are less confused and more focused rather than pumping up too many options.

    For all purposes, the infinite scroll seems to be a cool technology piece rather than solving a business function. Maybe it is more suited for news articles and stuff that tend to keep the user in place for longer rather than having it in a place where someone has to make a decision and pay for it.

    My $0.02! :)

  25. 34

    For browsing I like the lazy loading, but perhaps a way to “favorite” or mark to “check out later” would be helpful. So as I browse, I make a list of the ones I want to see in more detail.

    If I’m looking for a product and do a search, I’m of the theory that, save for some very large or specific retailers, if your filters and search terms aren’t pulling it back in the first few sets of results then something is wrong elsewhere. For example, I can’t stand finding shows on Amazon Instant Video on my Xbox because each season is listed separately. So I can scroll past five screens and see maybe three shows.

    Also, for this study, did they examine the sites as they are, or implement all three forms of browsing on the same set of sites? If not, there could easily be other UI features at play here that minimizes any real, useful data.

  26. 35

    I still tend to use pagination with filter to choose how much product that will show on the page.

  27. 36

    From my experience, unless you have a way to mark where a visitor is down the page of an infinite scrolling website, they become pointless. Way too many times have I clicked a link, then hitting back returns me to the top of the page, where I have to scroll through 100s more images before reaching where I left off.

    I believe if you have a list of products, then pagination is ideal, especially in eCommerce.

  28. 37

    I was looking at some premium OpenCart templates and found website. Do you think we should try one of their themes?

  29. 38

    Great article.

    However, I miss the button “Load All”, instead of a lot of “Load More” buttons appearing at regular intervals.

    Giving users the power to choose how to view the page, would be a great idea in my view – which should be tested on other real users :-)

    Having the whole page, makes it easy to glance through the complete selection, search internally on the whole page, and use as a starting point for viewing details on each product (e.g. in a separate windows).

    With more and more users on Mbit-lines, the time to load a long page is negligible.

  30. 39

    Hongbo Miao

    June 15, 2016 7:22 pm

    It is very useful! Thank you for sharing!


↑ Back to top