All enterprises loaded into the shopfront on every page load

[daniellemoorhead]

As discussed in UK Hangout, Rob has been looking at front-end performance in response to Lynne's post on discourse.

He has found that enterprise are being serialised and loaded into all checkout (shopfront, cart, checkout, order confirmation) pages, which means a 2.5-3.5 second hit on each of these pages on Australian production. It also likely contributes to poor performance on devices where memory is limited.

The primary reason that this is in place is to ensure the correct data is available for enterprise modals on the various pages.

Strategy to resolve this would be to build async loading of data when a modal is available, rather than loading all possible data into the pages on the off-chance that it is required.

[daniellemoorhead]

@oeoeaio to run @mkllnk through his thinking on this.

[NickWeir63]

Thanks @daniellemoorhead and @oeoeaio it would make a big difference to the saleability of OFN in the UK if we could improve the load speed. Thank you for trying!

[pmackay]

@daniellemoorhead am wondering if you mean @oeoeaio above?

Also has there been previous discussion about enterprises all having permanent links? Do we need to maintain the modals at all? Permanent pages would have a bunch of benefits. Would it make sense to refactor to achieve that rather than changing so modals load on demand?

[mkllnk]

@pmackay I agree that it would be great to have individual pages for enterprises. That is something that has been requested a lot of times.

[daniellemoorhead]

@pmackay I also agree. Are you able to do a search on github/discourse and see if it's something that has been logged already, and if not create a new item for it? There's no money at present to do this work but it's definitely worthy of inclusion in the backlog (if it isn't already there). Cheers!

[mkllnk]

Okay, I'll make some notes here just for myself and for whoever is interested.

Budget: 15h

There are nine pages that load all enterprises. Most of them don't need all enterprises loaded upfront:

app/views/checkout/edit.html.haml editing your cart
app/views/enterprises/shop.html.haml the shop front
app/views/groups/index.html.haml listing all groups
app/views/groups/show.html.haml showing a single group
app/views/home/_hubs.html.haml the list of shops
app/views/map/index.html.haml the map with all enterprises
app/views/producers/index.html.haml the list of producers
app/views/spree/orders/edit.html.haml changing an order
app/views/spree/orders/show.html.haml showing an order

I used binding.pry to go into app/views/home/_hubs.html.haml and measured the time loading the enterprises takes on my laptop:

Benchmark.measure { inject_enterprises }

The first time it took 1 minute and 50 seconds. The following times it took between 5.4 and 6.4 seconds. That is validating Rob's results.

The shop list doesn't only display shops. It displays profiles and the producers of all shops (click for fat view). In it's current form, it actually displays all enterprises. So this is not a good candidate to start optimising.

The shop front displays the current shop and all of its producers. When you click on a producer, its modal pops up and displays the shops where you can buy from this producer. This modal is rarely viewed and the data should not be loaded upfront.

[NickWeir63]

@OliverUK sent me this screenshot - sorry for the delay in posting it

[mkllnk]

The following pages are now loading a smaller set of enterprises:

• shopfront,
• cart,
• checkout,
• order confirmation

On the Australian production server the shop list loads all enterprises and needs between 4 and 40 seconds for that. The Food Connect shopfront needs only 1.2 to 1.5 seconds loading fewer enterprises. This does not include the javascript rendering that goes on top of that.

I spent 15.6 hours on this task. But there are more pages that still load all enterprises:

• app/views/home/_hubs.html.haml the list of shops, this is a similar task, but could work very well, because we are showing only a few enterprises at the beginning
• app/views/groups/index.html.haml listing all groups, this is only for searching certain groups
• app/views/groups/show.html.haml showing a single group, this could be optimised similar to the current task
• app/views/map/index.html.haml the map with all enterprises, well, we need all enterprises on here, maybe caching would be good
• app/views/producers/index.html.haml the list of producers, this could be optimised similarly