WebView feels laggy on heavy pages (GitHub PRs with large diffs)

[bnema]

Bug Description

When browsing GitHub PRs with lots of files and git diffs, the WebView feels laggy, especially during scroll loading (lazy loading of diff content). The scrolling is not smooth and the page feels unresponsive.

Environment

• Heavy pages like GitHub PR file diffs
• Pages with lots of DOM elements and lazy-loaded content

Current WebKit Configuration

After reviewing the codebase, here's the current performance-related setup:

Settings Applied (internal/infrastructure/webkit/settings.go)

• SetEnableSmoothScrolling(true) - smooth scrolling enabled
• SetEnablePageCache(true) - page cache enabled
• SetEnable2dCanvasAcceleration(true) - 2D canvas acceleration
• SetHardwareAccelerationPolicy - configurable (auto/gpu/cpu)
• SetCacheModel(webkit.CacheModelWebBrowserValue) - browser-style caching

WebKit Context (internal/infrastructure/webkit/context.go)

• Single shared NetworkSession for all WebViews
• Browser-style cache model

What's NOT Configured

1. No web process limits - WebKit can spawn unlimited web processes
2. No memory pressure handling - No mechanism to release memory under pressure
3. No process-per-site-instance configuration
4. No JavaScript garbage collection hints

Potential Performance Improvements

1. WebKit Process Model Configuration

WebKitGTK supports different process models:

• WEBKIT_PROCESS_MODEL_MULTIPLE_SECONDARY_PROCESSES (default) - one process per page
• WEBKIT_PROCESS_MODEL_SHARED_SECONDARY_PROCESS - single shared process (less isolation, less memory)

Consider exposing this as a config option for users with limited RAM.

2. Memory Pressure Handling

WebKit has webkit_website_data_manager_set_memory_pressure_settings() which could help with:

• Memory limit thresholds
• Poll interval for memory monitoring
• Kill threshold for web processes

3. Web Process Count Limit

webkit_web_context_set_web_process_count_limit() can limit the number of web processes.

4. JavaScript/DOM Performance

• Consider using webkit_settings_set_enable_javascript_markup(false) for read-heavy pages
• webkit_settings_set_enable_smooth_scrolling() is already enabled

5. GPU Compositing Tuning

Current config exposes these env vars but they might need better defaults:

• WEBKIT_FORCE_COMPOSITING_MODE - force GPU compositing
• WEBKIT_DISABLE_DMABUF_RENDERER - for problematic GPU drivers

6. Network Session Configuration

• Consider enabling webkit_network_session_set_itp_enabled(false) if privacy features cause overhead
• Prefetch/preconnect hints for known heavy sites

Investigation Needed

1. Profile actual WebKit performance on GitHub PR pages
2. Check if issue is CPU-bound (JS execution) or GPU-bound (compositing)
3. Monitor memory usage during scroll on heavy pages
4. Test with different hardware_acceleration config values
5. Compare with other WebKitGTK browsers (GNOME Web, Tangram)

Related Files

• internal/infrastructure/webkit/settings.go - WebKit settings
• internal/infrastructure/webkit/context.go - WebContext/NetworkSession setup
• internal/infrastructure/webkit/webview.go - WebView creation
• internal/infrastructure/webkit/pool.go - WebView pooling
• internal/infrastructure/config/schema.go - RenderingConfig, PerformanceConfig

User-Facing Config Options to Consider

[performance]
# Web process memory limit in MB (0 = unlimited)
web_process_memory_limit_mb = 512

# Maximum concurrent web processes (0 = unlimited)  
max_web_processes = 4

# Use shared web process model (less memory, less isolation)
shared_web_process = false