Diagnosis
Overweight, sluggish, and short of breath.
The site works, but a heavy page builder stack and an unoptimized asset load leave it slow to respond and slow to paint. The symptoms are treatable. The underlying architecture is the real condition.
◆ OVERALL GRADE D
Vitals
Measured live against Cloudflare cache. Lower is better on every reading below.
Server response · TTFB
1.8s
Critical target < 0.5s
Full page load
2.6s
Critical target < 1.5s
HTML document weight
266KB
High target < 100KB
CSS files
40
Critical target 2 to 5
JavaScript files
41
Critical target 5 to 10
Heaviest single image
460KB
High a PNG photo
Findings & Prescriptions
Seven issues, ordered by how much they hurt real visitors.
Critical, fix first
High, fix soon
Note
01
Slow server response
Critical
Finding
Even on a warm Cloudflare cache hit, the server takes ~1.8s to send the first byte. The page is slow before a single image loads, which makes this the single biggest drag on the experience.
Cause
Elementor plus a dozen plugins overwhelming PHP on every request.
℞ Fix
Full page edge caching, fewer plugins, faster host. On a rebuild this drops to under 200ms for free.
02
81 stylesheets & scripts
Critical
Finding
40 CSS + 41 JS files load on the homepage. Each is a separate request the browser must fetch and parse before the page settles.
Cause
Every builder and add on ships its own bundle; WP Rocket isn't combining them.
℞ Fix
Combine & minify, remove unused plugins. Should be ~5 CSS / ~8 JS total.
03
Unoptimized images
Critical
Finding
A portrait ships as a 460KB PNG; another graphic is 315KB. Only 4 of ~36 images use modern WebP, and the rest are oversized JPG or PNG.
℞ Fix
Convert photos to WebP or AVIF and size them to display dimensions. This alone cuts well over 1 MB from the page.
04
Broken SEO hygiene
High
Finding
The homepage has no <h1> heading at all. It also emits 2 canonical tags and 3 meta descriptions, sending conflicting signals to Google.
Cause
Rank Math, All-in-One SEO, Site Kit and MonsterInsights all running at once.
℞ Fix
Keep one SEO plugin, add a real H1, remove duplicate tags.
05
Pinch zoom disabled
High
Finding
The viewport tag disables zoom, blocking visitors from zooming in on mobile. This is an accessibility failure, and rough for an older wellness audience.
℞ Fix
Update the viewport meta tag so it no longer blocks zooming.
06
Page builder bloat
High
Finding
Elementor, Elementor Pro, ElementsKit, Phlox Pro theme and Auxin are all layered together. That is five overlapping systems, each adding its own CSS and JS and load.
℞ Fix
This is the root cause behind findings 01 to 03. A clean rebuild retires the whole stack.
07
Duplicate analytics
High
Finding
Google Site Kit and MonsterInsights both track the site, double counting visits and loading redundant scripts.
℞ Fix
Pick one analytics setup and remove the other.
Looking Ahead
A short note on the platform underneath, and where we would take it next.
On the platform
Why WordPress would become a blocker for what Etara is building
WordPress powers a large share of the web, and it served Etara well to get online. As a tool for publishing pages, it does that job, and the observation here is not a criticism of the current site.
The plan for Etara, though, is bigger than a marketing site. The goal is for this to become the source of truth that runs the practice, not only forms and booking, but the systems around them, with room for a patient application and a wider health platform later. That is a different kind of software from a website.
WordPress is built to publish content, not to be the backbone of a product. Pushing it in that direction means leaning on a specific plugin or a third party service for each new capability, stitched together and never quite fitting. Every one of those adds cost, lock in, and another dependency that can break. At that point the platform is fighting you rather than helping. It is also why the same architecture produces the slow response, the heavy page, and the conflicting SEO measured above.
In short, WordPress can run a website. It is not the right base for what Etara is aiming to build next.
What a Custom Foundation Gives Etara
Not just a faster website, but a base that can grow into the system that runs the practice.
Flexibility
A foundation, not just a website
Built to extend in any direction the practice needs, with no template or plugin quietly deciding what is or is not possible.
Data
One source of truth
Bookings, patients, content, and operations can live in a single system you own, instead of being scattered across separate plugins and services.
Product
Ready for an app and a Health OS
The same backend that runs the site can power a future patient application or health platform, so you build once rather than rebuild later.
Ownership
You own the whole stack
The code and the data belong to Etara, not to a set of plugin vendors. Nothing essential is locked behind a service you cannot control.
Performance
Speed that holds
It ships only the code each page needs, so it loads in well under a second and stays fast as features are added on top.
Growth
Scales with the practice
New capabilities are added cleanly as Etara grows, without fighting the limits of a template or bolting on yet another plugin.
Our recommendation
Build the foundation, not just the website.
Our suggestion is a custom built foundation rather than a website bolted onto WordPress. It would carry everything patients already value about Etara today, while giving you room to grow it into the system that runs the practice, one source of truth for bookings, patients, content, and whatever comes next, including a patient app or a wider health platform. You would own the whole thing, it would stay fast and secure, and it would extend cleanly instead of hitting a wall. There is no rush here. Whenever the timing feels right, we would be glad to map out what that path could look like.