A landing page is one page with one job, and most of what gets written about designing one cannot be checked: a compelling headline, a bold button, social proof. This guide stays on the other side of that line, covering only what carries a number or a rule written down in official documentation: the performance thresholds that decide whether a visitor sees your page at all, the field rules in the HTML documentation and the WCAG criteria, what changes in the layout once the language is Arabic, and how much traffic an A/B test needs before its result means anything.
One note about numbers first. Marketing articles about landing pages circulate specific percentages for what removing a form field does, and deadlines counted in seconds for capturing attention, with no published primary study behind them. You will not find one of them here. Where no primary source exists, this guide explains the mechanism instead of quoting a figure.
Performance: the verdict lands before the headline is read
Google publishes numeric thresholds for three metrics that measure the visitor's real experience, each with a defined "good" boundary. Each metric is assessed separately for mobile and desktop, and at the 75th percentile rather than the average. Put differently, the slowest quarter of your traffic decides your result.
| Metric | What it captures | Good | Source |
|---|---|---|---|
| LCP | When the largest element in the first screen appears | 2.5 seconds or less | web.dev/lcp |
| INP | How long the page takes to answer its worst interaction during the visit | 200 ms or less (poor above 500) | web.dev/inp |
| CLS | How much elements move after they appear | 0.1 or less (poor above 0.25) | web.dev/cls |
The speed work itself is covered in our website speed optimization guide. What belongs here is knowing which part of a landing page moves which metric.
Which element decides your LCP
The documentation limits eligible elements to a short list: img elements, image elements inside an svg, video elements (the poster image time counts), any element carrying a background image loaded through url(), and block-level elements containing text. A CSS gradient is not on that list, so the gradient behind your headline is never measured, while the cover photo your designer set as a url() background is.
On a typical landing page the first candidate is the hero image or the video at the top. One detail is worth keeping in mind when you decide what to ship: the size recorded for an element is only the part visible inside the viewport, and for an image displayed smaller than its natural size the recorded size is the smaller of the two. Uploading a 3,000-pixel-wide image to be displayed at 800 buys you nothing in the measurement and buys you extra bytes that delay it.
Which interactions count towards INP, and which do not
INP watches three kinds of input only: mouse clicks, taps on a touchscreen, and key presses. Scrolling, hovering and zooming sit entirely outside the calculation.
The practical consequence is that scroll effects and hero animations never surface in INP however heavy they are, though they may surface in LCP. What does surface is everything that happens on a click or a keystroke: validation re-running on every character typed into the phone field, or a governorate dropdown that rebuilds its options each time it opens. The value recorded for the page is the worst interaction of the entire visit, with one interaction in every 50 discarded as an outlier, so a single slow moment inside a six-field form is enough to become the page's number.
The promo bar: when it costs you CLS and when it does not
A layout shift is counted when an existing visible element changes its start position between two frames. The documentation states plainly that a new element appearing in the page, or an existing element growing, does not enter the calculation as long as nothing visible is pushed out of place.
That separates two cases which look identical. A promo bar injected at the top a second after load, pushing the hero down, is counted in full; the same bar rendered over the content in a fixed position is not counted at all. The size of the cost varies too: the score is the impact fraction multiplied by the distance fraction, so shifting a full-width block near the top of the page is far more expensive than nudging a small element near the bottom. Shifts are grouped into a window that runs up to five seconds, with gaps of less than one second between them.
The form: every field is paid for on the visitor's side
Every field you add asks the visitor to read, decide and type, and then risks a rejected submission. That is the mechanism, and it needs no borrowed statistic. What can be documented is what makes the field itself cheaper for someone filling it with one thumb on a phone.
| Rule | What it does | Reference |
|---|---|---|
A valid autocomplete value such as name, tel, email, street-address | The browser offers stored data and fills the field in one tap | MDN and SC 1.3.5 at level AA |
autocomplete="one-time-code" on a verification field | Picks up the incoming code instead of making the user memorise it | MDN |
inputmode such as numeric or tel | Switches the on-screen keyboard, and enforces no validation at all | MDN |
type="tel" for a phone number | Shows a phone keypad on mobile, with no automatic format check | MDN |
A label tied to the field | Screen readers announce it, and the tap area grows | SC 3.3.2 at level A |
| A text error message that names the field and suggests the fix | Tells the visitor what to do instead of "an error occurred" | SC 3.3.1 and SC 3.3.3 |
Three rows in that table are missed more often than the rest.
Start with autocomplete, which is not a nicety. MDN states that valid tokens satisfy WCAG 2.2 Success Criterion 1.3.5, and that the made-up value a developer writes to defeat autofill fails the criterion, because the field's purpose is no longer programmatically determinable. Switching autofill off across an entire form for security reasons takes away the shortest route to submission from a user who depends on it.
Next, type="tel" does not validate the number, and the documentation explains why: phone number formats vary widely around the world. A strict pattern written for an Egyptian number becomes a trap for a Saudi visitor typing a different shape, or for anyone who starts with an international prefix. Accept both and normalise the number on the server.
Finally, type="number" is documented as inappropriate for values that merely consist of digits without being numbers, such as postal codes and card numbers. National ID and phone numbers belong to that same family: use type="tel", or a text field with inputmode.
As for "how many fields should I ask for", there is a practical answer that needs no statistic: ask for what you will use within 48 hours. A "company size" field that changes nothing about how you follow up is a cost carried by the visitor alone. The rest of the standards covering forms, errors and keyboard navigation are in our web accessibility guide.
Arabic and reading direction: what actually breaks
The starting point is a single line: <html dir="rtl" lang="ar">. Direction is semantic information set on the document element rather than in the stylesheet, and on that basis the line starts on the right, which places the primary button at the start of the reading order automatically, provided the layout is written with logical CSS properties (margin-inline-start, inset-inline-end and their siblings) instead of hard-coded left and right.
After that come the details that show up in the Arabic version and never showed up in the English design it was built from:
- Letter spacing. MDN warns that
letter-spacingapplied to Arabic script separates letters that are meant to stay joined, leaving the text looking broken. The tracked-out headline that looks elegant in Latin damages the Arabic word. - Height. W3C's internationalization documentation lists Arabic among the scripts that need more height than Latin text, both per line and between lines. A button pinned to a fixed height, and a card measured against three lines of English, are the first things to clip.
- Short strings. The same document records that the expansion ratio in translation rises as the source string gets shorter, and that short strings are the ones squeezed into the tightest spaces: beside a form field, inside a graphic, in a set of width-restricted tabs. Your button label is the shortest text on the page and the most exposed. The document adds that Arabic resists abbreviation, because words are built from compact roots with prefixes, suffixes and internal changes, so the fix is room to expand rather than a shorter sentence.
Snaabble provides a tailored technical assessment to define the right stack & exact budget.
That leaves numbers and dates. The default numbering system in Intl follows the visitor's locale, not your page, and you can check it in one line: new Intl.NumberFormat('ar-EG').format(1500.5) returns ١٬٥٠٠٫٥, while the same call with ar-AE returns 1,500.5. Your offer price and its deadline can therefore render in different digit shapes for an Egyptian visitor and an Emirati one on the same page, and digit shapes get mixed inside one page without anyone writing it that way. Pick one form and set it explicitly everywhere you print a number or a date.
The WhatsApp button: when it beats a form, and how you know it works
In our markets a great many deals start with a message rather than a form. The link format is documented by WhatsApp: https://wa.me/<number> with the full number in international format, no leading zeros, brackets or dashes, plus an optional ?text= carrying a URL-encoded message that appears ready in the chat box.
That pre-filled message is the most useful detail of the whole button, because the conversation moves off your site and arrives with no context attached. Make it carry its own origin, something like "I'd like the October maintenance offer", and you will know from the first line which page sent this customer.
What you can measure on your side is the click itself. The link points to another domain, so GA4's enhanced measurement records it as an outbound click along with the link's domain and URL, with no extra code; turning it into a key event is covered in our GA4 measurement guide.
One constraint applies specifically to an Arabic interface: the branded "Chat on WhatsApp" button is available in English only as of September 2026, and WhatsApp's guidance asks you to use it as is without modification. So you have two explicit options: the official button with its English label, or your own button with Arabic text, in which case its contrast, target size and accessible name become your responsibility.
The choice between form and chat comes down to one question: what do you need before you can reply? If your answer depends on structured data (governorate, budget, installation date, number of branches), a form collects it once and records the visitor's consent to be contacted. If the visitor's next step is a question rather than data, the form adds friction for nothing. The most useful pages carry both and measure both, then drop the weaker one once they know.
Measurement: four events that show where the page breaks
| Event | What it reveals |
|---|---|
form_start against form_submit | The gap between them is everyone who started typing and walked away. A wide gap points at the fields, not the headline |
scroll, recorded at 90% depth | Whether visitors reach the bottom button at all, or your page outlasts their patience |
Outbound click (link_domain) | WhatsApp taps and other external links |
generate_lead | The completed request, the event your conversions are built on |
The first three arrive from GA4 enhanced measurement without extra code once their toggles are on; the fourth is sent explicitly. And when you read the result, the number that matters is not how many forms arrived but what a qualified lead costs; the line items that make that figure look smaller than it is are in our customer acquisition cost guide.
A/B testing: do the arithmetic before choosing a tool
Start with a correction that is still needed: Google Optimize has not been available since 30 September 2023, every experiment still running that day ended with it, and Google now points to integrations with third-party tools such as AB Tasty, Optimizely and VWO. Plenty of guides still recommend it.
The question that comes before the tool is whether you have the traffic. The NIST/SEMATECH statistics handbook publishes the accepted formula for the minimum sample size when testing a proportion, and your page's numbers fall out of it. Applied to a page converting at 2% today, at a 5% significance level and 90% power, detecting a rise to 3% needs roughly 2,500 visits, detecting a rise to 2.5% needs roughly 9,200, and a rise to 2.4% needs about 14,000.
Those are floors for comparing a sample against a known rate; a test comparing two live variants needs more than that per variant. The rule behind the jumps is that the sample size scales with the inverse square of the difference you want to detect, so halving the difference roughly quadruples the traffic you need.
Apply that to your own page: at 400 visits a month, a test able to detect half a percentage point needs around two years of continuous running. In that situation do not test. Fix what the documentation already shows to be broken: a heavy hero image, a field rejecting a valid number, a form without labels. And if you want to compare one period against another, read the conditions in our conversion rate optimization guide, because seasonality alone can manufacture an improvement that never happened.
What Google measures about your page inside your ads
If your page receives search ads, there is already a rating for it in your account. Quality Score is calculated from three components, one of which is landing page experience, and each component is compared against other advertisers who appeared for the same search over the last 90 days. Google states plainly that the score is a diagnostic tool and does not enter the ad auction, so it points at where the problem is rather than acting as a lever.
Google's glossary lists what this component is made of: how useful and relevant the information on the page is to the person who clicked, how easily they can navigate it, how many links it carries, and what the ad led them to expect. Note that ease of navigation sits next to the number of links, which qualifies a popular piece of advice: keeping the page focused on one action is one thing, and stripping out every link down to the privacy policy and contact details is another.
One policy point tends to be forgotten when external page builders are involved: Google requires the landing page and the display URL to share the same domain.
Where to start
- Measure the page on mobile and record the three metrics before you change anything.
- Identify the actual LCP element instead of guessing it, and treat that one alone.
- Review the form line by line:
autocomplete, field type, label, and the wording of the error message. - Open the page at phone width and look at the button and the headline: is either clipped, or are its letters coming apart?
- Turn on the four events, and wait two weeks before deciding anything.
Frequently asked questions
Should I remove the top navigation from a landing page?
Remove what leads the visitor away from the goal, and keep what they need in order to trust you: a direct way to reach you, with the terms of the offer and the privacy policy published where they can find them. Google's documentation names ease of navigation and the number of links together as factors in landing page experience, so what you want is a focused page, not an isolated one.
What is a good conversion rate for a landing page?
There is no single number worth comparing against, because published averages mix page types, channels and markets. Compare your page with itself over time, split by device and traffic source.
Is a browser testing tool enough to judge performance?
Lab testing diagnoses the cause and lets you try a fix before shipping it, but it usually measures a page load with no interaction, and INP has no value without real clicks and key presses. Judge the page by measurements from its own visitors.
One landing page per ad, or one page for all campaigns?
The closer the ad's promise is to the page's content, the fewer visitors leave immediately, and what the visitor expected from the ad they clicked is named explicitly among Google's landing page experience factors. Start with one page per offer, not one per ad.
Sources
- Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS), web.dev by Google.
- The autocomplete HTML attribute, inputmode, input type="tel", input type="number" and letter-spacing, MDN Web Docs.
- Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation of 12 December 2024.
- Text size in translation, W3C Internationalization.
- WhatsApp's guide to chat links, WhatsApp Help Center.
- Enhanced measurement events and recommended events, Google Analytics Help.
- Google Optimize sunset, Google Help.
- About Quality Score and Landing page, Google Ads Help.
- Sample sizes required, NIST/SEMATECH e-Handbook of Statistical Methods.
All pages above were reviewed on 22 September 2026.
Building a landing page for a campaign, or rebuilding one that brings back nothing? Describe the project to the Snaabble team through our UI/UX design service, and a reply reaches you in under 24 hours: a proposed scope of work, plus a delivery window with an estimated cost. Nothing is charged for it, and nothing is committed.
