Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Vue] initial page load performance test #18981

Open
diosmosis opened this issue Mar 22, 2022 · 0 comments
Open

[Vue] initial page load performance test #18981

diosmosis opened this issue Mar 22, 2022 · 0 comments
Labels
c: Performance For when we could improve the performance / speed of Matomo.

Comments

@diosmosis
Copy link
Member

diosmosis commented Mar 22, 2022

Given that the current Vue migration has resulted in a total of ~300kb being added to Matomo's gzipped JavaScript (w/ all premium features), it seemed like a good time to run some performance tests and check whether performance has degraded. Talking to @tsteur, it was determined that page load time is the only important metric to look at.

To test the frontend I used demo2 in three different states: at 4.5.0 (before the Vue migration), 4.8.0 (latest release w/ 300kb added to JavaScript assets), 4.x-dev (Vue code with asset chunking merged).

Tests were run using https://web.dev/measure/ (a tool created by Google).

Screenshots of the results are below, with findings/conclusions afterwards:

4.5.0 (baseline metrics)

4_5_0_measure1
4_5_0_measure2
4_5_0_measure3
4_5_0_measure4

4.8.0 (Vue without asset chunking)

4_8_0_measure1
4_8_0_measure2
4_8_0_measure3
4_8_0_measure4

(Performance degrades as expected since the only change is more JavaScript to the two synchronous HTTP requests made.)

4.x-dev (Vue with asset chunking)

4xdev_measure1
4xdev_measure2
4xdev_measure3
4xdev_measure4

Observations

  • The size of the JavaScript assets affects performance in 4.8.0, but not in 4.x-dev due to the use of asset chunking, and the fact that Vue code does not have to be immediately evaluated (unlike Matomo's jquery/angularjs code else), so it can be loaded with defer.
  • The biggest issue is the getCoreJs/getNonCoreJs files which both have to be loaded and executed synchronously. Both of these issues will naturally be solved by the Vue migration, even if there's more code.
  • web.dev reports that much of the JS code is unused on first page load (4.5.0: 1.8/2.8mb, 4.8.0: 2.2/3.4 mb, 4.x-dev: 2.4/3.6mb). The unused amount goes up with Vue use, of course, due to the precompiled templates, but it seems that removing the templates by themselves (ie, loading the vue templates like angularjs html templates) won't be as effective as removing both JavaScript and templates (which will naturally occur w/ delayed import()).
  • Script execution time goes down even with more with JavaScript, likely due to Vue using precompiled templates, and maybe being just faster than angularjs.
  • The bulk of script execution time is spent with getCoreJs, nothing else. getNonCoreJs and the chunks (which now contain CoreHome/CorePluginsAdmin) all take <= 150ms to execute. Something in this script is very CPU intensive.

Conclusions

Overall, for the moment, performance is improving with the vue migration, despite more code. This is primarily due to precompiled templates and asset chunking working together.

However there appear to be some ways to further improve page load time:

  • Once the AngularJS code is removed entirely (in Matomo 5) and inline scripts w/o defer are disallowed, it will be possible to make getNonCoreJs/getCoreJs entirely asynchronous.
  • Implement optional on demand loading of plugin Vue modules (already done in a PoC PR).
  • Not as big an improvement as the rest, but styles can be moved to scoped styles and loaded on demand with lazy loaded plugins. This would reduce the size of the initial CSS request.
  • Avoid full page loads by handling all URL changes via the pushState API so loaded UMDs don't disappear when, eg, going to tag manager, going to dashboard, then going back to tag manager (do-able for Matomo 5 and can be done after Vue migration).

I'll be creating linked issues for the above action items, excepting for the on-demand loading of plugins, which is already done in a PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c: Performance For when we could improve the performance / speed of Matomo.
Projects
None yet
Development

No branches or pull requests

2 participants