We've been improving performance for all users over the last year, in the last few weeks we introduced a custom load balancer among other things.
One thing these changes _should_ do is decrease the strain on the shared runners so you don't need to wait as long for the CI/CD pipelines to run. Right now we have some people/projects using a lot more resources than others, which was causing some of the back-up.
We can't really make the site faster only for specific users, and even if we could I don't think we would.
That said, with a proper revenue stream we'll be able to focus more resources toward performance on GitLab.com, so you should see continued improvement.
You can look through our issues labeled performance for GitLab CE[1], the infrastructure issue tracker[2], or our Gitaly project[3] for some examples of progress.
I wanted to add that the problem of the performance of GitLab.com was not because of the revenue but because of our focus and the fast growth. The revenue will help with paying the hosting bills as we keep growing.
And we'll make GitLab.com fast for everyone, including the free users.
One thing these changes _should_ do is decrease the strain on the shared runners so you don't need to wait as long for the CI/CD pipelines to run. Right now we have some people/projects using a lot more resources than others, which was causing some of the back-up.
We can't really make the site faster only for specific users, and even if we could I don't think we would.
That said, with a proper revenue stream we'll be able to focus more resources toward performance on GitLab.com, so you should see continued improvement.
You can look through our issues labeled performance for GitLab CE[1], the infrastructure issue tracker[2], or our Gitaly project[3] for some examples of progress.
[1]: https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf...
[2]: https://gitlab.com/gitlab-com/infrastructure/issues
[3]: https://gitlab.com/gitlab-org/gitaly