Skip to content
Mera News

Publisher guide, chapter 2

Page structure on mobile and desktop

Last reviewed November 2026

A reader decides quickly whether a news page is worth staying on. The headline should appear fast, the page should hold still, and every tap should get a response. Google also indexes the mobile version of your pages, so the phone layout is the version that counts for Search as well.

The numbers to aim for

Google's Core Web Vitals give you three measures and a clear target for each.

MetricMeasuresGood
Largest Contentful Paint (LCP)Loading2.5 seconds or less
Interaction to Next Paint (INP)Response to input200 milliseconds or less
Cumulative Layout Shift (CLS)Visual stability0.1 or less

Measure the 75th percentile of page loads, with mobile and desktop counted separately. A page passes when all three metrics meet the target at that percentile.

Use field data from real visits: the Core Web Vitals report in Search Console, PageSpeed Insights or the Chrome User Experience Report. Lighthouse is useful in the lab, but it can't measure INP and reports Total Blocking Time in its place.

Google says there is no single page experience signal. It does say Core Web Vitals are used by its ranking systems, and that other page experience aspects don't directly help a site rank, though they can still make it better to use.

One page for both screens

Google recommends responsive design as the easiest pattern to implement and maintain. The same HTML serves every device, so content and metadata match without extra work. If you run separate mobile pages, keep these identical to desktop:

  • Primary content
  • Headings
  • Structured data
  • Robots meta tags (a stray noindex can keep a mobile page out of the index)

Start with the viewport tag, then check that the page reflows at 320 CSS pixels wide without sideways scrolling.

<meta name="viewport" content="width=device-width, initial-scale=1">

On mobile

  • Put the headline, byline and visible date first, then the lead image or opening paragraph.
  • Keep the article text in the HTML. A "continue reading" button that fetches the rest on tap may hide that text from Google, which doesn't click, swipe or type.
  • Make touch targets at least 24 by 24 CSS pixels, the WCAG 2.2 AA minimum. For menus and close buttons, aim for 44 by 44, the AAA level.
  • Keep a sticky header short, and set scroll-padding-top to its height so a focused link is never hidden behind it.

On desktop

  • Keep body text to 80 characters a line or fewer, or 40 for Chinese, Japanese and Korean. This is the WCAG AAA guideline, and it helps every reader.
  • Set line spacing of at least 1.5 within paragraphs.
  • Keep supporting content in a sidebar that doesn't move the article when it loads.

Faster loading

The largest element on a news page is often the lead image. Treat it as the most important request on the page.

<img
  src="/images/lead-1200.jpg"
  srcset="/images/lead-800.jpg 800w, /images/lead-1200.jpg 1200w"
  sizes="(min-width: 768px) 720px, 100vw"
  width="1200"
  height="675"
  alt="Describe what the photo shows"
  fetchpriority="high">
  • Never lazy-load the LCP image.
  • Put it in the initial HTML, so the browser finds it before any script runs.
  • Use fetchpriority="high" on one or two images at most. More than that stops helping.
  • Use loading="lazy" only for images and iframes outside the first viewport.
  • Cut redirects, and keep the page cacheable. Unique URL parameters can send requests back to your origin server instead of the CDN.

A page that holds still

  • Set width and height on every image and video, and keep height: auto in the CSS.
  • Use the same aspect ratio for every image in a srcset.
  • Reserve space for ads, embeds and iframes before they load. The ads chapter covers slot sizes.
  • Overlay cookie notices and sign-up prompts, or reserve room for them, so they don't push the article down.
  • Use font-display: optional, or a fallback font adjusted to match your web font's metrics.
  • Animate with transform. Animating top or left causes layout shifts.

Quick responses

Total interaction time has three parts: the wait before your code runs, your code, and the paint that follows. Any task longer than 50 milliseconds is a long task.

  • Do as little as possible in event callbacks. Update the screen first, then defer the rest.
  • Break long work up with scheduler.yield(), and fall back to setTimeout in browsers that don't support it.
  • Keep the DOM small. Long article lists can use content-visibility to render off-screen items later.
  • Remember that each iframe has its own main thread, so check which frame a slow interaction came from.

Long pages and infinite scroll

If a section page scrolls without end, give each chunk its own permanent URL with an absolute page number such as ?page=12, and link those pages in sequence. Update the address with the History API as the reader moves. Google doesn't scroll or click, so lazy-loaded content must load when it enters the viewport, with no action needed.

Checklist

  • Check LCP, INP and CLS in Search Console, for mobile and desktop separately.
  • Open your busiest article template on a phone and confirm the headline and date are on the first screen.
  • Confirm the full article text is in the HTML the server sends.
  • Compare mobile and desktop for matching content, headings, structured data and robots tags.
  • Remove loading="lazy" from the lead image and add fetchpriority="high".
  • Add width and height to every image and video.
  • Reserve space for every ad, embed and banner.
  • Set scroll-padding-top to match your sticky header.
  • Test the page at 320 CSS pixels wide.
  • Give every chunk of an infinite scroll page its own URL.

Sources