I once took over a project for a boutique design agency with an enormous “inspiration” gallery: 14 years of high-resolution assets, not far off the monthly wallpaper tradition Smashing Magazine keeps up. Their admin dashboard was timing out and the front-end gallery needed nearly 12 seconds to load, which is rough for a portfolio meant to sell design work.
Under the hood it was what I expected. The previous dev used standard loops to fetch every resolution for every image in one go. Look at the November 2025 Wallpapers Edition and you will see a single design can carry 20 or more resolution links. Multiply that by a hundred images on a page and the metadata requests alone are enough to take your own server down.
Optimizing high-resolution image management for WordPress
My first thought, and this was the mistake, was to drop the whole mess into a transient. Cache the array of resolution URLs, save the database hits. It worked for roughly ten minutes. Then the client started batch-uploading new assets, the transient outgrew the memory allowed for the options table, and the site hung. All I had really done was make the same bad structure answer faster until it broke.
Caching was never going to fix this on its own, because the retrieval itself needed rethinking. Rather than calling get_post_meta for every resolution link, we needed to build those links from a naming convention or the CDN’s folder structure. That matters even more once several aspect ratios and device sizes are in play.
<?php
/**
* Efficiently generate resolution links without a thousand DB hits.
*/
function bbioon_get_optimized_asset_resolutions( $attachment_id, $slug ) {
$base_url = 'https://cdn.example.com/wallpapers/' . $slug . '/';
$resolutions = [
'1920x1080', '2560x1440', '3840x2160', '1024x1024'
];
$output = [];
foreach ( $resolutions as $res ) {
// We assume a naming convention here to avoid checking file_exists on every hit
$output[$res] = sprintf( '%snov-25-%s-cal-%s.png', $base_url, $slug, $res );
}
return $output;
}
?>Moving to a predictable naming convention and pushing the assets into a dedicated bucket got the download links out from under the WordPress media library’s overhead. The local library now holds only the source image, and logic handles the rest. It is more work upfront, and it is the reason the gallery stays upright when the November traffic arrives.
Do not lazy-load your logic
Plenty of devs treat optimization as installing a plugin and walking away. With a decade of data behind the site, a plugin only covers the symptom. What you need to look at is how the data moves from the server to the client, because the metadata on a single post can turn into the bottleneck by itself.
- Avoid
get_post_metain deep loops for static assets. - Use a CDN with a predictable folder structure.
- Never store large arrays in the
wp_optionstable.
A ten-year-old media library hides a lot. If yours is timing out and you would rather not go spelunking through it yourself, drop my team a line.
If everything still sits in the local uploads folder, an S3-compatible offload is probably your next job. Curious what has worked for other people in the comments.
