Optimization priorities [1.12rc1]

[pkarw]

What is the motivation for adding / enhancing this feature?

I've just decided to put a short note on the priorities over-optimization tasks we've planned for 1.12rc1. Not all of them have the same impact - therefore the same priority:

High priority - high impact, no breaking changes, pretty obvious things to do

1. Remove Elastic DSL / bodybuilder from frontend #2167 - Remove Elastic DSL from the frontend (move it to storefront-api or vue-storefront-api or both); potentially will save up to 500kb bundle size (bodybuilder package); it should be potentially a separate package as both: storefront-api and vue-storefront-api projects are using the same SearchQuery + SearchAdapter interfaces
2. Create an default-optimized theme based on default #3963 - Create a default-optimized theme with limited feature set - related to Optimize the bundle size #2232 -> this theme is https://github.com/DivanteLtd/vsf-capybara
3. Implement lazy-loading for products data #3706 - Implement network first data fetching strategy - to optimize the low 3g (and below) experience + potentially the Google Page Speed results
4. Optimize the bundle size #2232 - Optimize bundle size: graphql to by dynamically loaded + bodybuilder to be removed are key priorities; remove unused imports
5. Add the request_cache parameter support for Elastic storefront-api#33 - Add request_cache for vue-storefront-api or storefront-api calls
6. #3819 - Parallel building could give us up to -33% in the build time
7. Script prefetch optimizations #4030 - Prefetch optimization
8. Add PURGE support for cache invalidation  #4096 - Add purge requests support to invalidate CDN cache
9. Data prefetching optimizations #4161 - Prefetch the PDP data from PLP level

Medium priority - lower, or unknown impact, potentially breaking changes or need analysis

1. Remove the attribute/list call around the codebase #3948 - Remove the attribute/list call and remove the usage of attribute metada dictionary on the frontend.
2. Optimize the translation.processor #3950 - Optimize the translation.processor to process only the language files that are in use
3. Simplify the product vuex store #3952 - Simplify the catalog business logic - not sure if there will be a direct performance benefit from this simplification but it should be pretty ok to simplify the core codebase making it easier to maintain VSF - the other thing is that we should be very careful of the backward compatibility of this change

Other - other tasks, sometimes not 100% related to the performance ;)

1. Optimize the setupBreadcrumbs for the PDP #3951 - Optimize the way breadcrumbs are set - mostly for the PDP but probably for PLP as well

[pkarw]

@andrzejewsky @cewald @ResuBaka @gibkigonzo @haelbichalex @grimasod - please feel free to pick up some of these tasks as well as just share your comments/feedback/other ideas?

We decided to have the 1.12rc1 just all about the performance optimization

[lukeromanowicz]

There is no doubt that these are highly needed changes and will be a great improvement to vue storefront but I can already see the hell of upgrading a customized projected to 1.12 :/ A comprehensive guide and preferably some migration accelerating tools would be welcomed.

Personally I would add https://github.com/DivanteLtd/vue-storefront/issues/3819 as high priority to that list and it's something I will try to take care of.

[pkarw]

@lukeromanowicz cool - putting #3819 on the list; which tasks from the list you're afraid of regarding the upgrade path? I guess the High priority list doesn't consist any of non-b/c changes (i tried no to put any of those on it) even removing bodybuilder is not a b/c break as you as a developer can always import it

[lukeromanowicz]

Mainly I am afraid of:

• Remove Elastic DSL from the frontend
• removing attribute/list
• changing catalog logic once again

It might be safe for some projects where no custom es structures/mappings/filters are done but in other scenarios, it's gonna be a pain

[andrzejewsky]

@lukeromanowicz understandable, we'll try to minimize BC-breaks / use deprecates instead.

@pkarw I think this one: #3919 should be on that list because it's also part of 1.12, maybe it's not optimization itself but there are changes in webpack that might also reduce a bundle sizes etc.. and I think that will be the first thing what we will be working on when it comes to 1.12rc1.

[pkarw]

You’re tight we need to be careful- I guess we should have - as awkward it sounds - config vars to enable this new behavior / or implement it as switchable modules / or at last have a upgrade docs with a notes how to get the prev. behavior up and running

Anyway - I’m almost sure we can achieve 100% backward compatibility with the current Vuex actions. There will be a case - as you described - if anyone override any action we’ll affect during the optimization. There should be docs for that case

But on the other hand I’ve got a feeling we can optimize VSF bundle size and page speed results at least by 30% without any major architecture changes (the listed changes are minor or medium impact changes still based on current general approach - Vuex etc) so I guess it’s worth doing?

[ResuBaka]

Removing the bodybuilder package should not be so hard as we can just send the contend of content of SearchQuery (_availableFilters,_appliedFilters,_searchText) to the api and with that we can build the query. As you normally would not use the bodybuilder directly it should be transparent to the user. They only need to know that they need to update the API. So in the end it would only be a b/c change when you want to use the VSF 1.12 with the API on version 1.11.

But a better way would be that we move that change to a new adapter package and then have a config on the API side to enable the bodybuilder there, for the new search adapter.

[pkarw]

#2167 and #2232 are Work In Progress: #2167

[pkarw]

Another idea for optimization:

  optimization: {
    splitChunks: {
      chunks: 'all'
    }
  },

https://webpack.js.org/configuration/optimization/

[pkarw]

As for now i think the #3963 and #3706 along with #2232 will provide us with the highest performance impact

[pkarw]

@gibkigonzo we need to make sure that https://github.com/DivanteLtd/magento2-vsbridge-indexer and https://github.com/DivanteLtd/magento1-vsbridge-indexer are ready for #3948 - check it with @afirlejczyk please

[pkarw]

Related: https://github.com/new-fantastic/vsf-cloudflare