[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!