Introduction

You generally do not "disable the whole HTML page" in a literal browser sense. The usual solution is to place a full-screen overlay above the page, block pointer input, and remove that overlay only after every required jQuery .load() call has finished.

Use an Overlay Instead of Disabling Elements One by One

If you try to disable every button, link, and form field individually, you will miss edge cases and create brittle code. A single overlay is simpler because it blocks interaction everywhere at once.

A basic page structure looks like this:

1<div id="loading-overlay">Loading...</div>
2<div id="content">
3  <div id="header"></div>
4  <div id="sidebar"></div>
5  <div id="main"></div>
6</div>

Add CSS so the overlay covers the viewport:

1#loading-overlay {
2  position: fixed;
3  inset: 0;
4  display: flex;
5  align-items: center;
6  justify-content: center;
7  background: rgba(255, 255, 255, 0.85);
8  z-index: 9999;
9}
10
11#loading-overlay.hidden {
12  display: none;
13}

When the overlay is visible, the user cannot interact with the page underneath it.

Wait for All .load() Calls to Finish

The important part is tracking how many asynchronous .load() calls are still running. If you hide the overlay after only the first callback, the page becomes interactive too early.

A simple counter works well:

1$(function () {
2  let pendingLoads = 3;
3
4  function finishLoad() {
5    pendingLoads -= 1;
6    if (pendingLoads === 0) {
7      $("#loading-overlay").addClass("hidden");
8    }
9  }
10
11  $("#header").load("/partials/header.html", finishLoad);
12  $("#sidebar").load("/partials/sidebar.html", finishLoad);
13  $("#main").load("/partials/main.html", finishLoad);
14});

This approach keeps the overlay visible until all three sections finish loading.

Handle Success and Failure Explicitly

jQuery .load() callbacks receive a status string. You should handle errors rather than assuming success.

1$(function () {
2  let pendingLoads = 2;
3
4  function finishLoad(responseText, statusText, xhr) {
5    if (statusText !== "success") {
6      console.error("Load failed:", xhr.status, xhr.statusText);
7    }
8
9    pendingLoads -= 1;
10    if (pendingLoads === 0) {
11      $("#loading-overlay").addClass("hidden");
12    }
13  }
14
15  $("#header").load("/partials/header.html", finishLoad);
16  $("#main").load("/partials/main.html", finishLoad);
17});

Even on error, decrement the counter so the overlay does not remain stuck forever. If the page cannot function without a missing section, replace the overlay text with a failure message instead of simply hiding it.

A Promise-Style Alternative

If you are not forced to use .load(), modern code is often clearer with $.get() or fetch() plus Promise coordination. But if the existing codebase is already built around .load(), the counter-based solution stays close to the jQuery pattern and is easy to maintain.

The key principle is the same either way: block interaction until all required asynchronous work is complete.

User Experience Still Matters

Blocking the entire page is acceptable during initial setup, but keep the blocked period short. If the loading step takes noticeable time, add a spinner or a short explanatory message so the page does not look frozen.

You should also decide whether the whole page really needs to wait. Sometimes it is better to let the shell render immediately and only disable the section that depends on the unfinished request. Full-page blocking is best reserved for cases where partial interaction would break the workflow.

Common Pitfalls

• Hiding the overlay after the first .load() callback finishes allows interaction before the rest of the page is ready.
• Forgetting to decrement the pending counter on error can leave the overlay visible forever.
• Trying to disable every individual element instead of using one overlay creates unnecessary complexity.
• Blocking the full page for optional content hurts usability when only one section actually depends on the request.
• Assuming .load() is synchronous leads to timing bugs because the page continues executing while the request is still in flight.

Summary

• The practical solution is a full-page overlay, not literal browser-wide disabling.
• Count outstanding .load() calls and remove the overlay only when all required requests finish.
• Handle both success and failure so the UI cannot get stuck in a loading state.
• Use full-page blocking only when partial interaction would be incorrect.
• If you can modernize later, Promise-based request coordination is often easier to extend than many .load() callbacks.