Website speed is crucial for user retention, particularly in the mobile-first landscape. Snowplow enables precise measurement of page load times through the Performance Timing context, allowing data engineers and architects to capture granular performance data and troubleshoot effectively. In this Q&A-style post, we explore how to measure page load times using the Performance Timing context and aggregate that data in Redshift.

Q: What is the Performance Timing context?

The Performance Timing context in Snowplow leverages the Navigation Timing API to capture key milestones in the page loading process. It records attributes such as navigationStart, domLoading, and loadEventEnd, providing a detailed breakdown of load times from initial navigation to complete page rendering.

Q: How do I enable the Performance Timing context?

To activate the Performance Timing context, modify the JavaScript tracker configuration as follows:

'contexts': {

  'webPage': true,

  'performanceTiming': true

}

Ensure the corresponding tables are created in Redshift to store this data. The tracker will generate a JSON context object from the window.performance.timing object, along with the chromeFirstPaint field if available.

Q: How do I handle incomplete or missing data?

When firing a page view event as soon as the page loads, certain attributes like domComplete or loadEventEnd may not yet be populated. To mitigate this, consider using page ping events to update performance timing attributes:

snowplow('enableActivityTracking', 5, 10);

This configuration sends the first page ping 5 seconds after the page view event and subsequent pings every 10 seconds. This method ensures that more complete data is captured, particularly for long-loading pages.

Q: How can I aggregate Performance Timing data in Redshift?

A basic SQL query can aggregate page view and page ping events to calculate key load time metrics. Here's an example:

WITH basic AS (

  SELECT

    b.id,

    a.derived_tstamp,

    a.page_urlhost,

    a.page_urlpath,

    c.navigation_start,

    c.load_event_end

  FROM atomic.events AS a

  INNER JOIN atomic.com_snowplowanalytics_snowplow_web_page_1 AS b

    ON a.event_id = b.root_id

  INNER JOIN atomic.org_w3_performance_timing_1 AS c

    ON a.event_id = c.root_id

  WHERE a.event IN ('page_view','page_ping')

)

‍

SELECT

  id,

  MIN(derived_tstamp) AS first_event,

  MAX(load_event_end) - MIN(navigation_start) AS total_load_time_ms

FROM basic

GROUP BY id;

This query calculates the total load time by subtracting navigation_start from load_event_end. Similar queries can be used to track specific milestones or compare load times across sessions or user segments.

Q: What are the best practices for optimizing page load time analysis in Snowplow?

• Enable Web Page and Performance Timing contexts to capture relevant data.
  
  
• Use page ping events to update timing data for longer sessions.
  
  
• Aggregate data in Redshift to streamline reporting and reduce query complexity.
  
  
• Segment by browser, device, and referrer to identify specific areas for optimization.
  
  

Final Thoughts

Measuring page load times using the Performance Timing context provides valuable insights into user experience and website performance. By enabling this context and effectively aggregating the data, Snowplow users can diagnose slow-loading pages, pinpoint bottlenecks, and optimize performance across devices.

Stay tuned for further posts on integrating this data into dashboards and monitoring frameworks.