Page speed for psychology practice websites: what actually matters

For psychology practice websites, three Core Web Vitals metrics actually move the needle: LCP under 2.5s, INP under 200ms, CLS under 0.1. Everything else is mostly noise. A perfect 100 Lighthouse score is a vanity metric — getting those three numbers into the green is what affects bookings, search ranking, and whether anxious visitors stick around long enough to click “book now”.

Core Web Vitals in plain English

Google measures three things and uses them in ranking. Strip away the acronyms and they’re each asking a simple question.

• LCP — Largest Contentful Paint — how long until the biggest visible thing on the page (usually the hero image or main heading) finishes loading. Target: under 2.5 seconds on a 4G mobile connection. Above 4 seconds is a problem.
• INP — Interaction to Next Paint — how long it takes the page to respond when someone taps a button or scrolls. Target: under 200ms. Anything over 500ms feels broken.
• CLS — Cumulative Layout Shift — how much the page jumps around as it loads. The “I went to tap a button and an ad pushed it down so I tapped the wrong thing” problem. Target: under 0.1. This one’s a number, not a time.

These three metrics replaced an older set (FID, FCP, TTI) because they actually correlate with whether users complete tasks. They’re what Google uses to rank pages, and they’re what Lighthouse weights heaviest in its scoring.

Why mobile speed matters more than desktop

For allied health practices, roughly 65–80% of website traffic is mobile, and the share is rising every year. A page that loads in 1.2 seconds on your office desktop might take 4.8 seconds on a patient’s phone on the train.

Mobile speed is harder for three reasons: phones have weaker CPUs (even high-end iPhones throttle when warm), mobile networks are less consistent (4G in a basement is closer to 2G), and mobile users are less patient (median bounce after 3 seconds of waiting). Optimise for mobile first; desktop will come along for the ride.

What slows a typical Wix or Squarespace site

The same culprits appear on almost every template-built practice site I audit.

• Massive uncompressed hero images. A 4MB JPG of a calming beach scene that should be a 180KB WebP. This single change often drops LCP by 1–2 seconds.
• Web fonts loaded blocking. Five Google Font weights pulled from fonts.googleapis.com before the page can render. Use 1–2 weights and font-display: swap.
• Embedded video autoplay on mobile. A muted hero video that downloads 8MB before the visitor sees the booking button. Replace with a poster image on mobile.
• Third-party widgets stacked on the homepage. Booking widget + Google Reviews widget + Facebook feed + chat widget. Each one adds 100–500ms of JavaScript.
• No image lazy-loading. Off-screen images downloaded immediately. Add loading="lazy" to every image below the fold.
• Page builder bloat. Wix and Squarespace ship 1–2MB of JavaScript regardless of what’s on the page. There’s a hard ceiling on how fast a builder site can be.

Realistic targets vs vanity targets

A 100 Lighthouse score sounds great. It rarely matters. What matters is whether your Core Web Vitals are in the green for real users on real phones.

Site type	Typical mobile LCP	Typical mobile INP	Typical mobile CLS	Realistic ceiling
Wix template (typical)	4.5–7s	250–500ms	0.15–0.30	LCP rarely below 3.5s
Squarespace template	4.0–6s	200–400ms	0.10–0.25	LCP rarely below 3.0s
WordPress (Elementor + plugins)	5–9s	300–600ms	0.20–0.40	Highly plugin-dependent
Custom Astro/Next/static site	0.8–1.8s	50–150ms	0.00–0.05	All three in the green easily

The pattern is clear: builder platforms hit a performance ceiling because they ship the same large JavaScript bundle whether you use it or not. Static and lightly-hydrated frameworks (Astro, Eleventy, plain HTML) start fast and stay fast because the browser has less to do.

For most allied health practices, the practical target is “all three Core Web Vitals in the green on a mid-range Android phone over 4G”. A score of 92 in Lighthouse with all three vitals green is meaningfully better than a score of 100 in lab conditions but degraded performance for real users.

How to test

Three free tools cover everything you need.

1. PageSpeed Insights — https://pagespeed.web.dev. Paste your URL. Look at the “Core Web Vitals Assessment” panel at the top — that shows real-user data from Chrome users over the last 28 days. The lab scores below it are simulated and less important.
2. WebPageTest — https://www.webpagetest.org. More configurable. Useful when you want to test from a specific Australian location (Sydney, Melbourne) on a specific device profile (Moto G4 4G is a reasonable mid-range proxy).
3. Chrome DevTools Lighthouse panel — built into Chrome. Useful for fast iteration while you’re fixing things, but use mobile mode and “simulated throttling” to match real-world conditions.

Test every important page, not just the homepage. The booking page is usually slower than the homepage and matters more.

What to do next

A pragmatic order if you’re starting from a slow site.

1. Compress images. Run every hero image through Squoosh or convert to WebP. This single change typically drops LCP by 30–50%.
2. Audit third-party scripts. Remove any widget you don’t actively use. Defer non-essential scripts with loading="lazy" or defer.
3. Switch font loading. One or two weights, font-display: swap, self-hosted if possible.
4. Re-test. PageSpeed Insights against the homepage and booking page. Are all three Core Web Vitals green?
5. If the answer is “still no” after 1–3 and you’re on a builder platform, the realistic next step is rebuilding on a faster stack. The platform itself is the ceiling.

Speed isn’t the whole game, but it’s a prerequisite. A beautifully written booking page that takes 6 seconds to load is a booking page nobody finishes loading.

For the related question of which pages a practice actually needs in the first place, see my 5 essential pages every solo practice website needs.

If you want to know whether your current site can be made fast or needs replacing, book a free audit.