What TutorBird gives a website
Two things, and they behave very differently.
A hosted route: links into your TutorBird registration form, booking calendar and parent portal, which open on TutorBird's own domain. Nothing runs on your site at all.
An embedded route: a widget or iframe you paste into a page so the form or calendar appears inside your own layout. Convenient, and the source of nearly every performance problem we see on tutoring sites. Confirm the exact embed options on your plan with TutorBird before you design around one.
The rule that keeps both fast is simple.
The rule: nothing third party loads until the parent taps Book
A tutoring site's job is to be fast on a parent's phone at ten at night on a weak connection. Every third-party script in the head is paid for by every visitor on every page, including the ones who came to read your safeguarding policy.
So no booking script sitewide. No widget loading on the home page because a button is in the header. The parent taps Book a trial, and only then does anything from TutorBird enter the picture.
The booking page
Give booking one page of its own, at a clean path such as /book. Header buttons across the site point at that page, not at a widget.
On it, put a short heading, one line on what happens next, and then either the link out to TutorBird or the embed. That is the only page in the whole site allowed to carry the embed, which means one page pays the performance cost instead of thirty.
If you go hosted, link straight out. It is faster, it avoids iframe layout problems, and it is more reliable in the in-app browsers a lot of parents arrive from.
If you do embed, embed it properly
Load on interaction. Render a styled placeholder with a Load booking button, and inject the script or iframe only when it is tapped. That keeps the third-party cost off the initial page load even for people who land on /book and then leave.
Reserve the space. Give the container a fixed minimum height matched to the widget on mobile so the page does not jump when it appears. Unreserved space is the single biggest cause of a poor layout shift score on booking pages.
Set the iframe to load lazily where the embed allows it, and never nest it inside a container with its own scroll, which produces a trap where the calendar cannot be reached on a phone.
Deep links from the subject and fees pages
The button under the fees table should not dump a parent onto a generic calendar. Where TutorBird supports linking to a specific registration form or service, use those links so the trial or the correct subject and stage is already selected.
Fewer choices after the tap means more completed bookings. Test each link after any change in TutorBird, because renaming a service or a form is exactly how a live button quietly stops working.
Configure TutorBird before the site points at it
The platform decides how the booking feels, so set it up first. The trial as its own short service with its own price. Recurring weekly slots for continuing students. The parent as the account holder with the child as the student. Required fields at booking kept to parent contact, child's first name, year group and subject. Everything else asked in the confirmation.
Then brand the confirmation and reminder messages with your business name, address, what to bring, the joining link for online sessions, and a link to your safeguarding page. Parents read a confirmation more carefully than any page on your site.
Keep the phone route in the header
A tappable number next to the Book button, with the hours you answer it. Tutoring enquiries often start with a two minute conversation about a child who has had a bad year, and no widget replaces that.
Testing, especially in-app browsers
Book a test trial end to end on mobile data, then repeat it inside the Facebook and Instagram in-app browsers, where a large share of parent traffic arrives from a link in bio and where embeds and payment sheets fail most often.
Check four things: the right service was preselected, the form completed without zooming, the confirmation arrived at the parent's address, and the slot released when you cancelled the test.
Then run the booking page through a performance check on a throttled mobile profile and confirm the layout does not shift when the widget appears.
Tracking
Add events for taps on Book, taps on the phone number and form submissions, recorded by the page they came from. Ten minutes a month with that report tells you whether it is the fees page, a subject page or the home page filling your timetable, and which page to fix next.
Where this sits
Wiring TutorBird into a fast, stable booking route rather than scattering widgets across the site is part of building a children's tutoring website, and the same approach runs through our other childcare and family websites. The packages are on pricing. One booking page, loaded on demand, tested on a real phone.