How to Test an Indian Food Delivery Website at Mobile Viewport Size

Use Chrome DevTools Device Mode to set a repeatable mobile viewport, check the layout at 320 CSS pixels and around your site’s breakpoints, then complete the menu-to-cart-to-checkout journey at each important width. Emulation is a fast way to find responsive issues, but it does not reproduce every mobile browser or real device behavior; verify critical flows on an actual phone before release when confidence matters. Chrome documents responsive dimensions, device presets, orientation, breakpoints, touch, network and CPU throttling in Device Mode.

1. Set up a repeatable viewport test

Open the food delivery site in Chrome and open DevTools with F12 or Ctrl+Shift+I on Windows/Linux, or Cmd+Option+I on macOS.
Enable the device toolbar using the device icon or Ctrl+Shift+M / Cmd+Shift+M.
Choose Responsive so you can enter exact width and height values. A practical starting set is 320 × 800, 375 × 812, and 425 × 900 CSS pixels. Add a tablet width such as 768 CSS pixels if navigation or content columns change there. These are test points, not claims about the most common Indian phone sizes.
Turn on Show media queries from the device toolbar’s options. Drag or enter widths just below and above each displayed breakpoint.
Reload at each size and record the viewport, browser, page, state and observed issue. Keep one baseline set so later changes can be compared consistently.

The WCAG 2.1 Reflow criterion uses a width equivalent to 320 CSS pixels for vertically scrolling content, with an exception for content whose meaning or use requires two-dimensional layout. Treat 320 CSS pixels as a focused reflow check: information and functionality should remain available without unnecessary horizontal scrolling.

2. Inspect the pages and states that affect an order

Do not stop at the landing page. Use the site’s actual available journey, noting that Indian food delivery sites do not all have the same interface or features.

Entry and location: homepage, location or postcode entry, permission prompts, unavailable-location and empty-result states.
Discovery: restaurant list, search, filters, cuisine or category navigation, long restaurant names and delivery information.
Menu: category navigation, item names and descriptions, prices, food images, dietary or availability notices, and long lists.
Item selection: item detail, quantity, required options or add-ons where present, validation and add-to-cart feedback.
Cart: quantity changes, removal, fees and totals, coupon entry if available, sticky checkout action, and empty-cart state.
Checkout: address, contact and delivery instructions, form errors, payment selection and confirmation up to the point your test environment permits.
Support: help, order issue, cancellation or complaint paths when the site provides them. FSSAI’s Food Safety Connect portal accepts consumer grievances about online aggregators and food-delivery platforms; this makes a platform’s own help path a useful journey to inspect, but does not establish a design requirement or compliance finding. See the portal FAQ.

At every step check whether navigation, restaurant and menu content, item options, prices, cart controls, notices and the primary next action fit, remain readable and can be reached. Watch for clipped text, overlapping controls, disappearing actions, unintended horizontal scrolling and content obscured by fixed headers, cookie notices, drawers or chat widgets.

3. Exercise the complete journey at each important width

Start at the same entry point and use the same location or test account data for each viewport.
Find a restaurant and open its menu. Confirm that search, category links and menu scrolling remain usable.
Open an item, select any required options, and add it to the cart. Verify that selection and validation feedback is visible.
Review the cart, change a quantity, remove an item, and continue. Check that totals and the checkout action remain visible and usable.
Proceed through delivery details and checkout as far as the test environment allows. Do not submit a real order unless the environment and authorization are intended for that purpose.
Repeat after rotating to landscape and with the on-screen keyboard open on location and checkout fields. Ensure the focused field, validation message and next action are not hidden by the keyboard or sticky UI.

A screenshot can show a layout, but it cannot prove that the journey works. Interact with the controls and check the resulting states, especially dialogs, drawers, sticky bars and validation errors.

4. Test breakpoint transitions, orientation and constrained conditions

Layouts often fail between the widths developers routinely inspect. Use the media-query bars to find where the site changes, then test immediately below and above each breakpoint. Look for a navigation item that wraps or vanishes, a card that becomes too narrow, an abrupt jump in text wrapping, or a control that moves under an overlay.

Switch between portrait and landscape, and enable touch in Device Mode where available. Use Network throttling and CPU throttling to inspect loading indicators, delayed menu content, image loading and layout shifts under slower conditions. Chrome’s emulation is relative to the desktop machine and is only an approximation, not a measurement of performance on a particular phone.

5. Use a small test matrix

Viewport or condition	What to verify
320 CSS px wide	Reflow, readable text, accessible controls, no unnecessary two-direction scrolling
375 CSS px wide	Compact layout, restaurant/menu cards, cart action and common form interactions
425 CSS px wide	Wider phone layout, spacing and layout changes
Just below/above each breakpoint	Transitions, wrapping, visibility and navigation access
Landscape	Short viewport height, dialogs, sticky elements and keyboard overlap
Throttled network/CPU	Loading and error states, delayed content, shifting layout and interaction feedback
Physical phone and browser	Real touch, keyboard, location behavior and browser-specific rendering

India’s Guidelines for Indian Government Websites and apps (GIGW) recommend responsive design and testing across devices. GIGW is guidance for government websites and apps; this article uses it as a relevant reference, not as a claim that it imposes the same requirements on private food-delivery businesses.

6. Automate repeatable viewport checks with Playwright

For regression coverage, Playwright can set explicit viewport dimensions and emulate device settings. The following small Node.js script opens a target page at three widths and checks for horizontal overflow. It is a layout smoke check; it does not test the real ordering flow or certify accessibility. Install Playwright with npm install playwright, install its Chromium browser with npx playwright install chromium, save this as viewport-check.mjs, then run node viewport-check.mjs https://example.com.

import { chromium } from 'playwright';

const target = process.argv[2];
if (!target) {
  throw new Error('Usage: node viewport-check.mjs https://example.com');
}

const browser = await chromium.launch({ headless: true });
try {
  for (const width of [320, 375, 425]) {
    const page = await browser.newPage({
      viewport: { width, height: 812 },
      isMobile: true,
      hasTouch: true,
    });
    const response = await page.goto(target, { waitUntil: 'domcontentloaded' });
    await page.locator('body').waitFor();
    const dimensions = await page.evaluate(() => ({
      viewport: document.documentElement.clientWidth,
      document: document.documentElement.scrollWidth,
      height: document.documentElement.scrollHeight,
    }));
    console.log({ width, status: response?.status(), ...dimensions,
      horizontalOverflow: dimensions.document > dimensions.viewport });
    await page.close();
  }
} finally {
  await browser.close();
}

Playwright’s emulation documentation explains device presets, viewport overrides, touch, locale, timezone and related settings. A complete automated order test needs stable selectors and a safe test environment; do not automate payment or order submission against a live account unintentionally.

7. Follow up on a real phone

Emulation does not run the page on a real mobile device and cannot reproduce every browser API, CSS support difference or device behavior. Check the critical path on an available physical phone and browser when release confidence matters. Prioritize the on-screen keyboard, touch targets, location behavior, scrolling inside dialogs, browser-specific rendering and any payment or authentication transition. You do not need to buy a phone to perform the DevTools checks; a real handset is an optional follow-up.

8. Troubleshoot common failures

Symptom	Likely cause	What to do
Desktop layout stays visible in mobile mode	The page may lack a suitable viewport declaration, or the responsive CSS may not activate as expected.	Inspect the document head and responsive styles; compare the computed viewport and media-query rules.
Horizontal scrolling at 320 px	A fixed-width element, oversized image, long unbroken text, or positioned child extends beyond the viewport.	Inspect elements wider than the viewport in DevTools; adjust the responsible layout or allow content to wrap. Preserve intentional two-dimensional content where its use requires it.
Cart or checkout action is covered	A sticky element, bottom sheet, chat widget, or keyboard overlaps it.	Repeat with the overlay and keyboard active; make sure the needed action can be reached and focus is not obscured.
Layout differs at an apparently identical width	Different zoom, device scale, orientation, browser state or responsive breakpoint.	Record CSS viewport dimensions, reset zoom, use the same orientation and reload the same state.
Menu appears blank during testing	Content may load asynchronously, require location/session state, or fail under throttling.	Check the Network and Console panels, wait for the relevant content, and repeat with the required test state.
DevTools looks right but the phone behaves differently	Emulation does not reproduce every real-device browser or hardware behavior.	Reproduce the flow on a physical phone and record its browser and operating system.
Automated script reports navigation failure	The target may be unreachable from the runner, redirect, require authentication, or block automation.	Check the returned status and browser error, use an authorized test environment, and handle authentication explicitly.

9. Performance, reliability and cost considerations

Keep the matrix focused: run a few meaningful widths and breakpoint edges on every change; reserve broader device and browser checks for release or high-risk flows.
Use throttling diagnostically: it reveals loading and interaction states but does not produce a reliable real-phone performance benchmark.
Make automation repeatable: keep viewport, browser engine, test data and starting state fixed. Flaky location, session or live inventory state can make ordering checks unreliable.
Avoid real transactions: use a sanctioned test environment and test payment path where available. A production checkout can create real orders or charges.
Plan time for physical-device checks: emulation is inexpensive and fast, while actual hardware coverage takes access to devices and browsers. Choose follow-up based on the risk of the flow.

Or skip the browser setup

For a representative page image at a mobile viewport, ScreenshotNeo returns an image or PDF from one request. It can set a viewport, capture a full page, and accept CSS or JavaScript options; see the ScreenshotNeo API documentation. A screenshot is useful for visual review, but it does not exercise the ordering journey.

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://example.com \
  -d viewport_width=375 \
  -d viewport_height=812 \
  -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={
        "access_key": "YOUR_API_KEY",
        "url": "https://example.com",
        "viewport_width": 375,
        "viewport_height": 812,
    },
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://example.com',
  viewport_width: '375',
  viewport_height: '812',
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);

ScreenshotNeo removes cookie banners, newsletter popups and chat widgets before capture; bot checks, blank pages and failed loads are never billed, and the response identifies the page verdict and billing status. Its MCP server lets AI agents use screenshot, page-info and PDF capture tools. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots. Create a free ScreenshotNeo account to try it.

FAQ

Is 320 CSS pixels the only mobile width I need?

No. It is a useful reflow threshold, but breakpoint edges and the widths relevant to your supported layout still need checks.

Does a passing emulation test mean the site works on iPhone and Android?

No. It is an approximation. Use physical devices and relevant browsers for critical paths.

Does a screenshot test prove checkout works?

No. It captures a visual state. Complete the interactions and state transitions separately.

Does GIGW apply to private food delivery websites?

The cited GIGW guidance is directed at Indian government websites and apps. This guide uses it as a reference rather than asserting a private-site legal obligation.