So much great work has been done of shopfront load time so I hope folks don’t read this and sigh!
Products Caching works well for most clients. But Stroudco have been finding that users with slower machines are failing to load the page. As a large part of our goal in the UK is to make real food accessible to people on low incomes it is inherently designed into our service that we are going to be working with people with old computers running old browsers.
Currently OFN loads the full product set before displaying the shopfront. For shops with 500+ products this means 500+ requests to our image server which seems to be the main time waster. We often hear complaints of Stroudco shopfront timing out on old browsers and Stroudco have seen a drop in sales that at least is partially related.
Much talk has gone on of pagination. In many ways this is not an ideal solution by itself. By not loading everything into the DOM at the start though we end up with searching needing to send a rq to the server. Sending these RQs to the cache will help but it seems there is a strong feeling to have the full product set loaded into the DOM from the start.
With this in mind @pmackay and I have discussed a number of options.
The most recent favourite would be a kind of pagination on the loading of images only. Paul suggested auto-scroll so that as the user scrolls down the next set of images loads. Image loading could potentially be done asynchronously in the background, but loaded as batches so as not to create a confusing user experience as the page jumps about as each image loads (I hate that).
Would be great to find out if this is possible? Practical? A potential good solution? Totally ridiculous?
@oeoeaio I ping you for your detailed knowledge of angular. It would be great to hear any quick initial thoughts on feasibility. @RohanM I ping you to find out how this solution sits with you and all the work you’ve done on the cache. @maikel I bet you have interesting things to contribute too
@Oliver, @NickWeir Ping to find out how this sounds for Stroudco.
I’d like to comment, firstly, that I too experience the delays in loading, despite running the latest version of Firefox on a 2013 high-spec MacBook Pro. So it seems that the rural British internet speed is not up to it.
Your suggestions make a lot of sense to me but I think displaying a list of categories and then only listing the content of the selected category at a time could also be considered, depending on which is less work and what other users would prefer going forward.
Will answer in more detail tomorrow, but I guess my first question is this: is the amount of data being loaded a problem only because a) it takes a long time to download, or could it b) be because it takes a lot of memory once it is there, or c) that rendering and then watching for changes on such a large dataset requires a large amounts of CPU time?
If we could get a good feel for actual request time vs render time for a large dataset that might be useful.
It is my understanding that only image urls rather than actual images themselves are being cached, and so I don’t think images should be contributing to a slow initial load speed of the interface? Unless we are somehow preventing the interface from rendering until images are loaded? Could you confirm or deny that @RohanM?
I have had a look at a few different infinite scroll libraries over the years and I tend to like the look of the implementation behind virtual scroll libraries like angular-vs-repeat, though I’ve never actually used it. Might be worth trying out to see the effect that it has on images if we think that is the problem?
I suspect that CPU time is at least as big an issue as download speed for older devices. This would also be helped by loading far fewer objects into the DOM using a virtual scroll.
Thanks @pmackay, I think it does. Though I am not that well versed in performance testing TBH. I think you’re right in that a decent amount of time is being spent rendering the DOM, in addition to the time spent actually downloading data…
Just a thought and not sure this is the right thread (I think I read someone asking about whether to load up category selection first as possible solution?) . . the shop preferences allow the shop to set the order of product categories. Might it be useful to allow them to set one or more categories that load up to start with, so that the initial page load happens faster. Then customer could use filters to change categories or load up the rest as they need?
Even better if a customer could set their preferred categories to load up first, but that would be an ‘advanced user’ thing that wouldn’t get them past their first slow experience
hey @Oliver@lin_d_hop@oeoeaio - is it fair to say that the last round of changes has this at a satisfactory level and I can move this out of ‘wishlist’?
