PD Hero Image Preload
Auto-preloads the above-the-fold Divi hero background image to fix CSS-background LCP discovery delay on mobile. No template edits, no per-site config, fleet-scalable.
Install
This is the repository archive. It installs, but the folder name will carry the branch suffix and updates will not flow.
Install straight from GitHub with WP-CLI:
wp plugin install https://github.com/pressable/pressable-solutions-divi-hero-preload/archive/refs/heads/main.zipDivi Hero Image Preload
A tiny WordPress plugin that fixes the single most common Largest Contentful Paint (LCP) bottleneck on Divi sites.
The problem
Divi renders section / row / column backgrounds as CSS background-images whose URLs live in Divi's generated stylesheet. The browser can't discover the above-the-fold hero image until that stylesheet has downloaded and parsed — which on a throttled mobile connection adds roughly 0.5–1 second of "load delay" before the hero even starts fetching. Lighthouse/PageSpeed flags this as "LCP request discovery: Request is discoverable in initial document — failed." It is the dominant LCP cost on most Divi brochure sites, and <img>-targeting preload tools (including page-builder/cache-plugin "critical image" features) miss it because the hero is a CSS background, not an <img>.
What this does
On every singular front-end view it reads the current page's Divi layout, finds the first above-the-fold background image(s) on et_pb_section / et_pb_row / et_pb_column / et_pb_fullwidth_header, and emits an early:
<link rel="preload" as="image" href="…hero.jpg" fetchpriority="high">so the browser fetches the hero immediately, in parallel with the CSS, instead of waiting for it.
Mobile-correct. When Divi has a phone-specific background (background_image_phone with background_enable_image_phone="on"), the phone image is preloaded under media="(max-width: 767px)" and the desktop image under media="(min-width: 768px)", so mobile PageSpeed preloads the asset mobile actually uses and no bytes are wasted.
No template edits. No per-site configuration. Drop it in and it works.
Install
Either:
- mu-plugin (recommended for fleets): copy
pd-hero-preload.phpintowp-content/mu-plugins/. It auto-loads — nothing to activate, and it can't be deactivated by a site admin. - Regular plugin: copy into
wp-content/plugins/pd-hero-preload/and activate from the Plugins screen.
Filters
| Filter | Default | Purpose |
|---|---|---|
pd_hero_preload_max |
2 |
Number of hero backgrounds to preload. |
pd_hero_preload_scan |
30 |
How many leading Divi structural elements to scan for backgrounds. |
pd_hero_preload_phone_bp |
767 |
Divi phone breakpoint, in px. |
Scope and limitations
- Reads backgrounds from post content. Heroes built entirely in the Divi Theme Builder (stored as separate
et_templateposts rather than in the page content) are not parsed yet — that's the planned next iteration. - Singular front-end views only (
is_singular()), skips admin / feeds / REST. - Targets the CSS-background LCP discovery delay specifically. The remaining LCP component on heavy sites is render delay (Divi paint time, preloader plugins, plugin weight), which is a theme/plugin concern, not a discovery one.
Validation
Tested on Divi, WordPress 7.0, PHP 8.5, Pressable. Validated across a five-site Divi cohort under mobile PageSpeed-style throttling (4× CPU / Slow 4G / mobile viewport): cut LCP load delay from ~1000 ms to under 600 ms (as low as ~30 ms on lighter sites), and removed Lighthouse's "LCP request discovery" finding entirely. Auto-detection picked the correct hero on five structurally different layouts (section-, gradient-, and column-background heroes) with zero per-site configuration.
License
GPL-2.0-or-later.