If your website has a booking widget embedded in the page — a Calendly iframe, an Acuity scheduler, a HotDoc box — there's a good chance it's the worst-performing part of your site. Not metaphorically. Measurably.

We've audited 60+ service-business sites in the last year. The pattern is so consistent it's boring: the page loads in 1.8 seconds, the booking widget loads in 4.2 seconds, and 35-45% of people who reach the page never see the widget render before they leave. Of the ones who do, the conversion rate on the embed is typically 40-60% lower than the conversion rate of a native form on the same page.

The widget feels like the easy answer. It's not. This is the post explaining why, and what to do about it.

The case for embedded widgets (because there is one)

Before the criticism, the fair acknowledgement: there are legitimate reasons businesses embed booking widgets, and they're not all wrong.

You get a single source of truth for availability. The same calendar that the receptionist sees is the one the customer is booking against. No double-bookings, no manual sync, no Excel spreadsheets. If you've ever lost a customer because two people booked the same 9am slot, you understand why this matters.

You get a payment flow that already works. Calendly and Acuity handle Stripe webhooks, send receipts, manage refunds, and survive Stripe API changes. Replacing that with a custom build is a non-trivial amount of engineering.

You get features that compound. Group classes, recurring appointments, intake forms, package management, calendar sync. Building these from scratch is months of work; clicking a checkbox in Acuity is five minutes.

For a solo operator with 20 bookings a week and a website that's not heavily trafficked, embedding the widget is rational. The trade-offs we're about to describe become problems at scale.

The performance problem

Booking widget iframes are slow. This is structural, not a bug.

A standard Calendly embed loads:

The iframe HTML shell
Calendly's JavaScript bundle (typically 280-400KB)
Calendly's CSS
A WebSocket connection for real-time availability
Several API calls to fetch event types, availability, and timezone data
Web fonts (often Inter or Lato, served from a CDN)
Analytics calls back to Calendly

We measured a real client embed last month. The booking widget took 4.7 seconds to become interactive on a 4G connection. The rest of the page took 1.4 seconds. Customers who arrived on the booking page from a Google search waited an average of 3.3 seconds staring at an empty iframe before the widget loaded.

Google's Core Web Vitals considers anything over 2.5 seconds for Largest Contentful Paint to be poor. If the widget is the largest element on your page, you're failing CWV by default. That has direct SEO consequences.

The numbers we see across audits:

Average widget load time: 3.8 seconds (range 2.1-7.4)
Average page load time without widget: 1.6 seconds
Bounce rate on widget pages vs landing pages: 18% higher on widget pages
Mobile conversion rate on embedded widget vs native form: 42% lower

That last number is the one that should make you uncomfortable.

The mobile problem nobody talks about

On desktop, a Calendly or Acuity widget looks fine. The iframe sits in your page, the calendar appears, the user clicks a time slot.

On mobile — which is 65-75% of traffic for most Australian service businesses — the widget has to render inside a constrained viewport. The iframe doesn't know about your page's responsive breakpoints. It has its own. They don't match.

The most common failure modes we see:

Horizontal scrolling. The widget renders at a width wider than the viewport. Users get a horizontal scroll on the iframe inside a non-scrolling parent.
Tap target size. Calendly's date squares are about 36x36 pixels by default. Apple's accessibility guidelines say 44x44 minimum. On smaller phones, users mis-tap.
Keyboard hiding the form. When the intake form opens after slot selection, the on-screen keyboard covers the next/submit button. Users can't see what they're doing.
Back-button confusion. Inside an iframe, the device back button often exits your site instead of going back one step in the widget.

None of these are user errors. They're product errors caused by embedding a third-party app inside your responsive site.

The branding problem

You spent months getting the typography right. You agonised over the button colour. You hired a designer to nail the spacing.

Then you embed a Calendly widget and your customer sees Calendly's typography, Calendly's button colour, Calendly's spacing. The free plan also shows "Powered by Calendly" at the bottom. Acuity does the same unless you're on the USD $61/month Premium plan.

The visual whiplash from "your branded marketing page" to "the third-party booking iframe" is jarring. We've watched session recordings on Hotjar and Microsoft Clarity where users visibly hesitate when the widget loads. They're trying to figure out if they're still on your site.

The bigger the price ticket of the service, the more the brand mismatch matters. Booking a $40 haircut, no one cares. Booking a $4,000 wedding photographer, the visual inconsistency reads as unprofessional.

The conversion problem

Here's the bit that should actually motivate you to do something.

We pulled data from 14 Australian service-business sites where we've replaced an embedded widget with a custom booking flow that uses the same backend (Acuity or Cliniko via their APIs). Same calendar, same availability, same payment processor. Just rebuilt the front-end as a native part of the site instead of an iframe.

Average conversion rate lift: 34%. Range: 12% to 71%.

The wins came from a few places:

Faster load. The booking page now loads in 1.4 seconds instead of 4.5.
Better mobile UX. Native date pickers, properly sized tap targets, no horizontal scroll.
Visual continuity. The booking flow looks like the rest of the site.
Better intake flow. Custom flows can ask the right questions in the right order, hide irrelevant fields, and personalise based on service selection.
Recovery from errors. When a slot becomes unavailable mid-booking, a native flow can handle it gracefully. An iframe usually just shows an error screen.

On a service business doing 200 bookings a month at AU$200 average, a 34% lift is roughly AU$13,600 a month in additional revenue. Annualised, that's AU$163,200. The custom front-end rebuild typically pays back in under three months.

The hybrid approach we actually recommend

You don't need to throw out your booking SaaS to fix the iframe problem. The approach we use is:

Keep Acuity, Cliniko, or whatever booking backend you're on. Don't rebuild what works.
Use their API instead of their embed. Acuity, Cliniko, Calendly, Setmore, Cal.com — they all have APIs. Some are better than others.
Build a native booking flow on your site that calls the API. Available slots come from the SaaS. The UI is yours.
Send the booking back to the SaaS for confirmation, payment, reminders. Keep the SaaS doing what it's good at.

This gets you the data integrity of the SaaS (one source of truth, no double-bookings) with the performance and brand consistency of a native experience.

The build cost varies by which SaaS you're integrating with. Acuity's API is well-documented and stable. Cliniko's is solid. Calendly's is workable. HotDoc requires a partner agreement. Typical build cost: AU$8,000-18,000 depending on how complex the flow is.

What "API-first booking" actually looks like in the build

For founders who haven't seen this pattern before, a quick walk-through of what the native-front-end-with-SaaS-backend approach actually involves. We mention this because the term "API integration" is doing a lot of work in agency proposals and isn't always the same thing.

The booking page on your site does five things:

On load, fetches available slots from the SaaS API (filtered by service, staff, date range)
Renders a calendar UI that matches your site's design
Collects the customer details and intake form responses
Calls the SaaS API to reserve the slot and process payment (often via Stripe)
Sends the customer to a branded confirmation page on your site, while the SaaS handles email and SMS reminders behind the scenes

What this isn't: a copy-paste of the SaaS's data into your database. The SaaS is still the source of truth for availability and bookings. Your site is just the front-end customers interact with.

The implementation typically takes 60-120 hours depending on the complexity of the intake flow and the quirks of the SaaS API. Acuity's API is the most pleasant to work with. Cliniko's requires authentication via API key and has rate limits worth designing around. Calendly's V2 API became more capable in 2024 but still has gaps around custom intake. HotDoc requires a commercial partner agreement before you get API access.

For sites already on the SaaS, this is a non-disruptive change. The SaaS subscription continues, the calendar stays in sync, the reminders keep sending. The customer-facing booking experience just gets dramatically better.

The few cases where the embed is fine

To be honest with you, the iframe isn't always wrong. Cases where we'd tell a client to leave it alone:

Low-traffic informational sites. If you get 80 visitors a month and you're doing okay, the rebuild cost won't pay back.
Internal booking pages. A page that only existing customers reach via a link in a confirmation email — the conversion economics don't apply.
Genuinely simple flows. A single event type, no payment, one staff member. The widget overhead is small enough not to matter.
Calendly-style "share a link" usage. When the entire purpose is "send me a link to book a chat," embedding doesn't apply — you're not converting traffic, you're scheduling a known counterparty.

If none of those apply to you, the embedded widget is leaving money on the table.

The diagnostic test you can run in five minutes

Open your booking page on your phone. Time how long it takes from the moment you hit enter on the URL to the moment you can tap a date. Record it.

Now open your homepage and time how long it takes to tap your "book now" CTA. Same metric: URL entered to interactive.

If the booking page is more than 2x slower than the homepage, the widget is hurting you. If it's more than 3x slower, the widget is the single biggest conversion problem on your site.

We've audited businesses where the homepage loads in 1.1 seconds and the booking page takes 6.8. They were spending money on Google Ads to drive traffic to a page that was actively losing them customers.

Where to start

If you suspect your widget is hurting your conversion rate, the first thing to do is measure. Set up Microsoft Clarity (it's free) on your booking page and watch 20 session recordings. You'll see the drop-off in real time. You'll see the rage-clicks. You'll see the mobile users who pinch-zoom because the calendar is too small.

Once you know the cost, the decision to rebuild gets easier. The math usually works out to "this pays itself back in 90 days." Sometimes faster.

If you want us to do the measurement for you and tell you whether a rebuild is worth it for your specific business, book a free audit. We'll watch the recordings, run the speed tests, and give you the numbers — even if the answer is "your widget is fine, fix something else first."

Why Embedded Booking Widgets Kill 40% of Bookings