Google is testing the Chrome 148 lazy-loading update, a change that could speed up browsing by delaying the loading of off-screen audio and video elements. The feature is now in development and is expected to roll out in mid-April.
Lazy loading helps pages load faster by deferring the loading of content that is not yet visible. As a result, browsers can reduce unnecessary data use and improve page load performance. Lazy loading is already familiar to many web users. For example, on a page filled with images, a browser does not need to load every image at once before the page becomes usable.
Instead, it can load only the content currently in view and defer loading the rest until the user scrolls. This makes browsing feel quicker and more efficient. With Chrome 148, Google is testing the same approach for video and audio elements. That would expand built-in lazy loading beyond its current support for images and frames.
Right now, built-in lazy loading in Chrome and other Chromium-based browsers mainly supports images and frames. If this test moves forward, video and audio content would be added to that list. However, the change will not affect YouTube video embeds. YouTube embeds already benefit from lazy loading because they are typically loaded through frames
That distinction matters because it shows Google is extending an existing performance tool rather than introducing a completely new system. The update is scheduled to be enabled for users across several platforms, including desktop, Android, and iOS. The same report also suggests that other Chromium-based browsers, such as Edge and Vivaldi, may also receive the feature.
That could make the update relevant beyond Chrome alone, especially for users who rely on Chromium browsers for everyday browsing. Google is not only testing media lazy loading. The company is working on a problem related to Chrome’s split-view feature.
Read: Google Play Store Update Adds Review Search Bar
As part of that change, Chrome will move the split-view option to the context menu. It will also adjust the drag-and-drop thresholds that trigger the feature. While that is separate from page speed, it shows Google is refining both performance and usability in the same update cycle.
Native loading=”lazy” vs. JavaScript (Intersection Observer) Workarounds. Native support is expected to outperform custom JS implementations in most cases:
| Aspect | Native loading=”lazy” (Chrome 148+) | JavaScript + Intersection Observer |
|---|---|---|
| Integration with Browser | Excellent – works with preload scanner, network heuristics, autoplay/preload handling | Limited – runs alongside browser logic, can conflict |
| Main Thread Impact | None (fully asynchronous) | Some overhead from JS execution and observers |
| onload Blocking | Does not block | Often indirectly affects perceived load time |
| Error-Prone | Very low | Higher (manual src swapping, edge cases) |
| Maintenance | Zero JS needed | Requires code, testing across browsers |
| Performance Edge | Better overall (especially on complex pages) | Good, but not as optimized |
