Landing Pages

Mobile landing page optimization

Most of your traffic is on a phone. Most landing pages were designed on a desktop.

7 min read Updated April 29, 2026

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:

  1. One column, full width. Two-column forms on mobile force horizontal squeeze and miss-taps.
  2. Inputs at least 48 pixels tall. Smaller inputs make virtual keyboards harder to dismiss and labels harder to read.
  3. 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.
  4. 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.
  5. 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:

  1. Headline (large, bold, two lines max)
  2. Subhead (medium, two lines max)
  3. Primary CTA (full width or near it, with generous padding)
  4. One proof element (logo strip, star rating, named-customer caption)
  5. 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.

Mobile checklist: 44-pixel tap targets, 48-pixel form inputs, single-column layouts, right input modes, sticky primary CTA, hero under 100 KB, web fonts to two weights, real-device testing, sun-in-screen legibility, and a one-handed reach pass on every change.

Frequently asked

What's the single biggest mobile landing page mistake?
Designing on desktop and shipping responsive without testing on a real phone. The mobile fold is half the size of desktop, the inputs need to be bigger, and the CTA has to sit where the thumb can actually reach it. Most "responsive" pages get all three wrong.
Should I build a separate mobile page or rely on responsive design?
Responsive is fine for most sites if it's designed mobile-first. Separate mobile URLs add maintenance overhead and SEO complications without solving any problem responsive can't. The choice that matters is whether mobile constraints drove the design — not which architecture you used.
How fast does a mobile landing page need to load?
Largest Contentful Paint under 2.5 seconds on 4G is the baseline most teams should target. Google's Core Web Vitals thresholds are a useful proxy. Above 4 seconds, bounce rate climbs sharply and ad spend gets less efficient.
Is a sticky CTA bar always a good idea on mobile?
On longer pages, almost always. On short pages with the primary CTA already visible, it's redundant and steals real estate. Use it when the visitor would otherwise have to scroll back to act.
How do I handle dropdowns and select menus on mobile?
Use them sparingly. Native select menus work fine for short lists; for longer lists, autocomplete inputs are usually better. Avoid custom dropdown components that don't match native behavior — they confuse users and break accessibility.