Mobile landing page optimization
Most of your traffic is on a phone. Most landing pages were designed on a desktop.
Most paid traffic is on a phone. Most landing pages were designed on a 27-inch monitor, signed off in a meeting where everyone had a laptop, and shipped without anyone holding the page in one hand at arm's length. The result is a page that looks fine in mockups and falls apart in the field. Here's how to design for the device most of your visitors actually use.
Design for the actual viewport
The mobile viewport is roughly 390 pixels wide and 600-700 pixels tall in usable space, after the address bar and nav chrome. Subtract another 50 pixels for the bottom safe area on devices with home indicators. That leaves you with less than half the visual real estate of a desktop fold, and it has to do the same five jobs.
The implication: every element in the hero needs to be tighter on mobile. Headlines that fit one line on desktop wrap to four on a phone. Subheads that breathe on a laptop suffocate on mobile. The fix isn't responsive scaling — it's writing copy short enough that it works on the smaller canvas without being cropped or shrunk to unreadable.
Tap targets and finger anatomy
The thumb is not a mouse. It's wider, less precise, and approaches the screen from below — which means the bottom half of the page is easier to reach than the top. The patterns:
- Minimum tap target: 44 pixels tall. Apple's HIG floor, also the practical minimum for missed taps to stop happening at scale.
- Spacing between targets: at least 8 pixels. Buttons stacked tight produce mis-taps and frustration.
- Primary CTA in the bottom third. A sticky "Start free trial" bar that floats above the fold on scroll converts better than a button buried at the top of a long page.
- Avoid hover-only interactions. Tooltips, dropdowns, and reveals that depend on hover don't exist on touch. If the information matters, show it.
Test on a real phone, held one-handed, with your thumb. If you have to stretch or use both hands to tap the CTA, the design is wrong.
Forms get the worst of mobile
Forms are where mobile pages bleed conversion the hardest. The fixes are mechanical:
- One column, full width. Two-column forms on mobile force horizontal squeeze and miss-taps.
- Inputs at least 48 pixels tall. Smaller inputs make virtual keyboards harder to dismiss and labels harder to read.
- Right input modes. Use type="email" for email fields, type="tel" for phone, inputmode="numeric" where appropriate. The keyboard that pops up should match the data being entered.
- No required date pickers if you don't need them. Mobile date pickers are universally awful. If a free-text field will do, use a free-text field.
- Inline validation. Tell the user the email is malformed before they hit submit and lose their place.
The deeper guide is in how to reduce form abandonment. The short version: every field, every required toggle, every dropdown costs you mobile conversions disproportionately.
Speed is the silent killer
A page that loads in 2 seconds on desktop wifi can take 8 seconds on a 4G phone in a parking lot. By second three, half the visitors have bounced. By second six, almost everyone is gone. Mobile performance isn't a nice-to-have — it's the floor you build everything else on.
The four levers that pay back hardest:
- Image weight. Hero images should be under 100 KB compressed. Use modern formats (WebP, AVIF) and serve right-sized variants.
- Web fonts. One font family, two weights max. Every additional font weight is a separate file blocking render.
- Third-party scripts. Each chat widget, analytics tag, and tracking pixel adds latency. Audit ruthlessly.
- JavaScript bundles. If your landing page ships a 500 KB JS bundle to render a static page, the bundle is the problem.
Test on real network conditions, not your office wifi. Chrome DevTools' "Slow 4G" throttle is a good baseline.
The hero on mobile
The desktop hero pattern — text on the left, image on the right — doesn't transfer. On mobile, hero elements stack vertically, and the order matters more than it does on desktop. The working order:
- Headline (large, bold, two lines max)
- Subhead (medium, two lines max)
- Primary CTA (full width or near it, with generous padding)
- One proof element (logo strip, star rating, named-customer caption)
- Hero visual (smaller than desktop equivalent, often cropped tighter)
That order keeps the CTA reachable without scrolling on most devices. Putting the hero image first eats the fold and pushes the action below where the visitor will see it. Above-the-fold priorities covers the underlying logic.
Testing on real devices
Browser dev-tools simulators miss too much: the address bar that hides on scroll, the rubber-band overscroll, the tap-and-hold preview. Get a real iPhone and a real Android, and walk through the page thumbs-only. Note every place you have to stretch, hesitate, or zoom.
Two specific tests worth running every release:
- One-handed reach test. Hold the phone in your dominant hand. Can you complete the primary action without using your other hand? If not, the CTA placement is wrong.
- Sun-in-screen test. Take the phone outside in bright sunlight. Are the CTA, body text, and form inputs still legible? Low-contrast designs that look elegant in the office disappear in the field.
The pages that work on mobile are designed with mobile constraints in mind from the start, not retrofitted. Landing page best practices and CTA design both take mobile as a baseline assumption, not an afterthought.