TL;DR — Quick Summary
The window load event fires when the entire page — including all images, stylesheets, scripts, and subframes — has fully loaded. Mostly replaced by CWV for performance measurement but still useful for resource-dependent scripts.
What is Window Load Event?
The window load event (window.onload) fires when the entire page has fully loaded, including all dependent resources.
Load order:
- 1DOMContentLoaded — HTML parsed, DOM ready.
- 2Window load — All resources loaded (images, CSS, iframes).
- 3Fully Loaded — All async/post-load resources complete.
History & Evolution
- •1990s — window.onload is the only reliable 'page ready' signal.
- •2004 — DOMContentLoaded provides an earlier DOM-ready signal.
- •2010s — Performance analysis shifts to user-centric metrics.
- •2020 — Core Web Vitals replace load-time-based measurement.
- •2025–2026 — Load event remains in DevTools as a reference marker.
How Window Load Event is Measured
Available via window.addEventListener('load', ...) and Navigation Timing API. Visible in Chrome DevTools Network panel as a red vertical line. Reported by WebPageTest in metrics summary.
Key rule: Field data (CrUX) determines Google rankings. Lab data (Lighthouse, WebPageTest) is for debugging and iteration.
Common Causes of Poor Window Load Event Scores
- 1Large/numerous images — Every image must download.
- 2Third-party scripts — External scripts and dependencies.
- 3Iframes — Each iframe is a full page load.
- 4Large fonts — Multiple non-subsetted font files.
- 5No lazy loading — All resources load immediately.
Frequently Asked Questions
For step-by-step optimization, platform-specific fixes, code examples, and case studies, read our full guide:
The Ultimate Guide to Website Performance Measurement, Tools & Data: Lab, Field & Everything Between in 2026Struggling with Window Load Event?
Request a free speed audit and we'll identify exactly what's holding your scores back.