Mobile Website Speed Rescue Plan: From Homepage to Inquiry Form

The short version #

If your overseas mobile site takes ten seconds to paint, the form button doesn't respond for a beat after the tap, and your case study photos are 4 MB straight from the camera, you don't need a redesign yet. You need a speed rescue. Don't open Lighthouse first. Open analytics, find which pages and which countries actually matter, and start with the three biggest wins on every site we audit: images, fonts, and third-party scripts. Different page types deserve different priorities. The homepage is not the case study, and the case study is not the inquiry form. WordPress sites have their own set of traps. Once you ship, monitoring has to be continuous, not a one-time score on launch day. If budget is tight, save the homepage and the inquiry form first; everything else can wait for phase two.

A recent client makes industrial valves for export. Their overseas inquiries dropped 40% in March. Their site loaded in maybe four seconds on a desktop in our office. On a 4G phone in São Paulo it took 14 seconds. The case studies were stacked with seven 4 MB factory photos straight off a Canon. The homepage still had a video lightbox plugin from 2018. The brief said "redesign the homepage." We pushed back. Don't redesign yet, fix the speed. Three weeks later, mobile bounce rate fell from 78% to 53% and inquiry volume came back. The redesign got rescheduled to the next quarter with most of the original visual brief intact.

This post is the working playbook from projects like that. Not a list of performance jargon. A short, sequenced rescue plan that a small team can actually finish in two to four weeks.

1. Test reality #

Running PageSpeed Insights once and showing the team a number is the most common way to start in the wrong place. We've seen plenty of teams celebrate a 92 desktop score while their actual buyers in Brazil sit on a mid-range Android with a flaky 3G signal.

Before you measure, answer four questions:

• Which pages move the needle: home, primary product or service pages, the case studies that actually get cited in inquiries, and contact. Ignore the rest for now.
• Where do buyers come from: pull the GA4 Country and Device dimensions. If 70% of mobile traffic is in Germany and Poland, don't spend two days tuning for Beijing.
• What network are they on: 4G/5G in Western Europe is one world; rural Southeast Asia and the outskirts of São Paulo are another. Lighthouse's default "Slow 4G" is more optimistic than what your buyer actually has.
• What does "good enough" mean: a B2B inquiry site doesn't need a 100. Aim for LCP under 2.5 seconds, time-to-interactive under three on the primary device, and a form button that responds within half a second of a tap.

Use real devices and remote nodes. Chrome DevTools with 4G throttling, WebPageTest from a node in your target market, and Search Console's Core Web Vitals (which uses real Chrome user data via CrUX). Three signals beat one synthetic score.

2. Images first #

About 90% of mobile speed problems we diagnose come down to images. The number sounds inflated. It isn't.

Work in this order:

• Convert to WebP or AVIF: JPG to WebP saves ~30% on average; PNG to WebP saves 50%+. ShortPixel or Smush handles this on WordPress. Custom builds can run conversion in the asset pipeline. Keep the originals; serve the modern format with a JPG fallback.
• Resize for the container, not the original: a phone at 390 pixels wide doesn't need a 2400-pixel-wide factory shot. Use srcset and sizes so the browser picks the right one.
• Eager above the fold, lazy below: hero image gets loading="eager" and fetchpriority="high"; everything below the fold gets loading="lazy". WordPress 6.x defaults to this, but plenty of older themes override it.
• Don't forget background images: background-image in CSS doesn't get the same lazy-loading treatment. If your hero is a CSS background, swap it for a real <img> or add a <link rel="preload">.
• Audit case study pages separately: this is where we find the worst offenders. A single 5 MB workshop panorama can wreck a whole detail page. Cap case-study images at ~200 KB each and break long galleries into pagination or a collapsed grid.

Once images are dealt with, total page weight typically drops by half. Everything else you do becomes worth doing.

3. Fonts and scripts #

After images, the next two big sinks are web fonts and third-party scripts.

For fonts:

• Don't load Google Fonts at runtime: from some networks, the request stalls. Self-host the font files, set font-display: swap so text renders in a system font first, and let your branded font swap in when ready.
• Only load weights you actually use: many themes pull Regular / Medium / Bold / Light by default. That is 200 to 400 KB of font data for two visible weights. Cut it to what you actually render.
• Don't ship a full Chinese font set: if your English site has occasional Chinese characters (contact info, a quoted client name), use a subsetted file. A full Source Han Sans is around 14 MB.

For scripts, almost every site has too many:

• Live chat widgets: Tawk, Crisp, LiveChat all load eagerly by default. Most visitors don't open chat in the first minute. Defer the widget until scroll depth or a click on the chat button.
• Heatmaps and session recording: Hotjar and Microsoft Clarity earn their keep during a diagnosis sprint. Turn them off the rest of the time. They record every DOM event, which is brutal on older Android phones.
• Slider and video plugins: Slider Revolution and similar are common WordPress culprits. The JS alone runs 400 KB before you've shown a single slide. Disable what you don't actively use.
• Analytics tags: keep GA4, Meta Pixel, LinkedIn Insight, but consolidate them through GTM with defer so they don't block the main thread.

We usually pull a Network panel screenshot into a meeting and walk through every third-party request: source, size, purpose. Cutting half is normal.

4. Page-by-page #

Different pages have different jobs. Treating them all the same wastes effort.

Homepage:

• One hero image, one headline, one button. Skip the five-slide carousel. Carousels have been one of the most overrated UI patterns of the last decade.
• No autoplaying hero video. If you must show video, use a poster image with click-to-play.
• Cap the service grid at three to six cards. Anything else folds.
• Replace the client logo wall with a single SVG sprite or one optimized image, not eight individual PNGs.

Product or service pages:

• Top of the page: one-sentence definition, primary image, inquiry button. Within the first viewport, a buyer should know what this is, what it does, and how to ask.
• Use real HTML tables for specs. Never specs-as-an-image.
• Related case studies sit lower on the page, each showing only a thumbnail, the client, and a one-line outcome. Save the full read for the case page itself.

Case study pages:

• The list view uses thumbnails around 300×200. The full image only loads after a click into the detail page.
• On the detail page, photos that sit deep in the article should defer decoding until they scroll into view.
• Add decoding="async" to client logos so they don't block the first paint.

Contact page and inquiry form:

• Five fields max, already covered above.
• Ship the form script locally. Don't depend on a third-party form widget (Typeform, Tally) for primary inquiries; they're inconsistent on some overseas networks.
• Add a loading state to the submit button. If a buyer taps it and nothing happens, they tap two more times, then leave.
• Use Cloudflare Turnstile or hCaptcha instead of Google reCAPTCHA. Faster, and more friendly to European users from a GDPR angle.

5. WordPress specifics #

WordPress speed problems are rarely WordPress's fault. They're plugin sprawl, the wrong theme, and the wrong host.

Run this checklist:

• Plugin audit: open wp-admin → Plugins, tag every entry as "must keep / replaceable / unused." Common things to cut: multiple SEO plugins running at once, social-share widgets, redundant analytics plugins (GA4 reports on its own; you don't need a wrapper). We typically take 40+ plugins down to about 15.
• Theme weight: Avada, Divi, and Salient are powerful but heavy. For a content-driven site, GeneratePress, Astra, or Kadence load far less. Switching themes isn't a one-week job, but it belongs on the phase-two list.
• Caching: install LiteSpeed Cache, WP Rocket, or W3 Total Cache. Turn on page cache, browser cache, and Gzip or Brotli. Half an hour of work, immediate result.
• Database: run WP-Optimize once. Clear post revisions, expired transients, spam comments. On long-running sites, the wp_options table balloons past 20 MB and gets autoloaded into memory on every request.
• Hosting region: a Chinese host serving European buyers is the single worst configuration we see. Move to a host in or near the target market and add Cloudflare. For region-specific tuning, see Website Performance Across Regions. For deeper plugin and theme decisions, see WordPress Overseas Website Architecture.

6. Monitor after launch #

Performance isn't a launch-day artifact. A new plugin, a marketing-team upload of a 6 MB hero photo, a fresh GTM tag: any one of those takes yesterday's 2.1-second LCP back to six.

What we keep running long-term:

• Search Console Core Web Vitals: real Chrome user data via CrUX. Skim "poor" and "needs improvement" URLs once a week.
• GA4 page-load time: split by device and country to spot regional regressions early.
• Scheduled WebPageTest: pick the priority pages plus the primary market node; run weekly; archive results.
• Lighthouse CI: if you ship a build (Next.js, Nuxt, custom), wire Lighthouse into CI so a PR with a 600 KB image gets caught before merge.
• Slow logs: PHP slow log on WordPress, an APM like Datadog or New Relic on Node, and a weekly scan of the slowest ten requests.

The point isn't pretty dashboards. The point is to find regressions before a buyer does. The broader technical baseline is in Technical SEO Baseline for a New or Rebuilt Website, and if these symptoms feel familiar on an older site, 12 Signs Your Old Company Website Is Losing Leads maps the bigger pattern.

Trade-offs #

When budget is tight, the question we get asked most is "how much, how long?" Our standard answer:

• Week one: image compression, script audit, WordPress caching. On most older sites, this alone takes LCP from 6–8 seconds to around 3. Lowest cost, fastest visible result. Save the patient first.
• Weeks two and three: font optimization, homepage and service-page reflow, form tuning. Another 30–40% off load time, and conversion usually moves with it.
• Phase two: theme replacement, host migration, full multi-region CDN strategy. Bigger work, but only worth it once the first two phases are done. Otherwise you're paying for performance the easy stuff would have given you for free.

If the project is a full redesign, bake this rescue plan into the redesign timeline. Don't ship the new design and then "do performance later." The launch day is the new performance baseline.

Rescue table #

FAQ #

Is a Lighthouse score of 90 enough? #

Enough for a meeting. Not enough for production. Lighthouse is synthetic and gentler than real users on real networks. Use it as a trend (better or worse than last week), not an absolute target. For real-user data, look at Search Console Core Web Vitals and GA4 page-load time.

Do we always need to change hosts? #

Not always. If your existing host happens to sit close to the target market and you front it with a global CDN like Cloudflare, TTFB usually stays manageable. Host migration becomes mandatory in the classic mismatch: host in mainland China, buyers in Europe or North America.

What if the client says compressed images look worse? #

Separate "image quality the client can accept" from "image quality the website needs." Keep originals in OneDrive or a knowledge base; ship optimized versions on the site. For premium brands particularly sensitive to image quality, AVIF at quality 80+ gets you most of the way without the file-size cost.

Redesign or speed first? #

If both speed and conversion are broken, fix speed first. Wait a month, look at the data, and decide whether the redesign is still needed. We've watched several clients drop the redesign after their inquiry numbers came back. The visual issues turned out to be downstream of the speed issues. The right call between a small fix and a full rebuild is something we walk through in the diagnosis below.

Get a diagnosis #

If you're stuck behind an old website that crawls on mobile, or you've just shipped a redesign and mobile speed still isn't right, bring your domain, target markets, and the last 30 days of GA4 data. We'll run this exact checklist with you in a free initial review under our website rebuild service, and tell you which items are P0 fixes versus what can wait until next quarter.