At 320px, Your Landing Page Either Works or It Fails
At 320 pixels wide, your landing page faces its single toughest test. That viewport mirrors iPhone SE generations one through three and many entry-level Android handsets — devices responsible for millions of ad impressions every month. If your headline wraps into three awkward lines, your CTA button drifts off the right edge, or your form fields require pinching to tap, you are losing conversions before a visitor scrolls past the fold.
QAing at 320px is not a niche edge case; it is the most reliable stress test for mobile landing page viability. This guide gives you a repeatable, Playwright-powered audit workflow you can run on every landing page before it goes live. You will learn what to inspect, what to measure, and how to fix the most common 320px failure modes that silently erode conversion rates.
Why 320px Is the Gold Standard for Landing Page QA
The device reality behind the pixel count
The 320px CSS width corresponds to a physical viewport of roughly 640x1136 pixels on iPhone SE devices. According to Apple's 2026 device share data, these handsets still account for a measurable slice of global traffic, particularly in price-sensitive markets across South Asia, Latin America, and Africa. When you add Android devices with similar viewports — many running budget chipsets with slower render times — the combined audience is too large to ignore.
What breaks first at ultra-narrow widths
Landing pages are dense by design: hero images, value propositions, forms, and trust signals all compete for limited horizontal real estate. At 320px, the following issues surface first:
- Horizontal overflow from fixed-width containers, oversized images, or negative margins that push content past the viewport edge.
- CTA invisibility when buttons are pushed below the fold or clipped by a parent element with overflow: hidden.
- Typography collapse where body text drops below 14px or headlines wrap into unreadable fragments.
- Form abandonment caused by input fields too narrow for comfortable typing, triggering keyboard resize events that reposition the page unpredictably.
Setting Up Your 320px QA Environment
Choose the right viewport configuration
Do not rely solely on Chrome DevTools device emulation. Software rendering can mask real layout issues caused by touch events, dynamic keyboard behavior, and GPU compositing. Instead, use a two-layer approach:
- Browser emulation for rapid iteration — set the viewport to 320x844 (the logical height of an iPhone SE with a modern OS) and scan for visual defects.
- Physical device testing on at least one real iPhone SE or equivalent Android handset to validate touch targets, font rendering, and keyboard interactions.
Automate with a Playwright audit script
Playwright gives you deterministic control over viewport, network conditions, and screenshot capture. Below is a minimal script that sets a 320px viewport, captures a full-page screenshot, and logs any horizontal overflow:
const { chromium } = require('playwright'); (async () => { const browser = await chromium.launch(); const page = await browser.newPage({ viewport: { width: 320, height: 844 } }); await page.goto('https://your-landing-page.com', { waitUntil: 'networkidle' }); const overflow = await page.evaluate(() => { return document.documentElement.scrollWidth > window.innerWidth; }); console.log('Horizontal overflow detected:', overflow); await page.screenshot({ path: '320px-audit.png', fullPage: true }); await browser.close(); })();Run this script as part of your CI pipeline so every deployed landing page is automatically checked at 320px before reaching production.
The 320px Landing Page Audit Checklist
Use this checklist during every manual and automated QA pass. Each item targets a specific conversion risk that compounds at narrow widths:
- Hero section legibility — Confirm the headline is fully visible above the fold without vertical scrolling. At 320px, a single-line H1 should fit within approximately 480 vertical pixels including the browser chrome.
- CTA button placement — The primary action must appear within the first scroll. Verify the button width is at least 44px tall (Apple's Human Interface Guideline minimum for touch targets) and does not require horizontal scrolling to reach.
- Image asset sizing — Check that hero images and background visuals use max-width: 100% and serve appropriately compressed files under 200KB for 3G network conditions.
- Form field spacing — Input fields must span the full available width with at least 16px padding on each side. Test that the on-screen keyboard does not obscure the submit button.
- Trust element visibility — Security badges, star ratings, and testimonial snippets should remain visible without hiding behind sticky headers or cookie banners.
- Font rendering — Body text must render at no smaller than 16px on iOS Safari and 14px on Chrome Android. Headlines should remain bold and high-contrast against their background.
A tool like NetSixtySix Mobile QA can execute this checklist across multiple viewports simultaneously, but the manual pass remains essential for judging subjective quality such as whitespace balance and visual hierarchy.
The Three Conversion Blockers You Will Find at 320px
1. Off-canvas CTAs caused by fixed-width elements
The most frequent offender is a hero button or video embed with a hard pixel width that exceeds 320px. Inspect every element's computed width using the browser's layout panel. If any element's getBoundingClientRect().width exceeds the viewport width, it will create horizontal scroll — and users on mobile rarely scroll horizontally, so they miss your call to action entirely.
2. Sticky headers consuming viewport real estate
A sticky nav bar that is 60px tall on desktop may still be 60px at 320px, consuming nearly 7% of the visible screen. On iPhone SE devices, this leaves even less room for your value proposition. Test with the header both visible and hidden (via scroll-triggered collapse) to measure the impact on above-the-fold content.
3. Keyboard-triggered layout shifts
When a user taps an input field on a 320px viewport, the virtual keyboard typically resizes the visual viewport to roughly 320x480px. If your page uses position: fixed elements, they may jump or overlap during this transition. Use Playwright's page.keyboard API to simulate input focus events and capture screenshots at each stage.
Building a Repeatable 320px QA Workflow
Integrate the audit into your deployment process so no landing page ships unverified at this critical width:
- Pre-commit hook — Run the Playwright overflow script against your staging URL before each pull request. Fail the build if horizontal overflow is detected.
- Visual regression — Store the 320px full-page screenshot as a baseline. On each deploy, compare the new screenshot using pixel-diff tools and flag changes exceeding a 2% threshold.
- Weekly device lab session — Spend 30 minutes on a real iPhone SE testing one high-traffic landing page. Document any issues in a shared tracker tagged with viewport width.
- Conversion monitoring — Funnel analytics by viewport width. If the 320px cohort shows a statistically significant drop in CTA click-through rate, prioritize a layout review immediately.
Treating 320px as a first-class QA viewport — not an afterthought — ensures your landing pages serve every visitor effectively, regardless of device. Start with the checklist, automate what you can, and reserve human judgment for the subjective decisions that no script can make.