Frontend Performance Audit

Frontend performance is the combination of loading, parsing, rendering and perceived performance.

The idea of this is issue is to collect different performance measurements from the outside through different methods, assess the results and suggest different actions for FE implementation (e.g. in this issue gitlab-ce#23213), Infrastructure tasks or architecture changes. It is the goal to assess the different suggested actions on their impact + complexity, rank them and bring them to implementation. Also different popular optimisation strategies should be discussed here to reach different goals (e.g. mitigate slower page rendering performance by using on page with local storage).

Measurements

Startup

Use Cases that should be measured

Main Problem will be with automatic tools to have a consistent baseline and how do we do anonymous measurements.

Tools

Frontend Monitoring setup will be done for constant blackbox monitoring : gitlab-com/infrastructure#2106

Sitespeed.io - gitlab-org/gitlab-ce#34225

This looks like the perfect tool for our purpose of tracking FE performance, also integrates nicely in Grafana,etc. Moving forward with it to setup on a Frontend Monitoring machine.

  • Manual Sitespeed Script (ask in FE Channel for Temporary URL)
  • Automated Sitespeed Tracking to Grafana

Lighthouse (CLI, Will be automated and should be run constantly at a later stage)

There is an ongoing effort to integrate Lighthouse fully in CI gitlab-ce#33392

I think we should take a step by step approach with Lighthouse, first setup manual audits, track over time results also on a stable machine. Learn from its outputs and improve the FE. As soon as we are happy we can take another look at integrating in CI or integrate into monitoring. I think it would be hard with CI (already long pipelines) to have stable execution.

At a later stage it might make sense to take a look at custom audits for GL : https://github.com/GoogleChrome/lighthouse/tree/master/docs/recipes/custom-audit

  • Manual Lighthouse Tests (ask in FE Channel for Temporary URL)

GTMetrix

Tested through service all above URL's + setup monitoring for /explore + saved historical data for future reference :

Webpagetest

Done Manual Tests for now to gather/compare information.

PageSpeed Insights

You can run PSI on CLI level and get the results in JSON. (https://github.com/addyosmani/psi)

Usage

  • Manual Performance Audit on CPU/Memory on specific Tasks
  • Consistent FPS on Actions (Target 60 FPS)
  • Timing of Actions (By example top left project selector : Time from Click to being able to select a project)

Tools

  • InBrowser Performance Tools for Chrome / Edge / Firefox

Existing Initiatives for internal Frontend Performance Monitoring

gitlab-ce#27170

https://gitlab.com/brycepj/gitlab-frontend-monitor by @brycepj

https://gitlab.com/gitlab-com/infrastructure/issues/57#note_32137201

Resources

https://www.smashingmagazine.com/2016/12/front-end-performance-checklist-2017-pdf-pages/ https://developers.google.com/web/fundamentals/performance/

Actions

All actions should be measured by 1-10 on impact and effort (10=highest) and it should be determined if this will help .com only or overall GitLab (preferred method).

Code / Architecture changes

Images

Lazy Loading of images (gitlab-ce#34361) - Impact 9 / Effort ? / GL

Currently all Images on any GL page are loaded straight away , which leads to a blocking of the loading+rendering process. To resolve this problem we should start lazy loading of all relevant images

Resized Avatars to output size (gitlab-ce#34364) - Impact 8 / Effort ? / GL or .com

Currently all avatars that are displayed are using the original uploaded file in its original size, so for displaying a 24x24 User Avatar we load a 500 KB File sometimes. Also we should look at optimising PNG and eventual WebP There is a huge potential on saving bandwidth and loading time.

Deliver Content Images in output size (gitlab-ce#34365) - Impact 5 / Effort ? / GL

This is a technique to deliver images based on the current output size on that device. So that a mobile application only loads the image in a much smaller scale.

No offscreen Rendering of Images - Impact 2 / Effort ? / GL

Sometimes we render elements even if they are in a collapsed state :

Issue Sidebar : gitlab-ce#34366

Script

Currently we have the problem that in some pages legacy inline script is used which is depending on script out of the main JS file. So we can't set the script tags to async loading which would unblock the main loading/rendering path, and lead to a faster First Meaningful Paint. To enable this we are doing a 2 step process :

1. HAML Linter for finding Inline Scripts (gitlab-ce!9742) - Impact - / Effort 3 / None

@winh started on a linter which will check for inline scripts. It produces a list of erronous haml templates. Almost done and in review.

**2. Remove Inline Scripts from HAML (gitlab-ce#34903) **

Based on the linting results we need to remove those inline scripts and take the functionality to dispatcher.

3. Switch to async script loading

When we have removed all inline scripts we can put the script tag at the end and activate async loading.

Interim Solution : Specific Async Loading : gitlab-ce#34904

Webpack Code Splitting (gitlab-ce#33391) - Impact 7 / Effort 5 / GL

This will enable us to deliver packages which are optimised for each page. Already in progress

Upgrade to jQuery 3.x (gitlab-ce!11812) - Impact 5 / Effort ? / GL

Through the upgrade to jquery 3.x , which was a complete rewrite we could gain in some areas a significant performance boost, as selectors and a lot of other internals are much faster then in 2.x. Already in progress but hard to say the global effort.

Change to lodash instead of underscore.js (gitlab-ce!11812) - Impact 2 / Effort 4 / GL

Changing from underscore.js to lodash should give us here and there also a boost in execution. Main effort is to create a selective + optimised lodash package.

Data

Local Storage, Async API , etc.

Infrastructure changes

CDN (gitlab-com/infrastructure#57) - Impact 9 / Effort 4 / .com

By going through a CDN for our FE assets we should be able to reduce loading time significantly.

GZIP (gitlab-ce#33719) - Impact 7 / Effort ? / GL and/or .com

GZIP would help compress any textual content (html/json) that we are sending out from our webservers.

Cache Headers

HTTP/2

Edited by Tim Zallmann