Healthcare Website Speed: The Complete Healthcare Performance Guide for 2026

Healthcare websites are slow because of patient portal integrations (Epic MyChart, Athenahealth — 500KB–1.5MB JavaScript), appointment scheduling widgets (Zocdoc, Doctolib, proprietary — 300KB–800KB), telehealth video tools (Doxy.me, Zoom Health — 400KB–1MB), provider directory databases with search/filter functionality, and compliance scripts (HIPAA consent, ADA overlays, cookie managers — 500KB–1.5MB). Quick wins: 1) Implement facade patterns for chat widgets, scheduling tools, and telehealth launchers (saves 1–3MB combined). 2) Defer patient portal login scripts to the portal page only — don't load globally. 3) Preload hero images with fetchpriority='high' and convert to WebP. 4) Use static provider directory pages with edge caching instead of client-side database queries. 5) Defer analytics and marketing pixels until after page interaction. 6) Load ADA overlays on demand, not on page load. 7) Use a CDN with edge caching for sub-200ms TTFB. 8) Monitor with CrUX field data — real-user performance determines rankings for high-value local healthcare keywords.

In healthcare, page speed directly impacts patient acquisition, satisfaction, and ultimately health outcomes. The economics make speed optimization one of the highest-ROI investments any healthcare organization can make.

The Patient Acquisition Economics: Healthcare has significant digital marketing costs:

• Primary Care PPC: $15–$35 per click
• Dental: $10–$30 per click
• Orthopedics/Surgery: $25–$60 per click
• Dermatology: $15–$40 per click
• Mental Health: $20–$50 per click
• Urgent Care: $15–$35 per click

When a $30 click lands on a page that takes 5 seconds to load, and Google's research shows 53% of mobile users abandon after 3 seconds, you're burning $15–$20 per abandoned visitor — before they even see your appointment booking form.

Consider a multi-location practice spending $30,000/month on Google Ads:

• At 35% bounce rate (fast pages): 650 engaged visitors → 130 appointment requests (20% booking rate) → 104 new patients (80% show rate) → $52,000 in first-year revenue
• At 55% bounce rate (slow pages): 450 engaged visitors → 90 appointment requests → 72 new patients → $36,000 in first-year revenue
• Monthly revenue difference: $16,000 from the same ad spend — $192,000 annually

The Organic SEO Imperative: Organic rankings for healthcare keywords are enormously valuable because they eliminate per-click costs entirely. A single first-page ranking for 'family doctor [city]' or 'urgent care near me' can generate $200,000+ in annual patient revenue from organic traffic alone. Core Web Vitals are a confirmed ranking signal, and with only 44% of healthcare sites passing, optimization creates a genuine competitive moat.

Patient Lifetime Value: Unlike e-commerce, healthcare patients represent long-term recurring revenue:

• Primary care patient: $1,500–$3,000/year × 5–10 year average retention = $7,500–$30,000 LTV
• Dental patient: $800–$2,000/year × 5–8 years = $4,000–$16,000 LTV
• Specialty referral patient: $3,000–$15,000 per episode of care
• Every speed-related bounce doesn't just lose an appointment — it loses years of patient revenue and referral potential.

The Trust Factor: Healthcare is unique: patients evaluate credibility partly through website quality. A slow, clunky website signals outdated technology and undermines trust in clinical capabilities — even though the two are unrelated. Studies show patients associate website quality with care quality, making speed a trust signal.

Healthcare websites face a unique combination of performance challenges driven by regulatory requirements, complex integrations, and patient-facing tools.

1. Patient Portal Integrations: The patient portal is essential for modern healthcare but devastating for performance:

• Epic MyChart: 600KB–1.5MB JavaScript + iframe integration
• Athenahealth Patient Portal: 400KB–1MB
• Cerner/Oracle Health: 500KB–1.2MB
• eClinicalWorks: 300KB–800KB
• Proprietary portals: Variable, often unoptimized

The critical mistake: loading portal scripts globally across ALL pages when they're only needed on the portal login page.

2. Appointment Scheduling Widgets: Online scheduling is the primary conversion action on healthcare sites:

• Zocdoc embedded widget: 400KB–800KB JavaScript
• Doctolib integration: 300KB–600KB
• DrChrono scheduling: 200KB–500KB
• Proprietary scheduling systems: 300KB–1MB (often the heaviest)
• Calendar/availability checkers with real-time API calls

3. Telehealth & Video Integration: Post-2020, telehealth tools are standard on healthcare sites:

• Doxy.me launcher: 400KB–800KB
• Zoom Health integration: 500KB–1MB
• Teladoc/Amwell widgets: 300KB–700KB
• Video consultation launchers with pre-check functionality

4. Compliance & Regulatory Scripts: Healthcare faces unique compliance requirements:

• HIPAA consent/notice banners: 50KB–200KB
• ADA accessibility overlays (UserWay, accessiBe): 200KB–500KB with DOM manipulation
• Cookie consent managers (OneTrust, Cookiebot): 100KB–400KB, often render-blocking
• BAA-compliant analytics tools: Variable
• Security monitoring/fraud detection: 100KB–300KB

Combined compliance overhead: 500KB–1.5MB of JavaScript.

5. Provider Directory & Search: Provider directories are among the most-visited pages:

• Client-side search/filter with full provider database loaded
• Provider photos served at full resolution (2000×2000px headshots)
• Interactive maps with Google Maps or Mapbox integration
• Insurance/plan filtering with complex conditional logic
• Distance/location sorting requiring geolocation API

6. Marketing Stack: Healthcare organizations run aggressive patient acquisition campaigns:

• Analytics: GA4, Adobe Analytics, healthcare-specific platforms
• Call tracking: CallRail, Invoca (critical for healthcare — phone calls drive appointments)
• Retargeting: Google Ads, Facebook (with healthcare advertising restrictions)
• CRM: Salesforce Health Cloud, HubSpot
• Reputation management: Healthgrades, Vitals, RateMDs widgets
• Review solicitation tools
• Session recording: Hotjar, FullStory

The average healthcare website loads 15–22 third-party scripts.

Understanding benchmarks helps set targets and quantify competitive advantage in healthcare's local search landscape.

Core Web Vitals Pass Rates — Healthcare vs. Other Industries (2026 CrUX Data):

Healthcare performs slightly better than insurance and real estate but still has 56% of sites failing at least one CWV metric.

Healthcare Page Speed Benchmarks:

The gap between top-performing and average healthcare sites is substantial. Top-10% sites are 2x faster with 60% less JavaScript. Given that healthcare is primarily a local business, this performance gap directly affects Local 3-Pack rankings and patient acquisition in specific geographic markets.

A healthcare-specific performance audit must cover patient-facing pages, provider directories, portal integrations, and appointment flows — each has distinct bottlenecks.

Step 1: Audit the Right Pages (by Patient Acquisition Impact) Prioritize pages by their revenue contribution:

• Homepage — Often the organic and direct entry point
• Service/condition pages (orthopedics, cardiology, etc.) — High-intent organic traffic
• Provider/doctor profile pages — Critical for 'doctor near me' searches
• Provider directory with search/filter — Highest interaction complexity
• Appointment booking/scheduling page — Primary conversion action
• Location/office pages — Local SEO entry points
• Patient portal login page — High daily traffic from existing patients
• Blog/health education content — Top-of-funnel organic traffic

Test at least 2–3 examples of each page type in PageSpeed Insights.

Step 2: Scheduling Widget Performance Profiling The appointment scheduling flow deserves dedicated testing:

• Open Chrome DevTools → Performance panel → record while selecting a provider, choosing a time slot, and completing booking
• Look for Long Tasks triggered by availability API calls, calendar rendering, and insurance verification
• Measure INP for each interaction: provider selection, date picker, time slot clicks, form field inputs
• Check if availability checks block the main thread during slot selection

Step 3: Provider Directory Profiling Provider directories are often the heaviest pages:

• How much data is loaded on initial page load? (Full provider database vs. paginated)
• Are provider photos optimized? (Check dimensions and format)
• Does search/filter trigger client-side rendering of large datasets?
• Is Google Maps loaded on every directory page or only when requested?

Step 4: Third-Party & Compliance Script Inventory Chrome DevTools → Network tab → sort by domain:

• List every external script with size, execution time, and purpose
• Identify portal scripts loading on non-portal pages
• Flag duplicate analytics (GA4 + Adobe Analytics + healthcare-specific platform)
• Check if telehealth scripts load on every page vs. only telehealth pages
• Categorize as essential (immediate), deferrable, or removable

Step 5: Revenue Impact Calculation Calculate the dollar cost of slow pages:

• (Monthly ad spend × bounce rate increase from speed) = wasted ad spend
• (Bounce rate improvement × traffic × booking rate × show rate × average patient revenue × retention years) = annual patient revenue recovered
• (Organic ranking improvement × estimated traffic gain × booking rate × patient LTV) = organic revenue impact

The appointment scheduling widget is the conversion centerpiece of every healthcare website. Optimizing it for speed directly increases appointment bookings and new patient acquisition.

Facade Pattern for Scheduling Widgets (Critical Quick Win): Most scheduling widgets load 300KB–800KB of JavaScript on page load, even though users don't interact with them immediately:

1. Display a lightweight HTML/CSS 'Book Appointment' button or mini-form (identical appearance)
2. On click, dynamically load the actual scheduling widget JavaScript
3. Show a brief loading indicator (200–500ms), then open the full scheduling interface

This single change typically improves LCP by 500ms–1.5s and eliminates scheduling widget JavaScript from initial CWV assessment.

Optimizing Embedded Scheduling: If scheduling is embedded inline (not modal):

• Use Intersection Observer to load the scheduling widget when it scrolls into view
• Pre-connect to the scheduling API endpoint on page load
• Render a skeleton placeholder matching the widget's dimensions (prevents CLS)
• Cache provider availability at the edge (update every 5–15 minutes for near-real-time accuracy)

Provider Selection Optimization:

• Don't load all providers' availability simultaneously — load on selection
• Use debounced search for provider name filtering (300ms delay)
• Paginate provider lists — show 10–20 at a time, not hundreds
• Cache provider photos as WebP thumbnails (100×100px for lists, 400×400px for profiles)

Calendar & Time Slot Performance:

• Render calendar UI with CSS Grid (no JavaScript library needed for basic calendars)
• Load available time slots via lightweight API call, not full scheduling engine
• Use optimistic UI: show the slot as selected immediately, confirm via API in background
• Pre-fetch next week's availability when current week is displayed

Insurance Verification:

• Don't load insurance verification on the scheduling page by default
• Offer 'Verify Insurance' as an optional step after appointment selection
• Use server-side verification via edge function — zero client-side JavaScript
• Cache insurance plan lists at the edge (plans change infrequently)

Patient portal and telehealth integrations are essential but commonly implemented in ways that destroy site-wide performance.

Portal Script Isolation (Critical): The most common mistake: loading Epic MyChart, Athenahealth, or other portal scripts globally across every page. These scripts are only needed on the portal login page.

Fix:

• Load portal JavaScript ONLY on /patient-portal or equivalent routes
• Use route-based code splitting in your SPA framework
• For server-rendered sites, conditionally include portal scripts only on portal templates
• This single change can reduce JavaScript on non-portal pages by 500KB–1.5MB

Portal Login Page Optimization: Even on the portal page itself, optimize the integration:

• Lazy-load the portal iframe/widget after the page's LCP element renders
• Pre-connect to the EHR system's authentication endpoint
• Use a lightweight login form that redirects to the full portal — don't embed the entire portal
• Cache portal branding assets (logos, stylesheets) locally

Telehealth Launch Optimization: Telehealth tools (Doxy.me, Zoom Health) add 400KB–1MB:

• Never load telehealth scripts on non-telehealth pages
• On telehealth pages, use a facade: show 'Start Video Visit' button → load platform on click
• Pre-connect to the video platform's servers on page load (connection ready when needed)
• For scheduled visits, send a direct telehealth link via email/SMS — bypass the website entirely

Patient Form Pre-fill:

• New patient intake forms are often heavy (15–30 fields with validation)
• Code-split form JavaScript by section (demographics, insurance, medical history)
• Pre-fill from existing patient data where available (returning patients)
• Use native HTML validation as first layer before loading JS validation libraries
• Save form progress to sessionStorage for interrupted sessions

Provider directories are often the most-visited and heaviest pages on healthcare sites. They're also critical for local SEO.

Static Generation for Provider Pages (Highest Impact): Instead of client-side rendering from a database on every visit:

• Generate static HTML pages for each provider at build time (SSG)
• Include structured data (Physician schema, LocalBusiness) in the static HTML
• Rebuild only when provider data changes (ISR — Incremental Static Regeneration)
• Result: near-zero TTFB, instant rendering, perfect for SEO

Provider Photo Optimization: Provider headshots are a major performance issue:

• Source photos are typically 2000×2000px JPEG (500KB–2MB each)
• Directory listing: serve 100×100px WebP thumbnails (5–10KB each)
• Profile page: serve 400×400px WebP (20–40KB)
• Use srcset for responsive serving: `srcset='photo-100.webp 100w, photo-400.webp 400w'`
• Lazy-load all photos below the first 3–4 visible providers
• Use blur-up placeholder technique for perceived performance

Directory Search & Filter:

• Don't load the entire provider database client-side — use server-side search with edge caching
• Debounce search input (300ms) to prevent excessive API calls
• Use faceted filtering (specialty, location, insurance) with URL parameters for SEO
• Paginate results (15–20 per page) with proper pagination markup
• Cache filtered results at the CDN edge (common filter combinations)

Maps Integration:

• Use static map images for directory overview (Google Static Maps API — single image, zero JavaScript)
• Load interactive Google Maps only on 'View on Map' click (facade pattern)
• For individual provider pages, use a static map with a link to Google Maps directions
• Pre-connect to maps API endpoint if interactive map is likely needed

Local SEO Schema: Each provider page should include:

• Physician schema (name, specialty, hospital affiliation, accepting new patients)
• LocalBusiness schema (practice address, hours, phone)
• MedicalOrganization schema (for the practice/health system)
• BreadcrumbList (Home > Providers > [Specialty] > [Provider Name])
• AggregateRating if reviews are displayed

Location Pages: For multi-location practices:

• Create dedicated pages per location with unique content
• Include embedded maps (static facade → interactive on click)
• List providers at each location with links to their profiles
• Use LocalBusiness schema with geo-coordinates
• Optimize for 'near me' queries with proper NAP (Name, Address, Phone) consistency

Healthcare compliance scripts are unique burdens. Here's how to optimize each type without regulatory risk.

HIPAA Notice/Consent Banners: The Problem: Many healthcare sites display HIPAA notices as render-blocking modals or banners.

Optimization:

• HIPAA does NOT require render-blocking consent for website browsing — only for collecting PHI (Protected Health Information)
• Display HIPAA notices as non-blocking banners or footer text
• Only show interactive consent when users access forms that collect PHI (appointment booking, patient intake)
• This is a common misconception that causes unnecessary performance impact

ADA Accessibility Overlays: The Problem: Accessibility overlays add 200KB–500KB and perform heavy DOM manipulation.

Optimization:

• Build accessibility natively: semantic HTML, proper contrast ratios, keyboard navigation, ARIA labels
• Native accessibility is both better for compliance AND better for performance
• If using an overlay: defer loading until user clicks the accessibility icon
• Healthcare sites face higher ADA scrutiny — invest in native accessibility, not overlay band-aids

Cookie Consent Managers: Optimization:

• Load asynchronously — consent banner appears over rendered content, not before it
• Cache consent decisions: returning patients shouldn't re-load the full CMP
• Consider a lightweight, custom consent implementation (10KB vs. 200KB+ for enterprise CMPs)
• HIPAA-specific consent is different from GDPR cookie consent — don't conflate them

BAA-Compliant Analytics: Healthcare requires Business Associate Agreements (BAAs) for analytics processing PHI:

• GA4 with BAA: Standard implementation, no additional JavaScript overhead
• Freshpaint (healthcare-specific): 30KB, lighter than typical analytics alternatives
• Piwik PRO: Self-hosted option, zero third-party data transfer
• Load all analytics async — none need to be render-blocking

Security & Fraud Prevention:

• Load reCAPTCHA only on form pages, triggered on form focus
• Use server-side rate limiting instead of client-side fraud detection where possible
• Implement CSP (Content Security Policy) headers for security without JavaScript overhead

Healthcare websites run on various platforms, each with different optimization opportunities.

WordPress (Most Common for Practices):

• The most popular CMS for independent practices and small health systems
• Replace heavy multi-purpose themes with lightweight options (GeneratePress, flavor flavor)
• Use WP Rocket for caching, critical CSS, and script deferral
• Install Perfmatters for per-page script management — disable portal scripts on non-portal pages
• Use Gravity Forms or WPForms for patient intake (lighter than embedded EHR forms)
• Implement Redis object caching for provider directory queries
• See our WordPress speed guide

Custom / Headless CMS (Health Systems):

• Best performance potential — full control over portal integration and compliance scripts
• Use static generation (SSG) for provider profiles, location pages, and educational content
• Server-render appointment scheduling for instant first paint
• Implement edge rendering for geo-personalized content (nearest location, available providers)
• Use React Server Components for non-interactive sections (condition descriptions, provider bios)

Drupal (Common for Large Health Systems):

• Drupal is popular for large healthcare organizations due to its robust permissions and content modeling
• Use BigPipe for progressive page rendering
• Enable Varnish/CDN edge caching aggressively for provider and location pages
• Optimize Views queries for provider directories (avoid N+1 query problems)
• See our Drupal speed guide

HubSpot (Healthcare Marketing):

• Common for healthcare marketing teams managing content and lead generation
• Focus on reducing HubSpot modules per page
• Use HubSpot native forms instead of third-party alternatives
• Minimize custom HubL modules that add JavaScript
• See our HubSpot speed guide

Proprietary Healthcare Platforms:

• Some health systems use proprietary website platforms tied to their EHR
• Focus on what you can control: image optimization, third-party script reduction, CDN
• Advocate with vendor for performance improvements
• Consider a separate marketing/patient acquisition site with EHR API integration

For healthcare sites already passing basic CWV, these advanced techniques create competitive separation.

Speculation Rules for Patient Journeys: Pre-render the next step in the patient's likely journey:

<script type="speculationrules"> { "prerender": [{ "urls": ["/book-appointment", "/find-a-doctor"] }] } </script>

When a patient is on a condition/service page, pre-render the appointment booking page. When they're browsing the provider directory, pre-render the top provider profiles. This makes the patient acquisition funnel feel instant.

Edge-Side Personalization: Instead of client-side JavaScript for geo-personalization:

• Detect visitor location at the edge → show nearest clinic location, available providers, and hours
• Display relevant services based on geo (e.g., seasonal services: flu shots in fall, allergy in spring)
• Route to nearest location's booking page without client-side geolocation scripts
• Serve location-specific insurance acceptance lists

AI-Powered Symptom Checkers: Symptom checkers are increasingly common on healthcare sites. Performance considerations:

• Use edge-deployed AI models for sub-200ms response times
• Implement as a progressive interaction: start with a lightweight text input, load the full checker on engagement
• Don't load the entire symptom database client-side — use server-side inference
• Cache common symptom-to-specialty mappings at the edge

Progressive Provider Profiles: Load provider information progressively:

1. First paint: Name, photo, specialty, 'Book Appointment' CTA (static HTML)
2. On scroll/interaction: Full bio, credentials, publications
3. On demand: Reviews/ratings (load from API)
4. On click: Availability calendar (scheduling widget facade)

This keeps provider pages under 1.5s LCP while maintaining rich content.

Real-Time Availability Indicators: Show 'Next Available: Tomorrow at 2 PM' on provider cards without heavy scheduling widget JavaScript:

• Cache availability summaries at the edge (update every 15 minutes)
• Serve as static text in the HTML — zero JavaScript needed
• Full scheduling widget loads only when user clicks to book

Server-Side A/B Testing: Healthcare organizations test landing pages, but client-side A/B tools add 200–500ms:

• Test at the edge (Cloudflare Workers, Vercel Edge Middleware) — zero client-side impact
• Deploy variant pages as separate URLs and route server-side
• Track conversions server-side via GTM Server-Side

For healthcare, local organic rankings drive the majority of new patient acquisition. Speed optimization directly supports local search dominance.

Local Keyword Value: Healthcare local keywords have significant value:

• 'Primary care doctor [city]' — $15–$30 CPC, high volume
• 'Urgent care near me' — $20–$35 CPC, extremely high intent
• '[Specialty] specialist [city]' — $25–$60 CPC
• 'Dentist near me' — $10–$25 CPC, very high volume
• 'Pediatrician [city]' — $15–$30 CPC

With only 44% of healthcare sites passing CWV, organic ranking improvements from speed optimization can be worth $100,000–$500,000+ annually in avoided ad spend.

Local 3-Pack Dominance: The Google Local 3-Pack appears for virtually all healthcare searches:

• CWV is a ranking factor for both organic results and the local pack
• Speed-optimized location pages with proper LocalBusiness schema outperform slower competitors
• Google Business Profile click-throughs inherit the page's CWV assessment
• Fast-loading location pages with clear NAP, hours, and booking CTAs correlate with higher local rankings

Content Strategy for Healthcare Performance: Health education content is a major organic traffic driver:

• Condition/treatment pages should be the fastest on your site (no scheduling widget, no portal)
• Use SSG for health articles — near-zero TTFB
• Implement MedicalCondition and MedicalProcedure schema for rich results
• Implement FAQ schema on symptom and treatment pages
• Internal link from educational content to appointment booking pages
• Lazy-load supplementary content (related conditions, provider recommendations) below the fold

E-E-A-T for Healthcare (Critical): Google applies YMYL (Your Money or Your Life) scrutiny to healthcare content:

• Author attribution on health articles (link to provider profiles with credentials)
• Medical review dates and reviewer credentials
• Citations to peer-reviewed sources
• These E-E-A-T signals MUST be in the initial HTML — not lazy-loaded — for Google to properly evaluate them

Schema Markup for Healthcare:

• MedicalOrganization schema on practice/system pages
• Physician schema on provider profiles (with specialty, affiliation, credentials)
• LocalBusiness schema on location pages (with geo-coordinates)
• MedicalCondition schema on condition pages
• FAQPage schema on symptom and treatment FAQ pages
• BreadcrumbList for site navigation hierarchy

Scheduling & Patient Intake:

• Zocdoc (embedded widget) — Popular patient scheduling with facade-friendly implementation
• NexHealth ($300+/mo) — Modern scheduling API, lighter widget than legacy EHR integrations
• Acuity Scheduling ($16–$49/mo) — Lightweight scheduling for smaller practices
• Typeform / Jotform HIPAA ($99+/mo) — BAA-compliant intake forms, lighter than EHR-embedded forms

Compliance:

• Complianz (Free–€45/yr, WordPress) — Self-hosted cookie consent, no external JavaScript
• Osano ($0–$199/mo) — Lightweight cookie consent (smaller than OneTrust)
• axe DevTools (Free) — Test native accessibility without needing overlays
• WAVE (Free) — Web accessibility evaluation tool

Caching & CDN:

• Cloudflare (Free–$200/mo) — CDN, WAF (important for healthcare), HTTP/3, edge caching, BAA available
• WP Rocket ($59/yr) — WordPress caching with critical CSS and script deferral
• Vercel (headless/Next.js) — Edge delivery, ISR for provider pages, zero-config performance

Performance Monitoring:

• SpeedCurve ($15–$525/mo) — Continuous CWV monitoring with competitive benchmarking
• DebugBear ($79–$249/mo) — CrUX tracking with regression alerts
• PageSpeed Insights — Quick CWV diagnostics with field + lab data
• Google Search Console — Site-wide CWV monitoring grouped by URL template

Analytics (HIPAA-Compliant):

• GA4 with BAA — Standard Google Analytics with business associate agreement
• Freshpaint ($$$) — Healthcare-specific analytics, automatic PHI redaction
• Piwik PRO — Self-hosted, EU-compliant, healthcare-friendly
• Plausible/Fathom ($9–$25/mo) — Privacy-focused, lightweight (1KB), no PHI concerns

Call Tracking:

• CallRail ($45+/mo) — Lightweight async script, HIPAA-compliant option available
• Invoca — Enterprise call tracking with healthcare vertical support
• Load all call tracking scripts asynchronously

Passing all three CWV metrics is the practical bar for ranking — our Core Web Vitals optimization service focuses on exactly this.

Hero-image priority, font loading, and render-blocking removal are the big LCP levers — see our LCP optimization service.

INP failures usually trace to long JavaScript tasks — our INP optimization service profiles and fixes them.

CLS is usually fixable in days — our CLS optimization service handles font-loading, image sizing, and dynamic content shifts.

Render-blocking CSS and JS is the most common LCP killer — our render-blocking resource removal service eliminates it.

Marketing scripts can add 1-3s of LCP delay — our third-party script optimization service tiers and defers them.

Lead-form pages and quote calculators are the priority — see our insurance website speed optimization.

Booking funnel speed is the lever — see our hospitality website speed optimization.

Metric	Good	Needs Improvement	Poor
LCP (Largest Contentful Paint)	≤ 2.5s	2.5s – 4.0s	> 4.0s
INP (Interaction to Next Paint)	≤ 200ms	200ms – 500ms	> 500ms
CLS (Cumulative Layout Shift)	≤ 0.1	0.1 – 0.25	> 0.25
TTFB (Time to First Byte)	< 220ms	220–680ms	> 680ms
Total JavaScript (compressed)	< 220KB	220–580KB	> 580KB
Provider Directory Load	< 1.5s	1.5–4.2s	> 4.2s
Third-Party Scripts	< 7	7–18	> 18
Mobile Lighthouse Score	80+	45–79	Below 45