Safari Timelines: Layout, Rendering, and CPU Usage

This article provides a direct overview of the Timelines tab within the Safari Web Inspector, specifically focusing on how it tracks layout, rendering, and CPU usage. By examining the exact metrics, thread activity, and visual data provided by these specific timelines, web developers can quickly identify performance bottlenecks, eliminate page stutter, and reduce battery drain on macOS and iOS devices.

The Layout & Rendering Timeline

The Layout & Rendering timeline records every visual update made to the web page. It breaks down the browser's rendering pipeline into four distinct event types, allowing you to see exactly why and when the browser is forced to redraw the screen.

1. Event Types Tracked

  • Styles (Recalculate Styles): Triggered when CSS rules are changed or DOM elements are modified. This shows the time Safari spends calculating which CSS rules apply to which elements.
  • Layout: Triggered when changes to styles affect the geometry (position or size) of elements. The timeline records when the browser has to reflow the page and calculate the new coordinates for affected nodes.
  • Paint: Occurs after layout is complete. This event tracks the time taken to fill in pixels for text, colors, images, borders, and shadows into memory layers.
  • Composite: The final step where Safari takes the painted layers, combines them, and sends them to the GPU to be drawn on the screen.

2. Detailed Metrics Provided

For every recorded event in the Layout & Rendering timeline, Safari provides a data table containing the following specifics:

  • Initiator: The exact line of JavaScript code or CSS change that triggered the rendering event. Clicking this jumps directly to the source code.
  • Duration: The exact time (in milliseconds) the browser spent executing the task.
  • Area / Dimensions: For Paint and Layout events, Safari records the pixel dimensions (width and height) of the updated region on the screen.
  • DOM Nodes: The specific DOM node that served as the root for the layout or paint operation.

The CPU Timeline

The CPU timeline measures the processing power your web page requires to run, helping you optimize for both speed and battery efficiency.

1. Energy Impact Gauge

At the top of the CPU timeline, Safari displays an Energy Impact dial, categorized into Low, Medium, High, and Very High. This calculates the overall power consumption of the page over the recorded timeframe. Maintaining a "Low" impact ensures the webpage will not rapidly drain laptop or mobile device batteries or cause hardware fans to spin up.

2. Thread Breakdown

The timeline visualizes CPU usage as a percentage graph over time and separates this usage into specific system threads:

  • Main Thread: Displays the workload of the primary thread, which handles the DOM, layout, painting, and most JavaScript execution. If the Main Thread hits 100%, the page becomes unresponsive to user input.
  • Worker Threads: Shows CPU usage for background scripts, such as Web Workers and Service Workers.
  • WebKit Threads: Tracks background tasks managed by the browser engine itself, such as audio processing, garbage collection, and network data decoding.

3. Workload Categorization

When you select a specific time range in the CPU timeline, Safari breaks down the Main Thread activity into color-coded categories, showing the exact millisecond and percentage split between:

  • Script: Time spent executing JavaScript, including event listeners, timers, and animations.
  • Layout: Time spent recalculating styles and document geometry.
  • Paint: Time spent rasterizing elements and compositing layers.
  • Other: Internal browser tasks required to keep the page running.

Correlating Data with Rendering Frames

When switching the Timelines view mode from "Events" to "Rendering Frames," Safari combines CPU, Layout, and Rendering data into vertical bars. Each bar represents a single frame of animation.

This view clearly illustrates whether the combination of CPU processing and Layout/Rendering tasks is completing within the 16.6-millisecond window required for a smooth 60 frames per second (FPS) experience. Frames that exceed this threshold are highlighted, showing the exact ratio of Scripting, Layout, and Painting that caused the dropped frame.