6 ms·

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-lead

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 6y ago
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/ https://about.gitlab.com/handbook/engineering/performance/
- ddevault 6y ago
  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/dts https://git.sr.ht/~sircmpwn/linux/tree/master/arch/arm/boot/... https://github.com/torvalds/linux/tree/master/arch/arm/boot/dts https://github.com/torvalds/linux/tree/master/arch/arm/boot/... https://gitlab.com/ddevault/linux/-/tree/master/arch/arm/boot/dts 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://git.sr.ht/~sircmpwn/scdoc/tree/master/src https://github.com/ddevault/scdoc/tree/master/src https://github.com/ddevault/scdoc/tree/master/src https://gitlab.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.
  - emilycook 6y ago
    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 6y ago
      No problem. Good luck bringing these numbers down!
    - techntoke 6y ago
      You need to add more JavaScript. Currently page load time are not good, bit it would be the perfect time to add the telemetry: https://news.ycombinator.com/item?id=21390563 https://news.ycombinator.com/item?id=21390563 Once you add enough JavaScript it is like time travel. Instead of getting slower you actually speed up time.
  - sytse 6y ago
    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/gitlab.com/2020-02-27-00-22-14/pages.html https://storage.googleapis.com/sitespeed-results-gitlab/gitl... and https://about.gitlab.com/handbook/engineering/performance/ https://about.gitlab.com/handbook/engineering/performance/
    - sytse 6y ago
      And we created https://gitlab.com/gitlab-org/gitlab/-/issues/214681 https://gitlab.com/gitlab-org/gitlab/-/issues/214681
      - sytse 6y ago
        And we quickly fixed https://gitlab.com/gitlab-org/quality/performance/-/merge_requests/149 https://gitlab.com/gitlab-org/quality/performance/-/merge_re...

emilycook 6y ago

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/ https://about.gitlab.com/handbook/engineering/performance/

ddevault 6y ago
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/dts https://git.sr.ht/~sircmpwn/linux/tree/master/arch/arm/boot/... https://github.com/torvalds/linux/tree/master/arch/arm/boot/dts https://github.com/torvalds/linux/tree/master/arch/arm/boot/... https://gitlab.com/ddevault/linux/-/tree/master/arch/arm/boot/dts 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://git.sr.ht/~sircmpwn/scdoc/tree/master/src https://github.com/ddevault/scdoc/tree/master/src https://github.com/ddevault/scdoc/tree/master/src https://gitlab.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.
- emilycook 6y ago
  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 6y ago
    No problem. Good luck bringing these numbers down!
  - techntoke 6y ago
    You need to add more JavaScript. Currently page load time are not good, bit it would be the perfect time to add the telemetry: https://news.ycombinator.com/item?id=21390563 https://news.ycombinator.com/item?id=21390563 Once you add enough JavaScript it is like time travel. Instead of getting slower you actually speed up time.
- sytse 6y ago
  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/gitlab.com/2020-02-27-00-22-14/pages.html https://storage.googleapis.com/sitespeed-results-gitlab/gitl... and https://about.gitlab.com/handbook/engineering/performance/ https://about.gitlab.com/handbook/engineering/performance/
  - sytse 6y ago
    And we created https://gitlab.com/gitlab-org/gitlab/-/issues/214681 https://gitlab.com/gitlab-org/gitlab/-/issues/214681
    - sytse 6y ago
      And we quickly fixed https://gitlab.com/gitlab-org/quality/performance/-/merge_requests/149 https://gitlab.com/gitlab-org/quality/performance/-/merge_re...