Sep 12, 2025 | RUMCG Meeting

Attendees

• Andy Davies
• Erwin Hofman
• Karlijn Lowik
• Nic Jansma
• Michal Mocny
• Philip Tellis
• Yoav Weiss
• Sia Karamalegos
• Sergey Cherneyshev
• Eric Goldstein
• Simeon Totev
• Issac Gerges

Agenda

• Unresponsive crash reports, Self Profiling (Issac Gerges)

Admin

• Next meeting: October 2025

AI Notes

Navigation Timing and RUM Vendor Feedback

• The group is seeking specific input from RUM vendors on a navigation timing proposal to improve visibility into cross-document view transitions and identify hidden delays.
• The proposal to add timestamps for activation and dismissal of documents aims to clarify unknown delays during page transitions, which currently hinder user experience analysis (08:16)

• This would help expose delays caused by event handlers holding the old page during unload
• Tims concept of unattributed navigation time highlights this as a blind spot with no clear data today
• Sergey plans to document the full page lifecycle and pinpoint where these timestamps would help
• Privacy concerns around cross-origin redirects were discussed but this proposal focuses on same-origin contexts

• The group is encouraged to review and comment on the proposal by October 3rd to influence the 2026 Interop submission window (15:54)

• Karlijn and Erwin emphasized adding new metrics like LOAF and fetch timing, and upvoting existing ones such as CLS
• Yoav noted many resource timing tests currently fail and suggested prioritizing those for improvement
• Tracking and voting on these proposals will be coordinated in GitHub with community input encouraged

Interop 2025 Progress and 2026 Planning

• The discussion reviewed progress on 2025 Interop goals and outlined a coordinated effort to shape 2026 feature submissions with community backing.
• Core Web Vitals features like LCP and Element Timing are showing steady progress in Edge and Firefox but Safari updates remain unclear (14:25)

• No recent updates from Safari representatives were available, raising uncertainty about their timeline
• The group aims to keep momentum by upvoting key metrics issues to influence browser vendor priorities
• Mateusz volunteered to help add missing resource timing proposals for Interop 2026 by the September 24th deadline

• A two-phase approach will guide community involvement: proposal submissions by September 24th and voting through December 11th (19:44)

• This timeline aligns with the Amsterdam Web Performance conference, facilitating in-person advocacy
• The group plans to maintain a tracking issue in their GitHub repo to monitor proposal statuses and gather feedback
• Signature-based Subresource Integrity (SRI) was noted as an upcoming Chromium feature with enthusiastic support from Mateusz's team

Slacks Frontend Performance Challenges and Tools

• Isaac from Slack detailed Slacks unique performance challenges and the custom tooling developed to identify and reduce input delays and unresponsive crashes.
• Slacks desktop app has infrequent page loads but constant real-time updates on a single thread, making interactivity metrics like input delay critical (26:05)

• Over 60 engineers contribute to a complex frontend with features like multi-user video chat and multi-window support
• This complexity leads to frequent UI reconciliations triggered by many small state changes, increasing risk of blocking input

• Slack built Sleuth, a profiling tool using Chromium tracing APIs, to collect detailed performance data from escalations by large customers (29:54)

• Sleuth enables engineers to see exact call stacks and pinpoint blocking code without lengthy back-and-forth troubleshooting
• This tool has greatly improved issue resolution speed and visibility into customer-specific problems

• Unresponsive crash reporting via a new web API integrated with Sentry cut Slacks crash volume by half within a month (31:14)

• The API provides call stacks from unresponsive events that were previously invisible, enabling targeted fixes in 14 code areas
• Isaac emphasized this visibility was a major breakthrough in managing long-standing performance issues

• Self profiling API lets Slack continuously collect JavaScript profiles on engineers sessions to identify input delay hotspots (33:44)

• This profiling revealed forced layouts as a major cause of input blocking and identified 20 components causing problematic style recalculations
• Around 12 engineers are actively working through a list of 30-40 such performance issues based on these profiles
• The profiling is too costly for customers currently, but Slack plans limited sampling to reduce overhead

Discussion on Profiling APIs and Attribution Limitations

• The group debated the overhead, usefulness, and limitations of profiling APIs like self profiling and LOAF for pinpointing frontend bottlenecks.
• Isaac explained LOAF events often attribute delays to generic UI flushes, missing finer-grained function call details that self profiling exposes (37:56)

• Self profiling captures full call stacks and forced layout calls that LOAF alone cannot differentiate
• However, continuous profiling has overhead, and Slack experiments with enabling it for a small fraction of sessions to balance cost and insight

• Michael from Google contrasted two approaches: uploading detailed traces per event versus aggregating average stacks across many events (45:13)

• Slacks method resembles the aggregate sample approach, bucketing input delays by duration and categorizing by UI component
• This balances detail with scalability but may blur distinct rare issues

• Concerns were raised about self profilings startup and runtime costs, with Slack noting a 1-1.5 second page load delay when always enabling profiling headers (49:19)

• Discussions referenced historical benchmarks showing around 3% page load time increase just sending the profiling header
• More studies are needed to quantify the runtime profiling cost and its impact on user experience before wider rollout

• The group touched on ongoing efforts to improve LOAF attribution by allowing frameworks to better label work segments (55:08)

• This could help isolate problematic scripts without the full cost of profiling, though it remains coarse-grained

Long-Term Vision for Performance Tooling and Automation

• Isaac shared his vision to automate performance diagnosis so engineers receive curated, actionable insights without manual triage.
• He hopes future browser tools will surface the top 20 performance pain points automatically, reducing the need for a dedicated performance team (36:17)

• The goal is for systems like Sentry to automatically attribute errors to specific owners and package issues for quick fixes
• Isaac stressed that while automation can help, engineering judgment will always be needed for final resolutions

• The current self profiling and crash reporting APIs offer a foundation for such tooling but require better integration and usability improvements (43:50)

• Slack would gladly pay vendors like Sentry to provide seamless visibility and mapping of unresponsive crashes with source maps
• Current API bundling with unrelated reporting complicates selective data sharing and needs refinement

• Speakers agreed that education and training remain vital to help engineers interpret automated reports and address root causes effectively (40:53)

• AI may assist in future but cannot fully replace human understanding and prioritization for complex frontend issues

• The group sees potential in expanding soft navigation and async context tracking to improve attribution across interactions and visual updates (56:36)

• Linking paints and script execution back to original user interactions could refine performance insights further

Process and Community Coordination

• The group emphasized ongoing collaboration to shape web performance standards and improve tooling collectively.
• Sergey took ownership to replace Bitly for link shortening due to advertising intrusions, ensuring professional group communications (07:12)
• The next meeting is set for October 10th at the usual time, with encouragement for members to propose topics or lead discussions (05:28)
• A Real User Meetup is scheduled at Google HQ the day before the Performance Now conference, with a request for RSVPs at least three days prior (59:00)
• Community members are urged to participate actively in GitHub issue discussions and proposal upvoting to influence browser vendor priorities for Interop 2026 (17:44)

Action items

Sergey

• Investigate and migrate from Bitly to an alternative URL shortening service or consider reverting to long links to avoid advertising issues (00:07)

Meeting organizer/Community Group

• Encourage community members to upvote and propose issues for Interop 2026 submission by September 24th; track items of interest in RUM CG GitHub repo for visibility (00:15)

Mateusz

• Add missing resource timing and navigation timing issues to Interop 2026 proposal list (00:18)

Organizer

• Create a tracking issue in RUM CG GitHub repo for Interop 2026 items to facilitate community coordination and voting (00:21)

Isaac

• Consider following up with Web Performance Working Group to propose improvements to LOAF attribution and self profiling APIs based on Slacks experience and overhead tradeoffs (00:58)

Participants

• Provide anecdotal feedback or data to the navigation timing timestamp proposal thread if customers are impacted by such timing gaps (00:08)

Meeting participants attending Performance Now

• Register via Eventbrite at least three days before the RUM meetup event at Google HQ for security clearance (00:59)

Meeting organizer

• Follow up on the progress and influence of outstanding Core Web Vitals issues from Interop 2025 into Interop 2026 cycle (00:20)
• Investigate coordination with Safari team for updates on Core Web Vitals test progress (00:15)

Sergey and colleagues

• Evaluate bug reports on LOAF API limitations and consider submitting enhancements to browser vendors (00:39)

Meeting attendees

• Contribute ideas for October 10th meeting agenda in Slack or agenda document (00:06)