The Problem With “Fast Enough”
Most developers and marketers think about landing page performance in terms of Lighthouse scores — aim for green, feel good, move on. But “green” on Lighthouse and “high performance” are not the same thing. A page that hits 75 on mobile is in Google’s yellow zone and losing patients faster than a 95-scoring competitor.
The checklist below separates the decisions that have real impact on load time, Core Web Vitals, and conversion rate from the ones that are optimizations in name only. Not everything on this list is equal — the first items matter more than the last. We’ve ordered them by impact.
The 17-Point High-Performance Landing Page Checklist
#1 — Static-First or Server-Rendered Architecture
This is the architectural decision that determines your performance ceiling before anything else. A dynamically rendered page (WordPress, Wix, Squarespace) assembles HTML on each request, pulling from a database and executing server-side code. A static-first page (Astro.js, Hugo, Eleventy) pre-renders HTML at build time and serves it directly.
The performance ceiling for each:
- Dynamic (WordPress + Elementor): Performance Score 25–65. LCP rarely under 2.5s on mobile.
- Static-first (Astro.js on Cloudflare Pages): Performance Score 90–100. LCP routinely under 1.0s.
No amount of subsequent optimization closes this structural gap. The architecture sets the ceiling on everything below.
Recommended: Astro.js for content-focused landing pages. Next.js for pages requiring significant client-side interactivity.
#2 — Edge Network Hosting
Where your landing page is hosted is as important as how it’s built. Traditional hosting serves your page from a single server location — typically Singapore or Tokyo for Indonesian customers. When a patient in Surabaya requests your page, the data travels to that server and back: 200–400ms of network overhead before a single byte renders.
Cloudflare’s network has 300+ data centers globally, including nodes in Jakarta, Surabaya, Bali, and Medan. A static page cached at the edge serves from the node nearest to the patient, reducing Time to First Byte (TTFB) to 10–30ms.
Google explicitly factors TTFB into page experience assessment. A consistent TTFB under 200ms is what separates a landing page that feels instant from one that feels like it’s loading.
#3 — Hero Image Delivery
Your hero image is almost always your Largest Contentful Paint (LCP) element — the biggest visible thing on the page. How it’s delivered determines your LCP score.
Requirements for a properly delivered hero image:
- Format: WebP or AVIF. JPEG at 2024 file sizes is unnecessary. WebP provides equivalent quality at 25–35% smaller file size; AVIF gets to 50% smaller.
- Dimensions: Explicitly specified
widthandheightattributes in HTML. Missing dimensions cause Cumulative Layout Shift (CLS) as the browser reserves no space and jumps the layout when the image loads. - Priority loading:
fetchpriority="high"andloading="eager"on the hero image. The browser should treat this as the highest-priority resource on the page. - Preload link:
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">in<head>. This starts the hero image download before the browser has even parsed the<body>. - Responsive srcset: Different image dimensions for different screen sizes. A 1400px hero image sent to a 390px mobile screen is 8× the necessary file size.
Astro’s <Image> component handles all of these automatically. WordPress + Elementor requires manual configuration of specific plugins and correct theme setup to achieve the same — and plugin conflicts frequently break the setup after updates.
#4 — Zero Render-Blocking JavaScript
Render-blocking JavaScript is code that the browser must download, parse, and execute before it can show the visitor anything. It’s the primary cause of slow First Contentful Paint (FCP) and high Total Blocking Time (TBT).
The standard WordPress plugin stack adds 300–700KB of JavaScript that must execute before the page renders: jQuery (87KB), Elementor runtime (200KB+), analytics scripts, chatbot scripts, form plugin scripts. Each one blocks rendering.
The target is zero render-blocking JavaScript for the initial paint. Analytics, chatbots, and non-critical interactive elements should be deferred or loaded asynchronously after the main content is visible.
Astro ships zero JavaScript for static content by default. Interactive elements (forms, sliders) use Astro’s Islands architecture — only the specific interactive component loads JavaScript, not the entire page.
#5 — Self-Hosted, Preloaded Fonts
Google Fonts is convenient and widely used. It’s also a performance liability. Loading fonts from an external CDN adds DNS resolution time, a separate HTTP connection, and a render-blocking stylesheet before your custom font displays.
Until the custom font loads, the browser shows either a flash of invisible text (FOIT) or a flash of unstyled text (FOUT) — both of which contribute to Cumulative Layout Shift and a jarring user experience.
The correct approach: download font files (typically WOFF2), self-host them in your project, and preload them in <head>:
<link rel="preload" href="/fonts/inter-latin-400.woff2" as="font" type="font/woff2" crossorigin="anonymous">This eliminates the external DNS request, the separate connection, and the render-blocking stylesheet. The font is ready before the browser paints the first text.
#6 — Scoped CSS (No Global Bloat)
WordPress themes and page builders load a global CSS file for every page on the site, including styles for sections, templates, and components that don’t appear on the current page. A clinic landing page with 8 sections loads CSS for the e-commerce templates, portfolio grids, and archive pages it doesn’t use.
Astro’s component-scoped styles generate CSS that contains only the styles used by the components on the current page. The total CSS for a clinic landing page is typically 8–15KB. A WordPress + Elementor page loads 80–200KB of CSS.
Unused CSS is parsed by the browser and discarded — a computation cost that adds 50–200ms of style processing time on slower devices.
#7 — Deferred, Not Blocking Analytics
Google Analytics 4 and similar tools represent real functionality that landing pages legitimately need. But loading analytics scripts in a way that blocks rendering is a performance anti-pattern.
The correct implementation:
- Load GA4 after
requestIdleCallback— the browser’s signal that it has spare processing capacity - Never load analytics in
<head>withoutasyncordeferattributes - For paid ad landing pages where conversion tracking is critical, load the tracking pixel immediately but defer the full analytics suite
This approach maintains full analytics data while reducing analytics’ contribution to Total Blocking Time from 80–150ms to effectively zero.
#8 — Optimized Above-the-Fold Content
Everything visible without scrolling — the above-the-fold content — should load and render before the browser begins loading below-the-fold content. This sounds obvious but requires explicit implementation.
For images below the fold: loading="lazy". They fetch only when the patient scrolls near them.
For JavaScript that powers below-fold interactive sections: load it asynchronously and only when needed.
The above-fold rendered HTML — hero image, headline, CTA button — should require zero JavaScript to appear. If removing all JavaScript from your page’s <head> breaks your hero section, you have a render-blocking dependency to fix.
#9 — Single, Unambiguous Above-Fold CTA
This is a copy and UX requirement, not a performance one, but it directly affects conversion rate more than any individual technical optimization.
Above the fold, there should be one call-to-action with one destination. Not “Book Now / Learn More / Contact Us / Download Brochure.” One action.
For Indonesian clinic landing pages: a WhatsApp button with a pre-filled message is almost universally the highest-converting CTA. Patients are in WhatsApp constantly. The friction of filling a form or making a phone call is higher than tapping a WhatsApp link.
Above-fold real estate is your most expensive space. Use it for the one action you most want patients to take.
#10 — Mobile-First Viewport Testing
Design and test on the smallest screen you expect patients to use — typically 390px width (iPhone 15) — before testing on desktop. Most clinic landing pages are designed desktop-first and then “made responsive,” which is working backward from real patient behavior.
72% of Indonesian web traffic comes from mobile devices (StatCounter 2024). A landing page that performs well on WiFi in a design review and poorly on 4G in a waiting room is performing poorly where patients actually are.
Test on a real device over real mobile network conditions, not just in Chrome DevTools’ device emulator.
#11 — No Unnecessary Third-Party Scripts
Every third-party script — chatbots, social media share buttons, heatmap tools, pop-up builders — adds an external HTTP request, potential render-blocking behavior, and a privacy consideration.
For a landing page optimized for conversions, the question to ask for every third-party script is: does this script directly increase the number of patients who book? If the answer isn’t clearly yes, it shouldn’t be on the page.
For WhatsApp chatbot overlays specifically: they frequently conflict with mobile scroll behavior and add 50–200KB of JavaScript. A simple pre-filled WhatsApp link achieves the same outcome with zero JavaScript.
#12 — Explicit Image Dimensions Everywhere
Every image on the page — not just the hero — needs explicit width and height attributes. When these are missing, the browser doesn’t know how much space to reserve for the image while it loads. The result: the layout shifts as images appear, which is measured as Cumulative Layout Shift (CLS).
CLS above 0.1 is a Core Web Vitals failure. Google considers CLS a direct measure of visual stability and uses it as a ranking signal. Even if patients don’t consciously notice the jumping layout, they feel it as an unpolished, unreliable experience.
#13 — Local SEO Markup on the Page
This is about search ranking, not page speed. But it belongs on a landing page checklist because it’s consistently missing.
Google reads structured data (JSON-LD schema) to understand what a page is about at a semantic level. For a clinic landing page, the minimum viable schema:
{
"@type": "MedicalClinic",
"name": "Nama Klinik",
"address": { … },
"telephone": "+62...",
"openingHours": "Mo-Fr 09:00-17:00",
"aggregateRating": { … }
}This tells Google’s crawler the page is about a clinic, where it’s located, and how it’s rated — without requiring Google to infer this from the content alone. It improves local search relevance and can trigger rich results (star ratings) in search results.
#14 — Content That Matches Search Intent
Technical performance means nothing if the patient who clicks your ad or organic result arrives and doesn’t see what they expected. Keyword-to-content alignment is what keeps the patient on the page long enough for the technical performance to matter.
The landing page headline should directly reflect the search term or ad copy that brought the patient there. A patient who searched “klinik kulit veneers Surabaya” arriving at a generic “Selamat Datang” homepage will leave immediately — not because the page is slow, but because the content didn’t match the intent.
Landing pages for paid campaigns should be tightly matched to specific ad groups, not generically pointed at the homepage.
#15 — Contact Information Accessible Within Two Scrolls
Patients searching for clinics often have a specific question that a landing page won’t fully answer — they want to confirm operating hours, ask whether a specific treatment is available, or check whether a specific doctor is present on a given day.
If your contact information requires navigation to a separate page, a significant portion of patients will leave to find a competitor before they find your number.
NAP (Name, Address, Phone) information should appear in the footer of every landing page — and on mobile, a click-to-call phone number and WhatsApp button should be persistently accessible in a floating bottom bar.
#16 — Conversion Tracking That Actually Works
You cannot improve a landing page’s conversion rate without knowing the current rate. Basic conversion tracking on a clinic landing page:
- WhatsApp button click event (every click → tracked as conversion)
- Phone number click event on mobile
- Form submission confirmation event
- Time-on-page segmented by traffic source
Google Tag Manager with properly configured triggers handles all of this without page rebuild. The critical mistake to avoid: counting page views as conversions, or using form “visits” instead of form “submissions.” Both overreport conversions and corrupt optimization decisions.
#17 — A/B Testing Infrastructure
High performance without iteration is a ceiling. The landing pages that compound in conversion value are the ones that have a testing methodology.
For a clinic landing page, the two highest-impact things to A/B test:
- The hero headline — even small reframing can shift conversion rate by 15–30%
- The primary CTA label — “Booking via WhatsApp” vs “Konsultasi Gratis” vs “Cek Jadwal Dokter” have meaningfully different conversion rates in practice
Testing requires traffic. With under 2,000 monthly visitors, formal A/B testing produces statistically unreliable results. At that traffic level, qualitative user testing (watching 5 real patients navigate the page) produces more actionable insight.
The Checklist Summary
| # | Item | Impact Level |
|---|---|---|
| 1 | Static-first architecture | 🔴 Critical |
| 2 | Edge network hosting | 🔴 Critical |
| 3 | Hero image delivery | 🔴 Critical |
| 4 | Zero render-blocking JavaScript | 🔴 Critical |
| 5 | Self-hosted preloaded fonts | 🟠 High |
| 6 | Scoped CSS | 🟠 High |
| 7 | Deferred analytics | 🟠 High |
| 8 | Above-fold content priority | 🟠 High |
| 9 | Single above-fold CTA | 🟡 Medium-High |
| 10 | Mobile-first testing | 🟡 Medium-High |
| 11 | No unnecessary third-party scripts | 🟡 Medium |
| 12 | Explicit image dimensions | 🟡 Medium |
| 13 | Local SEO schema markup | 🟡 Medium |
| 14 | Search intent alignment | 🟡 Medium |
| 15 | Contact info within two scrolls | 🟡 Medium |
| 16 | Conversion tracking | 🟢 Foundation |
| 17 | A/B testing infrastructure | 🟢 Foundation |
The first four items are architectural. Every other optimization on this list competes for marginal gains on a bad foundation. If items 1–4 aren’t right, nothing else closes the gap.
For clinics currently on WordPress, items 1 and 2 require migration to a new stack — not an in-place fix. The investment is worth examining against three years of current performance penalties. Our SEM cost analysis shows what those performance penalties cost in advertising spend alone.
References
- Google Developers: Core Web Vitals — 2024
- Google Developers: Optimize LCP — 2024
- Google Research: The Need for Mobile Speed — 2024
- Cloudflare: Network Map — 2024
- Astro Documentation: Islands Architecture — 2024
- StatCounter: Mobile vs Desktop Indonesia 2024 — 2024
- HTTPArchive Web Almanac: Page Weight 2024 — 2024
Common Questions About High-Performance Landing Pages
What is the most important factor for a high-performance landing page?
Framework and hosting architecture. A landing page built on a static-first framework like Astro.js, served from an edge network like Cloudflare, will outperform a WordPress page with every optimization plugin installed — because the architectural constraints of WordPress impose unavoidable overhead that plugins cannot eliminate.
What Core Web Vitals score should a landing page target?
Target LCP under 1.5 seconds, CLS of 0.00–0.05, and Total Blocking Time under 100ms. These are stricter than Google's 'Good' thresholds (LCP ≤ 2.5s, CLS ≤ 0.1, TBT ≤ 200ms) because paid traffic and conversion-critical pages warrant a higher performance standard than informational pages.
How much does page speed affect conversion rate?
Google's own research shows that as page load time increases from 1 second to 3 seconds, the probability of mobile visitors bouncing increases by 32%. From 1 second to 5 seconds, it increases by 90%. For a landing page receiving paid traffic where every visitor has a cost, this bounce rate difference translates directly to wasted advertising spend.
Can I achieve a high-performance landing page using a page builder like Elementor?
Elementor and similar page builders generate significant JavaScript overhead that is structurally difficult to eliminate. You can improve WordPress/Elementor performance with optimization plugins and defer strategies, but Lighthouse scores above 75 are rare and scores above 90 are physically impossible because Elementor's rendering requires JavaScript execution before content appears.
What is LCP and why does it matter most for landing pages?
LCP (Largest Contentful Paint) measures how long it takes for the biggest visible element on the page — typically your hero image or headline — to render. It's Google's primary speed metric and the one that most directly correlates with whether a user stays or leaves. A landing page with an LCP above 2.5s is failing the majority of mobile visitors before they've read a word of your copy.