How to Eliminate Front‑End Image Layout Shift with Smart Placeholder Optimization

1 Background

In frontend development we usually use the <img> tag to load images, which only appear after the first screen is rendered, causing layout shift.

To avoid this, a 1px gray placeholder image is used as src before the real image loads, but this still does not fully eliminate shift.

We observed that both during first‑screen rendering and when the image finishes loading, the page shifts because the gray placeholder height differs from the real image height.

After first‑screen rendering, loading the gray placeholder causes severe shift.

Because the real image height differs from the placeholder, a slight shift occurs.

This article shares the optimization process for image placeholders.

2 Current Situation Analysis

The severe first‑screen shift is caused by the placeholder code which runs after two TTFB times due to loader.js and main.js. Only after main.js executes does the gray placeholder appear.

Since there are two TTFB times, the simplest method is to inline the placeholder logic into index.html. After inlining, there are three possible trigger points for the placeholder logic:

Trigger after window.onload.

Trigger after DOMContentLoaded.

Inline directly without listening to events.

The placeholder logic accesses offsetTop, clientWidth and similar properties, so we need to ensure these properties can be correctly obtained at each trigger point, which involves understanding the browser rendering process.

2.1 Browser Rendering Process

The rendering steps are: build DOM tree, build CSSOM, construct render tree, calculate layout, paint, and composite.

Layout calculation triggers when the browser needs element size or position, e.g., when getComputedStyle or offset* is accessed. Therefore, measuring properties synchronously triggers layout, allowing offsetTop and clientWidth to be obtained correctly at all three trigger points.

Since layout is triggered by accessing offsetTop, we can use DOMContentLoaded to replace window.onload for the placeholder logic.

Experiments show iOS WebView renders the first screen after DOMContentLoaded, while Android renders after the first <script> before . Both DOMContentLoaded and direct inlining solve the shift on iOS; Android still has a brief shift. DOMContentLoaded does not affect later inline JS execution, so we choose DOMContentLoaded to trigger the placeholder.

After optimization, the gray placeholder is rendered synchronously with the first screen, eliminating the severe shift.

2.2 Better Calculation of Placeholder Height

The second shift is due to the method of calculating placeholder height.

Original formula:

placeholder height = data‑ratio * Math.min(screen width, data‑w)

. When data‑w is smaller than screen width, the height is correct; when data‑w exceeds screen width, the height may be incorrect because screen width is used as the baseline.

We need a better baseline: find the nearest ancestor element with non‑zero width and use the smaller of that width and the image’s actual width as the placeholder width, then multiply by the aspect ratio to get the placeholder height.

After this optimization, the gray placeholder matches the actual image height.

3 Conclusion

Final optimized effect shows all images have correct placeholders and no shift after loading.

Summary of the placeholder solution in three steps:

Inline placeholder code in index.html and trigger it in DOMContentLoaded using offset* to force layout.

Find the nearest ancestor with non‑zero width and use the minimum of that width and the image’s actual width as placeholder width.

Multiply placeholder width by the image’s aspect ratio to obtain placeholder height.

Other methods such as padding‑top + absolute positioning or SVG placeholders also exist.