[shred45]

Hey, also don't have a time for a full review, but had one comment. I've been a pretty passionate user of GitLab for 2+ years and really loved the industry-leading integrated CI/CD. I have found that page load times on both GitLab and GitHub, however, are pretty bad, with GitLab being the worst. Many administrative tasks, such as logging in -> finding repo -> checking a ci/cd test -> merging / releasing the branch, take 10+ page loads, and each one is quite slow. I ended up moving my personal projects to sourcehut simply because pages are more lightweight and server response times are faster. If GitLab could spend some time reducing the number of pages required for common tasks (not asking for a single-page-app!), and could reduce page load times as much as possible (I know this isn't trivial with Rails), I think that would greatly reduce the friction I feel when using the produce.

[emilycook]

Thank you so much for the feedback! I'm asking around to see if there are any projects open to reduce the number of pages, but I do know for sure that reducing page load times is an issue we're working on. Here is our handbook page that outlines our current metrics and goals, our primary goal is to have a speed index of less than 2 seconds per each page on .com: https://about.gitlab.com/handbook/engineering/performance/

[ddevault]

I know I'm biased here (full disclosure: sourcehut guy here), but I really hope you'll bring that goal even lower. I recently did a comparison between GitHub, GitLab, and SourceHut on the same "worst-case" page:

https://git.sr.ht/~sircmpwn/linux/tree/master/arch/arm/boot/...

https://github.com/torvalds/linux/tree/master/arch/arm/boot/...

https://gitlab.com/ddevault/linux/-/tree/master/arch/arm/boo...

                    cold cache     warm cache
    git.sr.ht:      1.4s     72K   1.4s     48K

    github.com:     3.3s    635K   3.0s    317K*

    gitlab.com:     3.1s   1300K   1.6s     58K+

    * Hides half of the files
    + Only the initial load, it loads a bunch of stuff with JS to keep
      populating the page afterwards, and has severe performance issues
      simply using the page (on Chromium, it was straight up unusable on
      qutebrowser)

Even after the page loads, for me it's impossible to use. On a more forgiving "best-case" page, GitLab has poor performance:

https://git.sr.ht/~sircmpwn/scdoc/tree/master/src

https://github.com/ddevault/scdoc/tree/master/src

https://gitlab.com/ddevault/scdoc/-/tree/master/src

                    cold cache     warm cache
    git.sr.ht:      296ms    28K   198ms      4K

    github.com:     572ms   360K   629ms     36K

    gitlab.com:    1310ms  1311K  1110ms     16K

You should definitely make performance a core focus IMO.

[gygitlab]

Many thanks indeed for calling this out. Performance is certainly a key goal for us and as part of the Quality group we've been increasing our performance test efforts over the last year and prioritising performance fixes with our dev teams.

We've investigated and confirmed the controller that's looks to be the cause of this and raised an Issue here - https://gitlab.com/gitlab-org/gitlab/-/issues/214681. Many thanks again.

[emilycook]

Oh my goodness thank you so much for this! I'm gonna show this to our performance team. I appreciate you sharing the comparison, this is very helpful.

[ddevault]

No problem. Good luck bringing these numbers down!

[sytse]

I agree, thanks for the numbers. I'll suggest to incorporate this into our Q2 OKRs.

For our references please see https://storage.googleapis.com/sitespeed-results-gitlab/gitl... and https://about.gitlab.com/handbook/engineering/performance/

[sytse]

And we created https://gitlab.com/gitlab-org/gitlab/-/issues/214681

[sytse]

And we quickly fixed https://gitlab.com/gitlab-org/quality/performance/-/merge_re...

[alrafer]

Great turnaround time!