5 ms·

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

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...
      - alrafer 6y ago
        Great turnaround time!
- gygitlab 6y ago
  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 https://gitlab.com/gitlab-org/gitlab/-/issues/214681. Many thanks again.

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...
    - alrafer 6y ago
      Great turnaround time!
gygitlab 6y ago
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 https://gitlab.com/gitlab-org/gitlab/-/issues/214681. Many thanks again.