Chromium

2 posts

naverOriginal article

Analysis of Naver Integrated Search AIB (opens in new tab)

The integration of AI Briefing (AIB) into Naver Search has led to a noticeable increase in Largest Contentful Paint (LCP) values, with p95 metrics rising to approximately 3.1 seconds. This shift is primarily driven by the architectural mismatch between traditional performance metrics and the dynamic, streaming nature of AI chat interfaces. The analysis concludes that while AIB appears to degrade performance on paper, the delay is largely a result of how browsers measure rendering in incremental UI patterns. ### Impact of AIB on Search Performance * Since the introduction of AIB’s chat-based UI in July 2025, LCP p95 has moved beyond the 2.5-second target, showing a direct correlation with AIB traffic volume. * The performance degradation is characterized by a "tail" effect, where a higher percentage of users fall into slower LCP buckets despite stable server response times. * Unlike Google’s AI Overview, which renders in larger blocks, Naver’s AIB uses word-by-word animations and frequent UI updates that place a heavier burden on the browser's rendering engine. ### Client-Side Rendering Bottlenecks * Performance profiling indicates that the delay is localized to the client-side rendering phase rather than the network or server. * Initial rendering includes a skeleton UI period of roughly 900ms, followed by sequential text animations that push the final paint time back. * Comparative data shows that when AIB is the LCP candidate, the p75 value reaches 4.5 seconds—significantly slower than other heavy components like map modules. ### Structural Misalignment with LCP Measurement * **DOM Reconstruction:** After text animations finish, AIB rebuilds the DOM to enable citation highlighting and hover interactions, which triggers Chromium to update the LCP timestamp to this much later point. * **Candidate Fragmentation:** Streaming text at the word level prevents the browser from identifying a single large text block; instead, small, insignificant fragments are often incorrectly selected as the LCP candidate. * **Paint Invalidation:** Chromium’s rendering pipeline treats every new word in a streaming response as a layer update, causing repeated paint invalidations that push the `renderTime` forward frame-by-frame until the entire message is complete. ### New Metrics for AI-Driven Interfaces * To more accurately reflect user experience, Naver is shifting toward Time to First Token (TTFT) as a primary metric for AIB, focusing on how quickly the first meaningful response appears. * Standard LCP remains a valid quality indicator for static search results, but it is no longer treated as a universal benchmark for interactive AI components. * Future performance management will involve more granular distribution analysis and "predictive" performance modeling rather than simply optimizing for a single threshold like the 2.5-second LCP mark. To effectively manage performance in the era of generative AI, organizations should move away from relying solely on LCP for streaming interfaces. Implementing TTFT as a complementary metric provides a better representation of perceived speed, while optimizing the timing of DOM reconstructions can prevent unnecessary measurement delays in Chromium-based browsers.

figma2 min readCurated summary

Introducing BrowserView for Electron | Figma Blog

Figma introduced BrowserView for Electron to address the performance, stability, and feature bugs it experienced with `<webview>`. BrowserView embeds web apps at the operating-system window level, similar to Chrome tabs, allowing them to perform more like native Chrome content. Although it requires manual positioning and layering, Figma found the trade-off worthwhile and shipped it in Figma Desktop 2.0. ## Why Figma Chose Electron - Figma uses the web to make its design tools broadly accessible. - Its desktop app is built with Electron, extending the web experience to desktop platforms. - Figma had already improved performance through technologies such as WebGL and WebAssembly. - The company also contributed fixes and improvements to Electron and Chromium. ## Problems with `<webview>` - Electron commonly uses `<webview>` to embed remote web applications. - Unlike an iframe, a webview renders content in a separate process, improving security, stability, and performance. - Over time, Figma encountered: - Drag-and-drop bugs - Performance below that of Chrome - Other fundamental reliability issues - Because webview is implemented inside Chromium, fixing its underlying problems would require major Chromium changes. - Figma and Electron maintainers therefore chose to develop an alternative rather than continue waiting for Chromium fixes. ## How BrowserView Works - `<webview>` exists within the page’s DOM hierarchy. - BrowserView lives in the operating system’s window hierarchy, much like Chrome’s browser tabs. - This design benefits from the more mature and actively maintained code paths used for Chrome tabs. - BrowserView eliminates many webview-specific bugs. - Applications embedded through BrowserView can perform similarly to applications running directly in Chrome. ## Trade-offs and Adoption - BrowserViews cannot be positioned or layered using ordinary HTML and CSS. - Developers must manually manage their size, location, and stacking order. - This can be difficult for applications with complex interfaces. - For Figma, converting to BrowserView was relatively straightforward. - At the time of publication, BrowserView was experimental and still planned for further refinement. Figma recommends BrowserView as a promising replacement for `<webview>` when improved performance and reliability outweigh the added layout complexity.

Read original(opens in new tab)