Branch-based file views are slower than SHA-based in UI
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Summary
UI performance when browsing files by branch is significantly slower than accessing the same file by commit SHA. This occurs even when repository size, content, and commit structure are simple. On self-managed GitLab, this delay exceeds 10 seconds per request. On GitLab.com, the delay is smaller but still measurable, suggesting a systemic inefficiency in the Rails-based ref resolution path for branch-based file views.
Steps to reproduce
-
Create a repository with 500 short-lived branches, each with a single file and commit (example project below).
-
Push to GitLab.
-
Open any file via the branch in the UI:
https://gitlab.com/gyoachum_ultimate_group/zd622429/-/blob/branch-456/branch-456.txt
-
Get the commit SHA for the same branch:
❯ git rev-parse branch-456 2ce81b9720fc2884c95bb242fc47cb5a80f81539 -
Open the same file via SHA in the UI:
-
Compare performance using DevTools → Network tab (TTFB, total load time).
Example Project
https://gitlab.com/gyoachum_ultimate_group/zd622429
What is the current bug behavior?
- Branch-based file views trigger additional API requests (branches?search=, GraphQL, signatures, tags) and load more slowly.
- On self-managed GitLab with ref cache latency or high ref churn, these requests can take >10s.
- SHA-based access avoids these requests entirely and loads nearly instantly.
What is the expected correct behavior?
- Browsing a file by branch in the UI should perform similarly to browsing by commit SHA.
- Ref resolution and metadata hydration should not introduce significant latency for small or normal-sized repos.
Relevant logs and/or screenshots
See comparison screenshots below from GitLab.com using Chrome DevTools.
Branch-based:
- URL: /blob/branch-456/branch-456.txt
- Load: 1.90s
- Finish: 32.22s
- DOMContentLoaded: 1.20s
SHA-based:
- URL: /blob/2ce81b.../branch-456.txt
- Load: 1.80s
- Finish: 42.16s
- DOMContentLoaded: 1.64s
The fact that SHA-based file views may show a slightly longer overall “finish” time in the browser does not invalidate the performance concern. What actually matters is the time it takes to resolve the Git reference, load the file metadata, and render the content — all of which occur before or around DOMContentLoaded. In the example above, the SHA-based view achieves this just as fast or faster, despite finishing later due to non-critical async tasks. On self-managed instances, where background services and Rails capacity are more limited, the critical-path latency caused by branch-to-SHA resolution (e.g., FindLocalBranches, FindCommit, GraphQL hydration) is unavoidably user-facing, adding 10+ seconds of delay. That delay is avoided entirely when using SHA-based access, demonstrating that the current branch-resolution strategy introduces unnecessary overhead.
Output of checks
This happens on GitLab.com
Results of GitLab environment info
This happens on GitLab.com
Results of GitLab application Check
This happens on GitLab.com
Possible fixes
Patch release information for backports
If the bug fix needs to be backported in a patch release to a version under the maintenance policy, please follow the steps on the patch release runbook for GitLab engineers.
Refer to the internal "Release Information" dashboard for information about the next patch release, including the targeted versions, expected release date, and current status.
High-severity bug remediation
To remediate high-severity issues requiring an internal release for single-tenant SaaS instances, refer to the internal release process for engineers.
If you don't have /label privileges, follow up with an issue comment of `@gitlab-bot label ~"type::bug"`