Ever wonder why Amazon search results seem to load so fast? Turns out they are employing a cute trick when loading paginated results. Now, this technique is probably patented up the wazoo… so, use at your own risk!
Simply put, each results page contains data for more results than are displayed; so when the user presses next, the ‘extra’ results get shown immediately, and an AJAX call is then dispatched to load the rest. As a result, the user feels as if the search results appeared instantaneously.
Note how the first image requested for the second page of search results is for result #16, not for result #13.
Here’s the sequence –
- Let’s say the user searches for ‘harry potter‘, and the results are supposed to show 12 per page. Typically, 3 of these results would show up above the fold.
- When the results page loads, it loads up with data for 15 result items – but renders only 12 of them to the user.
- When the user clicks ‘Next »’, the AJAX page clears the results area, and updates them with the last 3 results (the ones that weren’t shown earlier)
- Only then does it make the AJAX call to the backend – and requests 15 new items.
- When these 15 arrive, it updates the bottom of the results area with the first 12, again keeping the data for the last 3 around, in case the user clicks on ‘Next »’.
- Rinse and repeat!
Implementation Notes
It’s curious that Amazon has chosen to have a pagination length of ’12’, an odd choice. It’s possible their search system is optimized for requests that are multiples of 5, so it was easier to have a page length of 12 and request 15 data items, rather than have a page length of 15, and have to request 18 data items.
While investigating this, I also noticed that Amazon doesn’t let you request paginated search results starting at an arbitrary page index – e.g., you can’t request page 8 of results while you’re viewing page 3. This makes sense, kinda. The side-effect is that, axiomatically, all search results load extremely fast!
Great use of precaching
This precaching of a few search results make the user feel like the results appear instantaneously, which, technically, they did. While the user consumes the top few results, the rest of the results stream in, for an amazingly smooth user experience!
@akumar overflow 
Interesting example where a simple micro-optimization can result in great deals. Whoa they patented it … a more general technique – Interlacing to show a blurred image and incrementally and load parts of it later to increase perceived speed is (or used to be) common.
Although Wikipedia (http://en.wikipedia.org/wiki/Interlacing_(bitmaps)) says that this technique is not quite popular these days, I do see a blurred version of images when opening some old images on facebook.
Perhaps preloading only three items has something to do with the screen height – by the time the user looks at the first three items which fit on a screen at a time the javascript can load other items in the background.
Interesting they did not use a simple double buffering technique wherein they could load 12 items in one buffer and before the user clicks on “next” preload all 12 items in another buffer.