Do you ask for passwords in the form?

No. The public form never requests access. Secure credentials are requested only after the scope and quote are approved.

Who reviews the incident?

The request goes to Jordi Ensenyat, founder of Code Barcelona and a WordPress specialist with more than 15 years of experience.

Is anything changed before the quote?

No. Visible symptoms and scope are reviewed first. Intervention begins after approval and with a rollback path prepared.

Do you work internationally?

Yes. WP Repair handles WordPress and WooCommerce incidents in English and Spanish through a remote service.

WordPress Serves Full-Size Images on Mobile: How to Verify `srcset`

A WordPress page displays an image at 360 pixels wide on a phone but downloads a file thousands of pixels across.

This is not solved by making the original upload smaller in every case. WordPress may already have appropriate variants, while the theme’s sizes attribute tells the browser to choose the wrong one. The image may also be a CSS background, builder output or manually coded element that bypasses normal responsive markup.

First establish which file the browser selects and why.

Inspect `currentSrc`, not only `src`

When an image has srcset, the src attribute may be a fallback rather than the chosen request.

In the browser Console:

const image = document.querySelector("main img");

console.log({
  src: image?.src,
  currentSrc: image?.currentSrc,
  naturalWidth: image?.naturalWidth,
  renderedWidth: image?.getBoundingClientRect().width
});

Replace the selector with one verified for the affected image. This is a read-only diagnostic.

Compare naturalWidth with rendered width, allowing for device pixel ratio. A 700-pixel source for a 350 CSS-pixel image can be reasonable on a 2× display. A 3000-pixel source is harder to justify.

Read the rendered HTML

An expected WordPress image might contain:

<img
  src="/uploads/photo-1024.webp"
  srcset="/uploads/photo-480.webp 480w,
          /uploads/photo-768.webp 768w,
          /uploads/photo-1024.webp 1024w,
          /uploads/photo-1600.webp 1600w"
  sizes="(max-width: 700px) 100vw, 700px"
  width="1024"
  height="683"
  alt="WordPress image delivery test"
>

Check the page source or Elements panel after plugins have modified it. The editor preview is not authoritative.

Understand how `sizes` affects selection

srcset offers candidates. sizes estimates how wide the image will be in the layout.

If sizes="100vw" but the image occupies one third of the desktop layout, the browser may select a source far larger than needed. If it claims a fixed 1200 pixels on mobile, the result is worse.

Write sizes from the real CSS:

sizes="(max-width: 767px) calc(100vw - 32px),
       (max-width: 1199px) 50vw,
       560px"

This example accounts for mobile padding, a tablet column and desktop maximum. Measure your layout rather than copying it.

Device pixel ratio changes the selected width

A high-density phone may request roughly twice the CSS width to keep the image sharp. That is expected.

In the Console:

console.log(window.devicePixelRatio);

Evaluate file choice against rendered width multiplied by a sensible density. Do not force every phone to a 1× image if product detail becomes visibly soft.

Check whether WordPress generated the needed sizes

In Media settings and theme/plugin registration, WordPress defines image sizes. An older upload may predate a newly registered size.

WP-CLI can list registered sizes where available:

wp media image-size

Command support depends on the WP-CLI version. Alternatively inspect wp_get_registered_image_subsizes() in a controlled diagnostic.

Do not regenerate the entire library until you know which sizes are missing. Large libraries can consume storage, CPU and time.

Builders may use the original attachment URL

Page builders often offer size choices such as Thumbnail, Medium, Large and Full. “Full” may insert the original and produce incomplete srcset behaviour depending on the widget.

Open the affected widget and confirm:

selected image size;
custom width;
background versus image element;
mobile overrides;
lazy-load settings.

Changing the widget to an appropriate registered size can repair delivery without replacing media.

CSS background images do not use `<img srcset>`

A background declared in CSS has no srcset attribute. Use media queries or image-set() where supported:

.service-hero {
  background-image: url("/uploads/hero-mobile.webp");
}

@media (min-width: 768px) {
  .service-hero {
    background-image: url("/uploads/hero-desktop.webp");
  }
}

For modern format/density selection, image-set() can help, but test browser support and fallbacks. If the image is meaningful content, an <img> or <picture> may be more appropriate and accessible.

Art direction needs `<picture>`, not just scaling

Sometimes mobile requires a different crop:

<picture>
  <source
    media="(max-width: 767px)"
    srcset="/uploads/hero-mobile-480.webp 480w,
            /uploads/hero-mobile-768.webp 768w"
  >
  <img
    src="/uploads/hero-desktop-1200.webp"
    srcset="/uploads/hero-desktop-800.webp 800w,
            /uploads/hero-desktop-1200.webp 1200w"
    width="1200"
    height="700"
    alt="WordPress performance specialist"
  >
</picture>

Keep aspect ratios and reserved space under control to avoid layout shift.

Cache and CDN rewrites can hide the real source

Image optimisation plugins and CDNs may replace WordPress URLs. Verify the final request:

URL;
Content-Type;
dimensions;
transferred size;
cache header;
query parameters.

Clear only the relevant cache after correcting markup. Purging everything can make comparisons noisy and load the origin.

Do not remove large variants needed elsewhere

The same attachment may appear:

as a small card;
in a full-width hero;
in a product zoom;
in a downloadable press asset.

Repair selection per context. Deleting the large source can damage valid high-resolution use.

Test across representative widths

At minimum, inspect:

narrow phone;
wide phone;
tablet;
laptop;
large desktop;
high-density display where commercially important.

For each, record rendered width, currentSrc, intrinsic width and transferred bytes.

Regenerate only after backing up media

If variants are genuinely missing:

back up uploads and database;
register the required sizes;
test regeneration on a small sample;
check crops and disk space;
run the bounded regeneration;
verify URLs and visual quality.

Do not delete old generated files automatically until references and rollback are understood.

Evidence for a responsive-image assessment

Provide the page URL, affected image, mobile viewport, currentSrc, rendered/intrinsic widths and recent theme/plugin changes. The first review does not require account credentials.

If WordPress serves full-size images on mobile, we can identify whether the fault is missing variants, incorrect sizes, builder output, CSS backgrounds or CDN rewriting. The repair keeps the right visual quality while reducing the bytes new visitors actually download.

Commission the image delivery fix

If you need the delivery corrected across your templates, our WordPress image optimisation service covers a representative sample, visual acceptance, responsive resource checks and a reversible rollout. Send the affected page URLs and identify who can approve product detail and image quality.