Mobile First Web Design Checklist: The South African Guide (2026)

A mobile first web design checklist is a structured audit tool that ensures every element of your website — layout, typography, navigation, images, forms, and performance — works correctly on smartphones before it is ever adapted for larger screens. For South African businesses, this approach is not a preference; it is a prerequisite. Professional web design in Johannesburg and across the country now starts from the smallest screen outward, because that is where your audience is.

According to Exploding Topics' mobile internet traffic analysis, 98.3% of South African internet users access the web via smartphones — and Africa leads every global region with 69.13% of internet usage on mobile. Globally, 64% of website traffic now comes from mobile devices. When Google completed its rollout of mobile-first indexing in 2024 — meaning it crawls and ranks the mobile version of your site — any business still building desktop-first was already behind. This checklist fixes that.

Use each section below as a working audit. Work through it before launch for a new build, or run it against an existing site that was never designed for mobile. Every item maps to a real technical requirement, a confirmed Google ranking signal, or an established mobile usability guideline — the distinction matters and is noted inline where it counts.

What Mobile-First Web Design Means for Your SA Business

Mobile-first web design means you design and build for the smallest screen first, then progressively enhance the experience for tablets and desktops — not the other way around. It is the opposite of building a desktop site and then compressing it to fit a phone. That compression approach produces sites where buttons are too small to tap, text requires pinching to read, and forms time out before users can finish them.

The practical consequence in South Africa is this: the mobile version of your site is the version most of your customers actually see. It is also the version Google's ranking systems evaluate. If your mobile experience is broken, slow, or stripped-down compared to your desktop site, your rankings will reflect the weaker version. Learn more about the foundations in our guide to mobile-first websites in South Africa.

Viewport, Layout, and Breakpoints

Viewport configuration is where mobile-first builds begin. Without a correctly set viewport, a mobile browser renders your page at desktop width and then scales it down — producing tiny, illegible content that users immediately leave.

1. Set the viewport meta tag. Every page must include <meta name="viewport" content="width=device-width, initial-scale=1"> in the <head>. Missing this single line causes your page to render at desktop scale on every smartphone.
2. Use relative layout units. Define widths, paddings, and font sizes in rem, em, %, or vw/vh — never in fixed pixels for core layout elements. Fixed pixel values cause overflow and horizontal scrolling on smaller screens.
3. Design from 360px width upward. As a working heuristic, 360px covers the majority of Android devices in the South African market — this matches common Chrome DevTools device presets (Samsung Galaxy S series). Use 375px (iPhone SE) as your iOS baseline. Any layout that breaks below 400px wide will fail for a significant share of your audience.
4. Eliminate horizontal scrolling. Set overflow-x: hidden on the body as a safety net, then identify and fix the element causing overflow — usually a wide image, a table, or a pre-formatted code block with no wrap.
5. Use CSS Grid or Flexbox for adaptive layouts. Float-based layouts from pre-2015 builds do not adapt reliably. Grid and Flexbox let columns reorder and stack without media query overrides at every breakpoint.
6. Test portrait and landscape orientations. Many SA users rotate their phones when filling in forms or reading longer content. Check that your layout does not collapse or overflow when the device is in landscape mode.

See our guide on responsive web design best practices for the full technical approach to breakpoint strategy.

Typography and Text Readability on Small Screens

Unreadable text is the fastest way to lose a mobile visitor. Google Search Console flags font sizes below 16px as a mobile usability error — and users who have to pinch-to-zoom simply leave.

1. Set body font size to 16px minimum. Google Search Console flags text that requires pinching or zooming to read as a mobile usability error — 16px is the threshold practitioners consistently use to avoid this flag, per Google's mobile-first indexing guidance. A 17–18px body size is more comfortable on high-density screens. Never go below 14px for any body copy.
2. Set line height to at least 1.5 for body text. Tight line spacing is readable on a large monitor but cramped and fatiguing on a 6-inch screen. Headings can use 1.2.
3. Limit paragraph width to a comfortable reading measure. Full-width paragraphs on a phone become walls of text. As a practical working rule, aim for a line length that fits roughly 10–15 words per line — typically achieved with a max-width constraint on your prose container — and let it expand naturally on larger screens.
4. Load web fonts with font-display: swap. Web fonts add meaningfully to page weight per family — web performance practitioners commonly estimate 50–150KB as a working heuristic — and cause a flash of invisible or unstyled text (FOIT/FOUT). The swap descriptor shows the system font immediately and replaces it when the custom font loads, preserving readability during download.
5. Maintain sufficient colour contrast. Low-contrast text is unreadable in bright South African sunlight. Use a free contrast checker tool to verify your text-to-background ratio meets the WCAG AA standard before publishing.

Touch Targets and Mobile Navigation

Buttons and links designed for a mouse cursor are too small for a fingertip. Google flags tap targets smaller than 48×48px as mobile usability errors in Search Console, and the Apple Human Interface Guidelines require a minimum of 44×44px for any interactive element.

1. Size all tap targets to at least 44×44px. This applies to buttons, menu items, checkboxes, radio buttons, and any linked element. If the visible element is smaller (for example, a social icon), add padding to expand the tap area without changing the visual design.
2. Space adjacent tap targets generously. Even correctly sized targets cause accidental taps when they are too close together. As a working rule, leave clear, visible space between any two tappable elements — footer links and inline navigation items are the most common offenders. If two targets feel crowded when you try to tap them with a thumb, they are too close.
3. Remove hover-dependent interactions. Drop-down menus that only open on hover do not work on touch screens. Rebuild them to open on tap, and test that the close action (tap outside, or an explicit close button) also works correctly.
4. Test your hamburger menu on both iOS and Android. A menu that opens and closes cleanly in Chrome DevTools emulation often fails on a real device because of scroll conflicts or fixed-position bugs. Test on hardware, not just a browser simulator.
5. Keep sticky headers compact. Fixed navigation bars that consume a large portion of the screen leave too little room for actual content. As a practical working rule, if your sticky header takes up more than roughly a thumb-and-a-half of vertical space on a 6-inch screen, it is too tall for mobile. If your header includes a logo, menu, and a CTA button in one sticky bar, reconsider the design on mobile.

Images, Video, and Media Weight

Images are typically the largest contributors to page weight and the primary cause of slow Largest Contentful Paint (LCP) scores on mobile. Getting images right has a larger effect on mobile performance than almost any other single optimisation.

1. Implement responsive images with the srcset attribute. Serve a 400px image to a mobile device and a 1200px image to a desktop — not the same large file to both. The srcset attribute and sizes declaration let browsers choose the right file automatically. Google's mobile-first indexing guidelines specifically call out responsive images as a requirement.
2. Convert images to WebP or AVIF format. These modern formats deliver significantly smaller file sizes compared to JPEG and PNG with no visible quality loss. Most South African-market hosting stacks (WordPress on WooCommerce, Shopify) support automatic WebP conversion via plugin or natively.
3. Lazy-load below-the-fold images. Add loading="lazy" to any <img> tag that does not appear in the first viewport. This defers image downloads until the user scrolls toward them, reducing initial page weight and improving LCP on content-heavy pages.
4. Prevent image overflow. Set max-width: 100%; height: auto; on all images. A single image without these rules can cause horizontal scrolling across your entire page — and a Google mobile usability error.
5. Handle video for South African data costs. Autoplay video on mobile consumes data without the user's consent and is a conversion killer for prepaid users. Use a thumbnail with a play button, or embed via YouTube/Vimeo so the video file is not served from your own domain. If video is essential to the experience, ensure it does not autoplay with sound.

Core Web Vitals and Mobile Performance

Google's Core Web Vitals are the three performance metrics used directly in its ranking systems. They are measured at the 75th percentile of real user sessions — meaning your slowest quartile of visitors determines your score, not your fastest. The thresholds below are the current "good" range as of 2026.

1. Fix your LCP element first. Identify it in PageSpeed Insights (usually the hero image or above-the-fold heading). Preload hero images using <link rel="preload">, ensure the image is compressed and in WebP format, and serve it from your hosting origin or a CDN with a South African edge node.
2. Eliminate render-blocking resources. JavaScript and CSS files that load before the page renders block LCP. Move non-critical scripts to deferred or async loading. Inline critical CSS for the above-the-fold view.
3. Add explicit width and height to all images. This reserves space in the layout while the image loads, eliminating the layout shifts that cause CLS failures. One image without dimensions can push your CLS score into the "poor" range.
4. Audit third-party scripts. Chat widgets, analytics, cookie consent tools, and social embeds all introduce INP delay and extra page weight. Load them asynchronously and defer non-essential scripts until after the main content is interactive.
5. Run PageSpeed Insights on mobile specifically. The mobile tab simulates a mid-range Android on a throttled connection — a realistic South African baseline. As a working heuristic, practitioners widely treat a mobile score of 70 or above as a minimum before launch — Google publishes no official pass/fail threshold. Note that median SA mobile speeds have reached 66.15 Mbps, but users in rural areas or on congested towers during peak hours still face 3G-equivalent conditions.
6. Track Core Web Vitals in Google Search Console. The Core Web Vitals report shows field data (real user measurements) across your pages. Use it monthly to catch regressions — a plugin update or a new image slider can push an LCP from 2.3 seconds to 3.8 seconds overnight.

See our detailed breakdown of how page speed affects conversions in South Africa for the business case behind these numbers.

Forms and Mobile Conversion Paths

A contact form that works on desktop but breaks on a phone is a revenue leak. Poorly built mobile forms are one of the top conversion killers identified when auditing South African business websites — and they are almost always fixable without a redesign.

1. Set minimum input field height to 48px. Fields smaller than this are difficult to tap accurately. Apply height via CSS — the default browser input height is often too small, especially on older Android browsers.
2. Trigger the correct keyboard type. Use type="email" for email inputs (triggers the @ keyboard), type="tel" for phone numbers (triggers the numeric pad), and type="number" for quantities. Missing the right input type forces users to switch keyboards manually — and many abandon instead.
3. Add autocomplete attributes. autocomplete="name", autocomplete="email", autocomplete="tel", and autocomplete="street-address" let smartphones prefill fields from saved data. Autocomplete-enabled forms convert significantly better on mobile because they reduce the typing burden.
4. Use visible labels, not placeholder-only text. Placeholder text disappears the moment a user taps the field. If the label is only a placeholder, users forget what they were filling in — particularly in multi-field forms. Use floating labels or static labels above the field.
5. Test payment flows on real South African payment gateways. If your site processes payments through PayFast, Peach Payments, or Ozow, complete a full test transaction on both iOS and Android using a real device on mobile data. Gateway redirect pages, 3D Secure screens, and return-to-site flows all have mobile-specific failure points that emulators miss.

Our UX guide for South African users covers the broader conversion decisions that sit behind individual form elements.

Content Parity and Google's Mobile-First Index

Since Google completed its mobile-first indexing rollout in 2024, the mobile version of your site is the version it reads, indexes, and ranks. If your mobile site has less content, fewer links, or stripped-out structured data compared to your desktop version, your rankings reflect the mobile version's shortfalls — not your desktop's strengths.

1. Audit every piece of desktop content for mobile presence. Common failure: accordions that collapse all content by default on mobile and never mark it up as visible to Googlebot. Check that your mobile HTML contains the same headings, body text, and images as your desktop version.
2. Implement structured data (Schema) in your mobile HTML. Google's mobile-first indexing documentation explicitly requires matching structured data on both versions. If your Schema is injected by a desktop-only plugin or JavaScript that does not render on mobile, Google will not see it.
3. Ensure Googlebot can access all resources on mobile. Check your robots.txt file to confirm that CSS, JavaScript, and image files are not blocked. Blocked resources prevent Google from rendering your page correctly — meaning it cannot assess your content, layout, or structured data.
4. Match internal links across both versions. If your desktop site links to a product page from the navigation and your mobile site hides that link behind a collapsed menu that requires JavaScript to open, that link may not be crawled. Include the same internal links in your mobile markup, even if the visual presentation differs.

Testing Your Mobile First Web Design Checklist Before Launch

Running through each checklist section is only useful if you verify results on real devices and real networks — not only in an emulator that renders everything at best-case performance.

1. Test on at least one iPhone and one Android device. Samsung Galaxy handsets are among the most widely used smartphones in the South African market. Test your priority user journey — homepage → key service or product page → contact or checkout — on a real Samsung and a real iPhone. Browser emulation in Chrome DevTools is a useful starting point, not a finish line.
2. Use Chrome DevTools Device Emulation for breakpoint coverage. Switch between device presets (Galaxy S20, iPhone 14, iPad) during development. Check all breakpoints where your layout changes — not just the smallest and largest sizes.
3. Run Google PageSpeed Insights against the mobile tab. Enter your URL at pagespeed.web.dev and focus on the Mobile results. The Opportunities section lists specific items to fix — ordered by estimated time savings on LCP.
4. Simulate slow 3G using Chrome DevTools Network Throttling. Open DevTools → Network → select "Slow 3G" from the throttling dropdown and reload your page. This simulates the experience for a user in a rural area or in a building with poor signal. If your site remains usable on slow 3G, it will work for every South African user.
5. Check Google Search Console Mobile Usability report. After launch, Search Console will flag pages with touch target issues, viewport problems, and content wider than the screen. Check this report within the first two weeks and after any significant site update.
6. Complete your highest-value user journey on mobile data, not Wi-Fi. Switch your test device to mobile data (Vodacom or MTN) and complete the full conversion path — landing page, exploration, form submission or payment. This surfaces form issues, redirect loops, and payment gateway failures that only appear under real network conditions.

Why South African Businesses Choose Growth Pulse Media

Every item on this mobile first web design checklist reflects how we build by default at Growth Pulse Media — not because of a policy, but because Dirk built and scaled an ecommerce business in South Africa before founding GPM. He paid for the mobile conversion failures that came from desktop-first builds, and those losses shaped every site the team produces today.

Our web design service starts with mobile wireframes. Every layout decision, every typography choice, every image optimisation pass happens on the mobile frame first. Desktop enhancements come after. We build on WordPress and WooCommerce with SA payment gateways — PayFast, Peach Payments, Ozow — tested on real Vodacom and MTN connections before handover, not after.

We keep our client load deliberately limited. Every site we build gets senior attention throughout the project — from the mobile audit on day one to the Core Web Vitals sign-off on launch day. No juniors shipping your build while the senior handles the next sale.

Who This Mobile-First Checklist Is NOT For

This mobile first web design checklist is designed for businesses actively building, rebuilding, or auditing a website. The following situations are exceptions where this checklist is not the right starting point.

Frequently Asked Questions

What is a mobile-first web design approach?

A mobile-first web design approach means designing and coding for the smallest screen first — typically a smartphone — then progressively adding layout complexity for larger screens. It is the opposite of building a desktop site and shrinking it for mobile. As confirmed in Google's Search Central documentation, the mobile version of a site is what determines indexing and rankings — so mobile-first design directly affects how your site performs in search, not just how it looks on a phone.

How does mobile-first design affect my Google rankings?

Google has used mobile-first indexing for all websites since 2024, meaning it crawls and indexes the mobile version of your pages. If your mobile site has thinner content, missing structured data, or blocked resources compared to your desktop version, your rankings will reflect those gaps. Core Web Vitals — LCP, INP, and CLS — are measured on mobile sessions and used directly in Google's ranking systems.

What Core Web Vitals scores does my site need?

To pass Google's Core Web Vitals good threshold, your site needs an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less, and a CLS of 0.1 or less — all measured at the 75th percentile of real user sessions. All three metrics must pass simultaneously for a page to earn a good Core Web Vitals assessment. You can check your current scores in PageSpeed Insights or in the Core Web Vitals report inside Google Search Console.

How do I check if my website passes mobile usability tests?

The fastest starting points are Google's PageSpeed Insights (pagespeed.web.dev) and the Mobile Usability report inside Google Search Console. PageSpeed Insights tests a single URL on a simulated mobile connection and lists specific issues with their impact. Search Console shows aggregate mobile usability errors across your entire site — including tap target failures, viewport problems, and content that extends beyond the screen width.

Does mobile-first web design cost more to build?

No — a mobile-first build costs the same as, or less than, a desktop-first build that requires a subsequent mobile rework. The cost difference appears when a site is built desktop-first and then retrofitted for mobile — you pay twice to solve the same problem. Building mobile-first from the start reduces rework, produces cleaner code, and delivers a site that performs correctly on the devices where most South African users will encounter it.

Dirk van Greuning Founder, Growth Pulse Media

Founder of Growth Pulse Media and a specialist in South African search dominance. Dirk translates his experience in scaling South African businesses into high-velocity digital strategies for B2B and retail leaders. He writes about SEO, lead generation, and paid media from an operator's perspective — prioritising pipeline value over impressions.

Connect on LinkedIn