Does returning from a product page preserve your place in the catalogue?
Someone browsing a long catalogue may open a product and return to find themselves at the beginning. Keeping the filter labels visible does not prove that the same product can be found again. The design decision is to define which browsing context survives the return, not merely to add a Back button. The catalogue example below is hypothetical and does not claim a measured fault or sales loss on a client website.
1. Define the context that should survive
Imagine a visitor choosing a material filter in a chair category, changing the sort order and opening an item from the second page. Category, filters, sorting, page and visual position all matter on return. Define which parts belong in the URL and which are temporary session state. Keeping everything only in browser memory may not reproduce the list when its link is reopened. Conversely, treating a pixel scroll value as a permanent product identifier can introduce unnecessary complexity. Start with the visitor’s actual comparison task.
2. Test the browser Back action first
Begin with the browser’s Back button rather than a custom return link. MDN describes history.scrollRestoration as controlling automatic or manual scroll restoration during history navigation. Changing this one setting does not restore every part of catalogue state. Observe the existing behaviour before adding more code, then investigate whether custom navigation is interrupting the natural return. A routine that scrolls to the top on every route change may also discard the position of someone returning from a detail page.
3. Include delayed cards in the return test
If product images or previously loaded groups arrive late, restoring the old scroll value may still show the wrong item. Card dimensions and loading order affect this experience. Under a slower connection, browse to the second group, open a product and return. Check whether the page jumps again after the intended product becomes visible. For applications with custom state, consider the product identifier as well as the pixel position when designing restoration. This is a proposed acceptance approach, not a measured performance result or a universal implementation recipe.
4. Do not rely on one successful cached return
web.dev explains how the back/forward cache can preserve page state and speed up returning navigation. Do not assume that every visit will use this cache. Repeat the task after a delay, after a reload and after opening the product through a direct link. Define the destination of the site’s own “Back to list” link separately. For a visitor who did not arrive from a list, blindly invoking browser history may lead somewhere unexpected. A meaningful category destination may be more appropriate in that case.
5. Write acceptance around a short customer task
Try: “Open a product from the second group in your filtered list, go Back and find the neighbouring model.” Record whether the person must rebuild the filters or search the whole list again. Test on mobile, desktop and with the keyboard; focus and scroll position are different parts of the experience. Include the return task in a web design delivery review. The catalogue pagination guide helps choose the list model, while shareable catalogue filters covers carrying selections in a usable link.
Frequently asked questions
Are filters in the URL enough?
They help preserve the selection. Loaded groups, scrolling and keyboard focus still need their own checks.
Will a custom Back button fix the problem?
Not by itself. Define history and direct-entry behaviour and test the actual browser return.