Closed Mopok closed 6 years ago
rudy-sasquatchstudio
commented
7 years ago Q: How should deeply nested categories work? The existing page only supports 3 layers. (womens > sweaters > yellow) for example.
How do you want the menu to look for that?
rudy-sasquatchstudio
commented
7 years ago Product loading issues ready for review
jason-sasquatchstudio
commented
7 years ago Lots to say about this one. Most of this PR https://github.com/lemonstand/lscloud-theme-meyer/pull/264 is dedicated to solving these problems.
Products and products filtered by a category are now shown on one unified page, but served by different api pages in json. Only products that are going to be displayed on the current page are loaded via json, and the requests are cached so it is instantaneous to navigate back.
It's probable that this has created some unused functions in meyer.js, but the code is very tangled and it's hard to tell. While doing this I also found many unused partials, and maybe unused pages, and unused files in the pages directory. This code base would benefit from some time dedicated to removing unused pieces.
There was already an api page that returned blog posts, so I removed the blog section of the theme api page, which was the only section of unbounded size. I made the home page use the blog api to load blog posts. Those were done in this commit https://github.com/lemonstand/lscloud-theme-meyer/pull/264/commits/764a54e01d06897edc2d3495eab100e2a89a56bb . The blog api could benefit from server-side pagination like what I implemented for the products api, but that is not included in this PR.
The page was slowed down by unnecessary timeouts set on functions making api calls. I removed those. There are still unnecessary looking timeouts, but I didn't want to touch them, just in case.
All categories (to two levels and one level deep respectively) are still loaded in the header and footer. If they weren't, there'd be no way to navigate to them. It would take close to 10000 categories for this to take longer to load than the hero image does, so this is irrelevant to performance.
Search now loads only the search results via json, and only makes the json call after the user has a delay in typing. It might make sense for search to only show the first 10 or so results, and it would certainly be more responsive, but that is not done in this PR.
The existing json api only notices categories no more than 3 levels deep (ie: living room > tables > coffee tables, but not living room > tables > coffee tables > square coffee tables). I did not change that, but it would make the code tidier and simpler to change it. The new code in meyer.js does store the current category as a list, so it would work for arbitrarily deep categories. The api and the html would need to be modified.
There were multiple places where products or categories were dumped in the html in a script element. I have removed many, possibly all, such places.
I think that covers everything. Whew!
jennbrewer
Major
Product Loading All products are loaded on every page in JSON twice. It is done in the background for pages that don't need to load products immediately, but products shouldn't even be loaded on pages that don't display them. The products are loaded in the navigation bar partial for the search function.
Pages that don't need products to be displayed; the dom loads fine, a bit delayed due to loading categories (See further down), then loads products in the background for 30s+. It's worth noting that if the user tries to use search before the products are loaded the search will break. The user will have no indication when search is ready or when it's broken.
Pages that depend on products, it will wait this 30s+ to load all the products then display the page.
Theme api Every page also loads a theme api json object. This holds information on theme settings. It gets rather large and doesn't need to be loaded on each page. For instance I only need theme settings regarding blogs on the blog page, I don't need to also get theme settings for the home page when I'm on the blog. So this should be split up into smaller objects to prevent unnecessary loading.
Home Page The homepage waits on all products to be loaded before displaying. It really should load then wait for the products in the featured collection.
Solution
Timings vs a Control store When comparing times of a store with 500+ products, 100+ categories with another store with 20 products 4 categories. The page load times differ a huge amount. Home Page: About 30s+ slower Product Page: 90s+ slower Static Pages (Contact Us): 3s+ for the DOM, then 40s+ to finally load the products behind the scenes for search.
Minor On all pages; in the header and footer all the categories are loaded. There should be a hard cap on how many are loaded in the footer and header.
This effects all pages because they all have the same footer and header.