## Release Notes We're introducing Rapid Diffs to the Merge Request Changes tab - a modernized approach to rendering code diffs that dramatically improves both real and perceived performance. This new system replaces client-side virtual scrolling with server-side rendering and HTML streaming, delivering diffs to users faster while maintaining full feature parity. Initially available as an opt-in experience, Rapid Diffs represents the foundation for consistent, performant diff rendering across GitLab. ## Problem to Solve As a developer reviewing code changes in merge requests, I want to see diffs load quickly and completely so I can efficiently review changes without waiting for content to appear or dealing with incomplete page loads. **Current Pain Points:** - **Slow perceived performance**: Users wait for JSON responses before any diff content appears - **Incomplete content loading**: Large merge requests may fail to load all diffs, leaving reviewers with partial information - **Inconsistent experience**: Different diff rendering approaches across GitLab pages create confusion - **Maintenance burden**: Virtualized scrolling implementation is complex and bug-prone - **Accessibility limitations**: Current client-side approach has gaps in screen reader support ## User Experience Goal The user should be able to navigate to a merge request's Changes tab and immediately see diff content appearing on screen, with additional diffs streaming in progressively, providing a fast and complete code review experience that works consistently across all merge request sizes. ## Proposal Implement Rapid Diffs architecture for the merge request Changes tab, replacing the current client-side virtual scrolling approach with server-side rendering and HTML streaming. ### User Journey 1. **Immediate Content**: User navigates to Changes tab and sees first diffs rendering immediately 2. **Progressive Loading**: Additional diffs stream in and appear without user action 3. **Full Interactivity**: All existing functionality (comments, suggestions, navigation) works seamlessly 4. **Consistent Experience**: Same interface and features as current implementation ## Further Details ### Feature Parity Requirements | Feature | Must-Have | Optional | Not in Scope | |---------|-----------|----------|--------------| | Version control | ✓ https://gitlab.com/groups/gitlab-org/-/epics/20756 | | | | Draft Notes (Batch Comments/Reviews) | ✓ https://gitlab.com/groups/gitlab-org/-/epics/20759 | | | | Code Suggestions (single and batch) | ✓ https://gitlab.com/gitlab-org/gitlab/-/work_items/588938 | | | | [Object Storage Support](https://docs.gitlab.com/administration/merge_request_diffs/) | ✓ https://gitlab.com/gitlab-org/gitlab/-/issues/587387 | | | | CRUD comment on line range | ✓ https://gitlab.com/gitlab-org/gitlab/-/work_items/588999 | | | | Draft comment on line range | ✓ https://gitlab.com/gitlab-org/gitlab/-/work_items/588999 | | | | Edit file link | ✓ https://gitlab.com/gitlab-org/gitlab/-/work_items/498890 | | | | Image support rendering | ✓ https://gitlab.com/gitlab-org/gitlab/-/work_items/499294 | | | | Show conflicts | ✓ https://gitlab.com/gitlab-org/gitlab/-/work_items/499559 | | | | Syntax highlighting cache | ✓ https://gitlab.com/gitlab-org/gitlab/-/work_items/502515 | | | | Linked file | | ✓ https://gitlab.com/groups/gitlab-org/-/epics/19906 | | | File by File Mode | | ✓ | | | Mark as viewed | | ✓ https://gitlab.com/groups/gitlab-org/-/epics/20754 | | | Hide all comments | | ✓ | | | Show full file (expand all lines) | | ✓ | | | Open in Web IDE link | | ✓ | | | CRUD comment on file | | ✓ | | | Image commenting | | ✓ | | | Empty state | | ✓ https://gitlab.com/gitlab-org/gitlab/-/work_items/533645 | | | Code quality highlights | | | ✓ | | Test coverage highlights | | | ✓ | | Increased diff limits | | | ✓ | ### Rollout Strategy **Opt-in Experience** - Feature flag enabling Rapid Diffs for merge requests - User preference toggle in interface - Feedback collection mechanisms - Performance monitoring and comparison ## Feature Usage Metrics ### Feedback Collection - **User Preference Tracking**: Monitor opt-in rates and user retention on new experience - **Feedback Issues**: Dedicated issue template for Rapid Diffs feedback - **User Surveys**: Periodic feedback collection on performance and usability ### Performance Monitoring - **Time to First Diff (TTFD)**: Measure time from navigation to first diff appearance - **Complete Load Time**: Track full page rendering completion - **JavaScript Bundle Size**: Monitor actual bundle sizes vs. targets - **Error Rates**: Track client-side errors and failed requests ### Usage Analytics - **Adoption Rate**: Percentage of users enabling Rapid Diffs - **Session Duration**: Time spent in Changes tab with new vs. old experience - **Interaction Patterns**: Comment creation, line expansion usage, navigation patterns ## What Does Success Look Like? ### User Experience Success - **Sub-1.5-second Time to First Diff** for diffs with 1000 lines or less. **Sub-2-second Time to First Diff*** for diffs above 1000 lines. - **25-40% Improvement on Fully Loaded Diff**  See [detailed formula in the Architecture blueprint](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/rapid_diffs/#fully-loaded-improvement-formula). - **Positive user feedback** indicating improved perceived performance - **Feature parity maintained** with no loss of existing functionality - **Accessibility compliance** meeting WCAG 2.2 AA standards ### Technical Success - **Stable performance**: No increase in error rates or support tickets - **Successful streaming**: HTML streaming working reliably across environments ### Adoption Success - **Growing opt-in rate** indicating user preference for new experience - **Low revert rate** showing users stick with Rapid Diffs once enabled - **Positive feedback themes** around speed and reliability improvements ## Measurement Strategy ### How We'll Collect Feedback 1. **Feedback callout and dedicated issue** on Changes tab directing users to provide feedback 2. **User research sessions** with volunteers from different user segments 3. **Performance comparison dashboards** showing old vs. new metrics ### What We'll Watch For - **Performance regressions** in any measured metrics - **Feature gap reports** where functionality doesn't match expectations - **Browser compatibility issues** across different environments - **Accessibility feedback** from users with assistive technologies --- *This effort represents the first iteration of Rapid Diffs in the merge request based on successful implementations in other parts of GitLab. Future work here will be to get to 100% feature parity with the existing implementation and enabling this as the default experience for merge requests in GitLab.* ### Internal Roadmap Details <!-- start roadmap:details --> https://gitlab.com/groups/gitlab-org/-/epics/18457#note_2951866819 <!-- end roadmap:details -->