How can I load optional data without delaying the main content?

Treat them as two jobs with separate rendering paths. The main view should depend only on its essential request. As soon as that result is ready, render it. The optional section can initially say it is loading, then show recommendations, an empty state, or a failure message.

Here’s a small example using invented local data. The render... functions stand in for your application’s UI updates:

const localItems = [
  { id: 1, name: "Notebook" },
  { id: 2, name: "Pencil" }
];
const localRecommendations = ["Eraser", "Ruler"];

const getItems = () => Promise.resolve(localItems);
const getRecommendations = () => Promise.resolve(localRecommendations);

async function loadPage() {
  renderItemsLoading();
  renderRecommendationsStatus("Loading recommendations…");

  // Handle optional success or failure independently, without waiting here.
  const recommendationsTask = Promise.resolve()
    .then(() => getRecommendations())
    .then((recommendations) => {
      if (recommendations.length === 0) {
        renderRecommendationsStatus("No recommendations to show.");
      } else {
        renderRecommendations(recommendations);
      }
    })
    .catch(() => {
      renderRecommendationsStatus(
        "Recommendations are unavailable. The main list is still ready."
      );
    });

  try {
    const items = await getItems();
    renderItems(items);
  } catch (error) {
    renderItemsError("The main list could not be loaded.");
  }
}

The optional task handles its own failure, including a synchronous error from getRecommendations(). It doesn’t hold up the await getItems() path. The example functions and render functions are placeholders; replace them with your application’s data and UI.

Promise.all() waits for all promises in its group to fulfill before its combined promise fulfills, and rejects if any promise rejects [S1]. If you render the main view only after awaiting a Promise.all() containing both requests, a slow optional request can delay that render, and an optional failure can send the combined operation to its error handling.

You can use Promise.all() when both results are required before the next step. For this task, keep the essential request as the gate for the main view and handle the optional request independently. Promise.allSettled() reports each outcome after all promises settle [S1], which can help when you want to collect results together, but it does not itself make the primary view render sooner. The timing and status display are application-level choices; the promise reference does not prescribe a UI pattern.

Give that section its own small set of states, with wording that reflects what happened:

1. Loading: “Loading recommendations…”
2. Success: show the recommendations.
3. Empty result: “No recommendations to show.”
4. Failure: “Recommendations are unavailable. You can still use the main list.”

These messages are examples, not required wording. The useful distinction is between a successful response with no items and a request failure; don’t present one as the other. Keep the status within the optional section so it doesn’t replace or obscure the main content. If you add a retry control, make it retry only the optional request unless the main data also needs refreshing.

Use this checklist, then check the three optional outcomes with controlled example results: success, an empty result, and failure. Also try a slow optional result while the essential result is ready; confirm the main view can render before the optional result arrives. These are implementation checks for your application, not claims about a particular framework or performance outcome.

Copyable status plan:

Main section: loading → content OR main-data error
Optional section: loading → content OR empty OR optional-data error
Optional failure: keep main content available

Keep the optional task’s error handling close to its status update. That makes it easier to see that an optional failure changes the optional section, not the essential view.