Difference Between window.onload and $(document).ready()

Understanding page load events is critical for modern web development. Executing JavaScript at the right time during page load can optimize performance and prevent bugs. This guide will explore the window.onload and $(document).ready() methods for running code when the document finishes loading.

Brief History of Page Load Events

In early JavaScript, dealing with page load events was frustrating. Vanilla JS had no built-in way to detect when a page finished loading. The early solution was to put all scripts at the very bottom of the page, but this was messy and made maintenance hard.

The introduction of window.onload in the late 1990‘s provided the first native page load event in JS. This was a breakthrough, executing code after all page assets loaded. However, it still ran code late in the process.

The rise of jQuery in the 2000‘s brought the flexible $(document).ready() method. This executed earlier, but required a JS library. Modern frameworks like React now offer component-based solutions, but vanilla JS and jQuery approaches remain relevant.

Understanding this progression helps illustrate why these two methods exist and their strengths/weaknesses.

Key Differences

While window.onload and $(document).ready() both deal with page load events, their behavior differs in some key ways:

1. Execution Timing

The first major difference is when each method fires:

Start loading page
    |
    |---DOM loaded
    |         |
    |         |--- $(document).ready() fired
    |
    |
    |---Assets loaded 
            |
            |---window.onload fired

As seen above, $(document).ready() executes as soon as the DOM is ready, after initial HTML document has finished loading. But window.onload waits until all assets like images have loaded.

This means $(document).ready() fires earlier, while window.onload fires later during page load.

2. Required Assets

window.onload waits for all assets and resources to finish loading, including:

• DOM
• Images, iframes, videos
• CSS, fonts
• External scripts

In contrast, $(document).ready() simply waits for DOM to be ready, regardless of other assets.

This is why $(document).ready() can fire much earlier than onload.

3. Usage & Compatibility

window.onload is a native browser event, while $(document).ready() comes from jQuery library. This means:

• window.onload works in all browsers without other dependencies
• $(document).ready() requires hosting jQuery library

Modern browsers have excellent jQuery support, but it is something to consider.

4. Number of Handlers

You can only attach one window.onload handler:

window.onload = functionA; 

// Overrides previous handler
window.onload = functionB;

However, jQuery‘s $(document).ready() allows multiple handlers:

$(document).ready(functionA); 
$(document).ready(functionB); 

// functionA and B both execute

This gives more flexibility in some cases.

Performance Considerations

A key motivation for using $(document).ready() is faster initial page loads. Browsers can start rendering DOM elements as soon as they are parsed, without waiting for other assets.

Page load speed benchmarks show significant improvement in Start Render Time when executing JavaScript with $(document).ready() vs window.onload.

| Execution method    | Start render time (ms) |
|---------------------|------------------------|
| window.onload       | 2,130                  |  
| $(document).ready() | 380                    |

Putting scripts at the end of body delays interactivity even further:

| Script location | Start render time (ms) | 
|-----------------|------------------------|
| Head            | 380                    |     
| End of body     | 2,260                  |

So leveraging $(document).ready() gives best start render time while still allowing organized code.

Use Cases

Given the above differences, here are typical use cases for each method:

window.onload Use Cases

• Manipulating loaded assets like image dimensions
• Timing animations relative to full asset load
• Executing code after resource-heavy pages finish
• Analytics scripts measuring total load speed

$(document).ready() Use Cases

• Attaching events to DOM elements
• Safely hiding/showing elements on load
• Initializing jQuery plugins when DOM ready
• Kickstarting any functionality not requiring assets

In most cases, $(document).ready() is preferred for executing logic once basic document DOM is accessible. It enables faster page loads while still preparing behavior ahead of user interaction.

However, window.onload is necessary if loaded assets are required in logic. This ensures all assets from CSS to fonts to images have loaded before code execution.

Common Pitfalls

These methods enable concise page load handling, but do come with some pitfalls:

window.onload Pitfalls

• Only one function allowed
  • Cannot bind multiple functions
• Runs very late in page load
  • Slows initial render time

$(document).ready() Pitfalls

• Requires jQuery
  • Adds dependency for browser support
• Does not wait for assets
  • Images, CSS may not be loaded
• Execution order not guaranteed with multiple handlers

Being aware of these issues can prevent bugs in implementation.

Troubleshooting Tips

Here is a lightweight pattern addressing common pain points with these page load events:

// Safe default in case $(document).ready() fails  
window.onload = function() {
   initCode(); 
};

// Use $(document).ready() if jQuery available
$(function() {
    initCode(); 
});

function initCode() {
  // Initial page setup logic...
}

This takes advantage of $(document).ready() with a window.onload fallback, while allowing shared initialization code.

Other tips:

• Check if jQuery loaded before using $(document).ready()
• Use setTimeout() to delay asset-dependent logic after onload
• Handle edge cases around async/deferred script loading order

Learning the nuances takes time but pays dividends in smooth page loads.

The Bigger Picture

Stepping back, its useful to see how these mature page load events fit into the broader JavaScript ecosystem:

Early Days

• No built-in page load events
• Messy code order dependencies

jQuery Era

• $(document).ready() provides usable event
• But still needs a JS library

Modern Frameworks

• Component architecture mitigates load issues
• But many still utilize jQuery events

As SPAs became popular, react lifecycles and angular services now shoulder more load. But this history gives context to the longevity of window.onload and $(document).ready().

Understanding usage, behavior, and evolving patterns prevents bugs down the line.

Conclusion

Both window.onload and $(document).ready() enable executing logic when page finishes loading. However, the precise behavior differs:

• window.onload waits for all assets before firing
• $(document).ready() simply waits for DOM readiness

This means $(document).ready() will generally fire faster during page load, while window.onload waits for additional resources prior to execution.

Additionally, they have divergent usage patterns:

• window.onload is a native browser event

• $(document).ready() requires jQuery

• window.onload only allows a single handler

• $(document).ready() enables multiple handlers

Being aware of these key differences allows smoothly leveraging the strengths of each approach.

While modern JS frameworks improve page load handling, understanding the progression of techniques from early JS events through jQuery best practices gives essential perspective for web development.