The WordPress site behaves normally on office Wi-Fi. On mobile data, the same page stays incomplete, the hero appears late or the menu takes too long to respond.
That difference is useful evidence. It tells you not to begin with a generic “speed optimisation”. Something about the mobile route —bandwidth, latency, device work or conditional content— is exposing a cost that Wi-Fi conceals.
The safest investigation keeps those factors separate. Otherwise it is easy to compress an image when the real delay is the server, or change hosting when the browser is downloading several megabytes of video.
Confirm that the difference is the connection
Use the same phone, browser and page for both tests:
- close unrelated browser tabs;
- open a private tab;
- load the page on Wi-Fi;
- record what appears late or remains unresponsive;
- disable Wi-Fi and repeat on mobile data;
- repeat each state once more.
Do not compare your desktop computer on Wi-Fi with a different phone on mobile data. That changes the device, browser and connection at the same time.
Note the mobile signal and network type. A weak indoor connection can produce packet loss and repeated transfers that a simple “4G” label does not describe. Move to a location with a stable signal before concluding that the website fails on all mobile data.
Identify whether the server or the page body is slow
Open the URL with a command-line request from more than one connection if possible. Measure the time until the first response byte:
curl -s -o /dev/null
-w 'First byte: %{time_starttransfer}snTotal: %{time_total}snDownloaded: %{size_download} bytesn'
https://example.com/page/This does not emulate a mobile browser, but it separates a delayed HTML response from the work that follows.
If the first byte is slow on every connection, investigate WordPress, PHP, MySQL and hosting before focusing on mobile assets. If the HTML begins quickly but the mobile page remains incomplete, inspect the browser waterfall and rendering work.
Remember that your mobile provider may take a different network route to the server. Compare several measurements rather than treating one request as a benchmark.
Look at transferred bytes, not the original media library
A page can contain optimised source images and still deliver the wrong files to a phone.
In remote browser testing or Chrome developer tools, use a mobile viewport and inspect the Network panel. Reload with the cache disabled for that diagnostic run. Sort by transferred size.
Check:
- which image becomes the Largest Contentful Paint element;
- whether the browser receives a desktop-sized image;
- whether the image URL uses WordPress-generated sizes;
- whether CSS background images have mobile alternatives;
- whether WebP or AVIF is actually served;
- whether a slider downloads hidden slides immediately;
- whether the browser starts a video before it is visible.
The filename is not enough. An image ending in .webp can still be far too large for its displayed dimensions.
Verify WordPress responsive image markup
WordPress normally adds srcset and sizes to images inserted through supported functions. Themes and builders can override or bypass that output.
A healthy image element may resemble:
<img
src="/uploads/hero-1200.webp"
srcset="/uploads/hero-480.webp 480w,
/uploads/hero-768.webp 768w,
/uploads/hero-1200.webp 1200w"
sizes="(max-width: 768px) 100vw, 1200px"
width="1200"
height="700"
alt="WordPress performance assessment"
>The browser uses srcset together with sizes, viewport width and screen density. If sizes incorrectly says the image occupies 1200 pixels on mobile, the browser may choose a larger file than the layout needs.
Do not paste a generic sizes value across the theme. Inspect the real CSS width of each important image and test common breakpoints.
Treat autoplay video as a separate mobile budget
Background MP4 video can be acceptable on a controlled landing page, but it needs deliberate mobile behaviour.
Check whether:
- the video has
preload="metadata"orpreload="none"where appropriate; - a poster image appears before playback;
- the mobile layout genuinely needs the video;
- the MP4 dimensions exceed the rendered size;
- the bitrate is suitable for a short decorative loop;
- the file contains unnecessary audio;
- playback starts before the video enters the viewport.
For a decorative video, the markup should not force a full download before the main content:
<video
muted
loop
playsinline
preload="metadata"
poster="/media/hero-poster.webp"
aria-hidden="true"
>
<source src="/media/hero-mobile.mp4" type="video/mp4">
</video>This is not a universal prescription. A product demonstration may need controls and accessible supporting text. The point is to choose the loading behaviour intentionally.
Fonts become expensive when latency is high
Several small font files can delay text because each request pays connection overhead and the browser may wait before displaying the chosen face.
Review:
- font families actually used;
- weights and styles loaded;
- whether the same font is requested from multiple plugins;
- cache headers;
- cross-origin configuration;
font-display;- any font preloads.
Only preload a font required by visible initial text. Preloading every weight competes with the hero image, CSS and other critical resources.
A practical @font-face rule includes a fallback behaviour:
@font-face {
font-family: "Site Sans";
src: url("/fonts/site-sans-regular.woff2") format("woff2");
font-display: swap;
font-style: normal;
font-weight: 400;
}Test the visual change. swap can reveal differences between the fallback and final font that create layout movement if metrics are poorly matched.
Third-party scripts may wait on different networks
Analytics, consent tools, chat, maps, embedded video and advertising are fetched from other domains. On mobile data, DNS lookup and connection setup for each third party can become more visible.
Group the Network requests by domain. For each third party, ask:
- is it necessary on this page?
- does it load before the main content?
- does it block a form, menu or checkout?
- can it wait for consent or interaction?
- what happens if the service is unavailable?
Do not delay a script blindly. Moving form or checkout code behind user interaction can break the exact journey you need to protect.
JavaScript execution can be the bottleneck after download
The same phone that downloads assets slowly may also parse and execute JavaScript more slowly than your desktop.
Record a Performance trace while loading the page and opening the affected interface. Long tasks on the main thread can make the page look complete but unresponsive.
Common WordPress sources include:
- page-builder front-end bundles;
- sliders and animation libraries;
- large menus;
- product-variation scripts;
- consent managers;
- duplicated analytics tags;
- scripts loaded by plugins that are not used on the page.
File size is only the first clue. Use the trace to connect a script to the actual blocked interaction.
Check for mobile-only content and CSS
Some themes render separate desktop and mobile sections, then hide one with CSS. The visitor may download both.
Inspect the DOM and Network panel for duplicate:
- hero images;
- sliders;
- navigation trees;
- testimonial carousels;
- background videos;
- form widgets.
display: none prevents visual display; it does not guarantee that the browser avoids every related image or script request. Prefer one responsive component when the design allows it.
Compare the page before and after consent
Mobile visitors often see a full-width consent interface before the page. It can add scripts, prevent scrolling or delay other components.
Test:
- no consent decision;
- rejection of optional categories;
- acceptance of the normal set;
- return visit with the choice stored.
If the website becomes slow only after acceptance, identify the added services. Preserve the intended privacy behaviour while reducing unnecessary work.
Do not use a desktop score as the acceptance test
A desktop PageSpeed result can be green while mobile visitors still receive:
- larger files than needed;
- slow font and third-party connections;
- excessive JavaScript;
- an autoplay video;
- mobile-only layout duplication;
- a slow uncached WordPress response.
Use mobile field data where available, but also test the exact page and interaction. Origin-wide averages can hide one expensive landing page.
Changes to avoid during diagnosis
Do not enable several image, cache and minification plugins at once. Do not replace every image before confirming which files are transferred. Do not remove analytics or consent code from production without understanding the business and privacy requirement.
Make one evidence-backed change, record the before state and keep a rollback route.
What a successful mobile repair looks like
The repaired page should:
- begin responding without an avoidable server delay;
- prioritise visible text and the main image;
- deliver media appropriate to the mobile layout;
- remain usable while optional scripts load;
- avoid unnecessary mobile-only duplicates;
- respond to menus, forms and checkout actions promptly.
Recheck on Wi-Fi and mobile data. A change that helps the phone but breaks desktop layout, analytics or WooCommerce is not complete.
If WordPress is consistently slow on mobile data, send the exact URL, phone model, browser, country and the visible symptom. An initial performance assessment does not require passwords. We will identify whether the delay belongs to delivery, media, JavaScript or the WordPress server before proposing work.