How Can Image-Heavy Websites Use CDN? How to Test Caching, Formats, and Loading Speed

After image sites, e-commerce sites, portfolios, and news sites integrate CDN, an illusion is most likely to appear: images are already returned from CDN nodes, and the cache status is alsoHIT, so the website should be fast.

But when the page actually opens, you still have to wait. Product list items pop out one by one, the hero image takes ages to appear, especially on mobile data.

This is not contradictory. CDN mainly solves 'where to deliver images to users from,' but how long an image ultimately takes to display also depends on how large it is, which size the browser downloaded, whether it hits the cache, when the request starts, and how many resources on the page are competing for bandwidth at the same time.

So for image-heavy websites using CDN, you cannot stop at just 'integrate the image domain with CDN.' An effective solution should address three layers at the same time:

1. Delivery layer: whether images are returned from a CDN node closer to the user;

2. File layer: whether the image dimensions, format, and compression quality are reasonable;

3. Page layer: whether above-the-fold images are prioritized and below-the-fold images are deferred.

If only one layer is optimized, test results often show 'nodes are fast, but the page is still slow.'

First, the answer: how image-heavy websites should integrate CDN

A relatively reliable approach is:

• Use a dedicated image domain, for exampleimg.example.com, and make image addresses on the page actually point to this domain;

• Cache public images on CDN, and use longer cache times for stable, unchanging images;

• When image content updates, change the file name or version number instead of relying on users to manually clear cache;

• Generate multiple sizes based on the page display width to avoid mobile devices loading desktop-sized images;

• Prioritize evaluating WebP or AVIF for photos while keeping compatible formats;

• Do not lazy-load the above-the-fold main image; for images below the fold, useloading="lazy";

• Test cold cache, warm cache, different regions, and different carriers separately with real image URLs;

• Finally, go back to the browser to check LCP, total image bytes, request order, and layout shift.

None of this is especially mysterious; the difficulty is that they must work together. For example, a 4000-pixel, 3MB product image, even if it hits a nearby node, is not suitable to be stuffed directly into a mobile card only 360 pixels wide.

Different images should not use the same strategy

Image-heavy websites usually do not have only one type of image. Logos, product thumbnails, above-the-fold banners, and high-resolution originals have different purposes, so their caching and loading methods should also differ.

The most common waste is saving only one original image for convenience: list pages, detail pages, pop-ups, and mobile all reference it. This simplifies URL management, but makes users pay for the largest size in every scenario.

After integrating an image domain with CDN, first confirm traffic really goes through the nodes

The website is configured withimg.example.comCNAME, it does not mean all images are already accelerated. Old pages may still reference origin addresses, CSS background images may use another domain, and images uploaded by third-party editors may bypass the new domain.

After integration, check at least four things:

Whether the page really uses CDN image addresses

Open the Network panel in browser developer tools and filterImg, check the Host of image requests. You can also view the page source and search for the old origin domain.

Pay special attention to:

• In HTML,srcandsrcset;

• In CSS,background-image;

• Images inserted after JavaScript runs;

• Open Graph share images and images in structured data;

• Legacy absolute addresses in rich text content.

Whether DNS already points to CDN

You can check the CNAME chain:

dig img.example.com CNAME +short
dig img.example.com A +short

Different networks and regions may be scheduled to different node IPs. This is normal CDN behavior and does not require global users to get the same IP. If you need to determine whether the current domain has already integrated CDN, you can useCDNChart's CDN detection tool, then verify against the CNAME status in the provider console.

Whether HTTPS certificates and access permissions are normal

The image domain needs a correct HTTPS certificate. When the page itself uses HTTPS, if images are still loaded over HTTP, the browser may block mixed content.

If images are configured with hotlink protection, signed URLs, or Referer whitelists, also test normal pages, search engine crawling, social sharing, and third-party channels that need to display images. Do not let overly strict hotlink protection rules make real users or search engines receive 403.

Whether responses come from nodes or origin

Check the cache status in response headers,Age,Viaor provider custom headers, then compare with origin logs. If every access goes back to origin, even if the domain goes through CDN, origin pressure and access latency will not truly decrease.

For the complete steps on integration verification, refer to"Has CDN acceleration taken effect? Check this after integration".

How to set image caching so it is fast and updates do not fail

Images are usually suitable for caching, but 'the longer the cache time, the better' is only half true. The premise of long caching is: when image content changes, the URL changes too.

Images that will no longer be modified can use long caching

If the file name contains a version or content hash, for example:

/products/sku-1280.a84f2c.webp
/assets/logo.v5.svg

When file content changes, a new URL is generated, and the old file can safely be set with a longer cache:

Cache-Control: public, max-age=31536000, immutable

Here31536000is one year. It is suitable for static resources where 'content under the same URL never changes' and should not be applied to all images without judgment.

If images with the same name are overwritten, do not blindly set one year

If new product images uploaded in the backend still use:

/products/123.jpg

Browsers and CDN may continue to use the old cache. At this point there are three options:

• Recommended: change to a new file name or new version path when updating images;

• Second choice: add a controllable version to the URL, for example123.jpg?v=20260919;

• Temporary handling: call the CDN refresh API after upload, along with a relatively short TTL.

Whether the version parameter enters the cache key must be verified according to CDN configuration. If CDN ignores query parameters,?v=2and?v=3may still be regarded as the same cache object; if CDN includes all parameters in the cache key, meaningless tracking parameters may create many duplicate caches.

Image processing parameters must enter the cache key, but cannot be combined infinitely

Dynamic image services commonly have URLs like this:

/photo/123.jpg?w=640&format=webp&q=80

Width, format, and quality change the returned content, and usually must participate in the cache key. Otherwise, a user requesting a 640-pixel WebP may receive a 1280-pixel JPEG, or even a response format that does not matchContent-Type.

But do not allow arbitrary sizes. Attackers or crawlers can continuously requestw=641,w=642,w=643, generating a large number of derivative files and cache objects. A more reliable approach is to limit sizes to a few business tiers, for example:

320 / 480 / 640 / 960 / 1280 / 1920

Quality can also be fixed to a small number of presets instead of accepting arbitrary numbers. This improves cache reuse and makes it easier to estimate image processing and storage costs.

Check response headers that hinder caching

If images always showMISSor bypass cache, focus on checking:

• Cache-Control: private,no-storeorno-cache;

• Unnecessary in the responseSet-Cookie;

• Whether CDN rules only cache specific suffixes;

• Whether requests carry authentication information;

• Whether URL parameters cause a new cache key to be generated every time;

• Whether the origin returns error status or unstable redirects.

Different providers do not handle these response headers exactly the same way by default. For example, Cloudflare in itsdefault cache behavior documentationlists common cacheable file extensions, and also explainsprivate,no-store,no-cache,max-age=0andSet-Cookieother situations' impact on default cache behavior. In actual deployment, the official documentation and current rules of the CDN you use should still prevail.

If you are not sureHIT,MISSandAgewhat they respectively mean, you can continue reading"How to read CDN cache hits? How to understand HIT, MISS, and Age".

How to choose among JPEG, PNG, WebP, and AVIF

Image formats are not better simply because they are newer, nor does it end with batch-converting all images to WebP. What should be compared is: under image quality acceptable to users, which format has smaller files, reasonable generation cost, and can display normally in target browsers.

JPEG: still practical for photo content

JPEG has good compatibility and is suitable for photos and continuous-tone images. It does not support transparency, and repeated editing and re-saving also accumulates lossy compression artifacts.

If existing images are already reasonably compressed JPEGs, there is no need to forcibly upscale and re-encode them multiple times for 'format consistency.' Look at final bytes and visual effect first.

PNG: suitable for transparent or lossless content, but easily too large

PNG is suitable for transparent images, UI screenshots, and content requiring lossless fidelity. For photographic photos, large PNGs are usually very heavy.

A common problem is design software exporting an oversized PNG with a transparent background, but the actual page background is fixed and does not need transparency. For such images, switching to JPEG, WebP, or AVIF often reduces download volume more than tuning CDN parameters.

WebP: balances photos, transparency, and broad compatibility

WebP supports lossy, lossless, and transparency. Google'sWebP official descriptionintroduces its compression capabilities and related tools. For most websites targeting modern browsers, WebP is usually an easy format tier to adopt.

But do not directly estimate your savings based on promotional ratios. Product images, illustrations, text screenshots, and already highly compressed JPEGs may have completely different benefits after conversion.

AVIF: file size may be more advantageous, but you must test with real images

AVIF can achieve smaller files on some photos and complex images, but encoding time, decoding performance, quality parameters, and your image processing service capabilities all need evaluation. For websites that generate large numbers of derivative images on the fly in the backend, also consider transcoding CPU cost and first-generation latency.

A practical selection method is not to argue about 'which is more advanced, WebP or AVIF,' but to sample from real business images: portraits, products, dark images, detail-rich photos, and text screenshots, and compare file size and generation time at similar visual quality.

SVG: suitable for logos and icons, not for all images

SVG has great advantages for vector logos, icons, and simple illustrations, and can stay clear at different resolutions. User-uploaded SVGs may contain scripts or external references, so they must be securely sanitized and cannot be unconditionally allowed for upload and display as ordinary images.

Converting formats alone is not enough; image dimensions are often more important

If an image on the page is only displayed at 360×240 pixels but downloads a 4000×2667-pixel original, even if converted to WebP, it may still waste a large amount of traffic.

Browsers providesrcsetandsizes, which can select more suitable candidate images based on screen and layout. An example that provides AVIF, WebP, and JPEG fallback formats at the same time is:

<picture>
  <source
    type="image/avif"
    srcset="/images/product-640.avif 640w,
            /images/product-1280.avif 1280w">
  <source
    type="image/webp"
    srcset="/images/product-640.webp 640w,
            /images/product-1280.webp 1280w">
  <img
    src="/images/product-1280.jpg"
    srcset="/images/product-640.jpg 640w,
            /images/product-1280.jpg 1280w"
    sizes="(max-width: 768px) 100vw, 50vw"
    width="1280"
    height="853"
    loading="lazy"
    decoding="async"
    alt="黑色双肩包正面和侧面细节">
</picture>

There are several easily overlooked points in this code:

• srcsettells the browser which image sizes are available;

• sizesdescribes approximately how wide the image occupies under different layouts, not how wide the image file itself is;

• widthandheighthelp the browser reserve the aspect ratio in advance, reducing page jumps when images appear;

• altshould describe the image content and purpose, and must not stuff unrelated keywords such as 'image CDN acceleration' for SEO;

• JPEG'ssrcandsrcsetprovide fallback for environments that do not support new formats.

MDN'sresponsive images descriptionintroduces in detailsrcset,sizesandpicturehow they work. Before launch, it is best to check the files actually selected by the browser under different mobile, tablet, and desktop viewports, rather than only confirming that the page 'can display.'

More lazy loading is not better, especially not for the above-the-fold main image

For images below the screen, native lazy loading can reduce initial above-the-fold requests:

<img
  src="/images/gallery-960.webp"
  width="960"
  height="640"
  loading="lazy"
  decoding="async"
  alt="产品内部结构展示">

But if the above-the-fold banner, product main image, or article cover is the largest content element on the page, it may very likely participate in LCP. Addingloading="lazy"to it may make the browser start downloading later, which instead slows down when users see the main content.

Critical above-the-fold images can load normally, and when truly necessary, use carefully:

<img
  src="/images/hero-1280.webp"
  width="1280"
  height="720"
  fetchpriority="high"
  alt="秋季新品系列展示">

fetchpriority="high"It is not a universal 'acceleration switch' for all above-the-fold images. Too many priorities means no priority, and may also crowd out bandwidth for CSS, fonts, or other critical resources. web.dev inbrowser native image lazy loading descriptionclearly recommends not using lazy loading for above-the-fold visible images; itsLCP optimization guidealso emphasizes that LCP resources need to be discovered and start loading as early as possible.

If the main image is hidden in a CSS background or inserted only after JavaScript runs, the browser will discover it later. At this point, even if the CDN node responds quickly, LCP may still look bad.

For image CDN speed testing, at least test four types of objects

Testing only one tens-of-KB logo cannot represent the real experience of an image website. It is recommended to select from online business:

• A small icon or small thumbnail from 10KB to 50KB;

• A common list image;

• An above-the-fold main image;

• A large detail page image or high-definition preview image.

These files do not need to be deliberately made to a certain size; they should represent the content real users download most often. When testing, record URL, file type, pixel dimensions, and file bytes, to avoid directly comparing old and new results after images are replaced a few days later.

The first and second requests should be viewed separately

The first request may be a cold cache that needs CDN to go back to origin; the second request may already hit a node. Both are important, but they answer different questions:

• Cold cache reflects the origin-return path, origin processing, and cache fill speed;

• Warm cache reflects the edge node's ability to deliver images to users.

Requesting the same public image URL consecutively can quickly check response headers and timing:

curl -sS -D /tmp/image-headers.txt -o /dev/null \
  -w 'remote_ip=%{remote_ip}\ncontent_type=%{content_type}\nsize=%{size_download}\ndns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\n' \
  'https://img.example.com/products/sku-1280.webp'

sed -n '1,30p' /tmp/image-headers.txt

Focus on checking:

• Content-Typewhether it matches the actual format;

• Content-Lengthor whether the actual downloaded bytes meet expectations;

• Cache-Controlwhether the required caching is allowed;

• Agewhether it grows;

• whether the provider's cache header changes fromMISStoHIT;

• Varywhether it matches the format negotiation method;

• ETagorLast-Modifiedwhether it is reasonable;

• whether TTFB and total duration are stable across multiple requests.

Do not add random parameters to the URL every time just to avoid caching, and then judge CDN speed based on that. Random parameters may create new cache objects, and what you measure is always origin-return performance.

Do not test only once in the office

Fast access from Beijing Unicom does not mean Guangzhou Mobile, Chengdu Telecom, or overseas users are also fast. Image CDN testing should at least cover regions, carriers, and peak access times where real users are concentrated.

You can put representative image URLs intoCDNChart website speed test, to observe connection, TTFB, download time, and success across different regions and networks. When testing, it is recommended to keep:

• Test time and time zone;

• Test region and carrier;

• Resolved or connected IP;

• HTTP status code;

• Cache status;

• TTFB, total duration, and downloaded bytes;

• P50, P95, and failed requests.

A single fastest result only shows that 'one request was fast.' To judge whether image delivery is stable, sample continuously and group cache HIT and MISS. For the specific method, refer to"Websites are sometimes fast and sometimes slow. How should CDN speed testing be done?".

CDN images are fast, why does the page still look slow?

Single-image speed testing focuses on one URL, while page loading is a process where dozens or even hundreds of resources compete together. The two cannot replace each other.

Open the Network panel in browser developer tools and check:

How many images the page downloaded in total

Check request count, transferred bytes, and original resource size separately. The compression ratio may be good, but if the page requests 200 images at once, above-the-fold bandwidth may still be squeezed.

When the above-the-fold main image starts requesting

If the main image is discovered only after HTML parsing for a long time, or inserted only after waiting for some JavaScript execution, CDN cannot make up for the lost time before that. In a waterfall chart, the main image request start time is often more valuable than looking only at download duration.

Whether mobile downloads desktop-sized images

After switching different viewports, check the image's actual URL andContent-Length. The page CSS shrinking a 4000-pixel image to 300 pixels for display does not mean the browser only downloaded the 300-pixel version.

Whether the LCP element is an image

If the LCP element is the above-the-fold large image, continue breaking it down: whether server response is slow, whether the image is discovered very late, whether the download is too large, and whether display is delayed by scripts or animations after download.

Whether the page jumps when images appear

When images lack explicit dimensions, the browser does not know how much space to reserve when layout starts. After the image loads, text and buttons get pushed away, causing layout shift. Provide correct width and height oraspect-ratiofor images, which is usually more direct than simply improving CDN speed.

CDN speed testing and full-page speed testing solve different problems; for the boundary between them, refer to"What is the difference between CDN speed testing and website speed testing? What can each measure?".

A troubleshooting table: find the real problem from symptoms

A deployable transformation sequence

If the website is already online, it is not recommended to change all image formats, domains, and URL rules on day one. When there are too many changes, once images fail to display, it is hard to quickly determine which layer has the problem.

You can first select a type of page with high traffic and a relatively stable structure for a small-scale transformation:

1. Count the page's current image requests, total bytes, LCP, and main image time;

2. Select four types of resources: logos, thumbnails, above-the-fold main images, and detail images;

3. Make image URLs truly go through CDN, and verify certificates, status codes, and cache headers;

4. Generate fixed sizes for high-frequency display positions, first avoiding obvious oversized downloads;

5. Compare image quality, bytes, and transcoding cost of JPEG, WebP, and AVIF on real samples;

6. Use versioned URLs and long caching for files that will not be modified in place;

7. Remove lazy loading from critical above-the-fold images, and defer below-the-fold images in batches;

8. Repeat single-image, multi-region, and full-page tests;

9. Confirm that search crawling, social sharing, hotlink protection, and image update workflows are not broken;

10. After metrics are stable, gradually cover other pages.

For before-and-after comparison, besides average load time, also record total image bytes, cache hits, P95 in different regions, LCP, and failure rate. Otherwise, it is easy to mistake an accidental fluctuation for transformation benefit because the network was better on the test day.

Common questions

After images are placed in object storage, is CDN still needed?

Object storage solves file storage and origin access, while CDN is responsible for distributing cacheable content to locations closer to users. When users are widely distributed, image traffic is high, or the origin is far away, CDN usually still has value. Whether it is worth integrating should be judged together by real user regions, cache hits, origin-return traffic, and costs.

How long is appropriate for image cache time?

There is no fixed answer that applies to all websites. When file names contain content hashes or versions and content under the same URL never changes, a very long cache time can be set; if images with the same name are frequently overwritten, use versioned URLs, or adopt a shorter TTL and establish a reliable refresh process. Do not just say 'cache for 30 days' without considering the update mechanism.

Are WebP and AVIF always smaller than JPEG?

Not necessarily. The result depends on the original image content, encoder, quality parameters, and the original JPEG compression level. The correct approach is to compare real samples at similar visual quality, not just look at the file extension.

The image is already HIT, why is TTFB still high?

It may be connected to a farther node, node load or network routing may be poor, or the cache status header may represent an upper-layer cache rather than the edge layer closest to the user. Record response IP, region, carrier, and multiple P95 values, then determine whether it is an occasional fluctuation or a persistent problem.

Should all images be lazy-loaded?

No. Images below the screen are suitable for lazy loading, while above-the-fold main images or images that may become LCP should usually be requested as early as possible. Above-the-fold images being lazy-loaded is one of the common reasons 'CDN is fast but the page looks slow.'

Should image CDN use Ping or HTTP download for testing?

Ping can only provide clues about basic network round-trip time; it cannot represent HTTPS handshake, caching, TTFB, and file download. Image acceleration should primarily use HTTP requests to real image URLs, while recording file size, cache status, TTFB, download duration, and success rate.

Will using CDN for images directly improve SEO rankings?

CDN itself is not a switch that guarantees ranking improvement. It may improve image delivery speed, stability, and user experience, but whether the page obtains search traffic also depends on content quality, crawling and indexing, mobile experience, image semantics, internal links, and many other factors. Imagealtshould accurately describe the content, and not be written as a string of search terms for keyword density.

When an image-heavy website loads slowly, you can first take one above-the-fold main image and perform a complete check: which domain it requests from, which node it resolves to, whether it is HIT or MISS, how many bytes were downloaded, when it starts in the waterfall chart, and whether it is the LCP element. Seeing this chain clearly is usually easier than adjusting all CDN parameters in bulk from the start to find the real bottleneck.