Mobile-First performance: Optimization strategies for the 2026 mobile index

Google indexes and ranks the mobile version of a page, fetched by its smartphone crawler. A WordPress site that only shrinks a desktop layout to phone width can look fine on a quick check and still send a heavy, slow page to the device that decides how it is indexed. Mobile-first performance means building each page for a phone on a constrained network first, then adding weight for larger screens only where it earns its place.

Learn more about WordPress speed optimization at WPPoland.

This guide covers what Google’s mobile-first indexing requires, the Core Web Vitals thresholds for mobile, how mobile speed is measured in the lab and in the field, and the WordPress features and code patterns that improve LCP, INP, CLS and back navigation on phones.

#Mobile-first indexing timeline from 2016 to 2024

Google’s mobile-first indexing best practices define the term in one line: Google uses the mobile version of a site’s content, crawled with the smartphone agent, for indexing and ranking. Getting the whole web there took eight years.

In the October 2023 post, John Mueller and Nir Kalush described the small group of sites still left on the desktop crawler. The errors were pages that show errors to every mobile user, a mobile version blocked in robots.txt while the desktop version stays crawlable, and mobile pages that all redirect to the homepage. In June 2024 Mueller wrote that after 5 July 2024, a site whose content cannot be reached with a mobile device at all would no longer be indexable. Googlebot Desktop still appears in server logs for some features, such as product listings and Google for Jobs, so a desktop user agent in your access log does not mean your site was skipped.

The “2026 mobile index” is therefore not a new index. The switch happened in 2023 and 2024. What keeps changing is the content of your mobile pages and how fast they are for real visitors.

#What Google’s mobile-first documentation asks WordPress sites to check

The best practices page is a parity checklist. The mobile version of a page should match the desktop version on:

• the main content, including text, images and video
• structured data
• the title element and the meta description
• image alt text
• robots meta tags
• headings

The same page warns against lazy-loading primary content that appears only after a user interaction such as a tap or a swipe, because the crawler does not perform those interactions. In WordPress the usual offenders are tabs or accordions that fetch their content by AJAX on click, and separate mobile templates from older mobile plugins that drop sections, schema or alt text. A responsive theme that sends the same HTML to every device passes the parity check by design. That is one reason to be careful with device-specific HTML, covered in the Client Hints section below.

#Core Web Vitals thresholds for mobile in 2026

The current thresholds are:

Since March 2024 the responsiveness metric is Interaction to Next Paint. Rick Viscomi’s launch post on web.dev announced INP as a stable Core Web Vital replacing First Input Delay, and gave developers until 9 September 2024 to move off FID. A guide that still lists FID as a Core Web Vital predates that change.

Each threshold is assessed at the 75th percentile of page loads, segmented across mobile and desktop (web.dev, Web Vitals). Mobile and desktop are separate populations, so a fast desktop result says nothing about the phone result.

Many teams set internal targets below the “good” line to leave headroom, because field data moves with traffic mix, campaigns and third-party scripts. Google’s own page experience documentation adds a caution: chasing a perfect score purely for SEO reasons may not be the best use of your time.

#How Google uses page experience signals in ranking

Google’s page experience documentation answers the ranking question directly:

• There is no single page experience signal. Core ranking systems look at a variety of signals.
• Core Web Vitals are used by Google’s ranking systems.
• Beyond Core Web Vitals, other page experience aspects do not directly help a site rank higher, although they make the site more satisfying to use.
• Page experience is generally evaluated per page, with some site-wide assessments.
• Google still shows the most relevant content when page experience is weak. A good experience helps where many pages are similarly helpful.

For mobile work this sets priorities. Touch target size, a clean mobile menu and bfcache eligibility are worth doing for visitors and for the Core Web Vitals they influence, but Google does not describe them as separate ranking signals. The same page lists no AMP requirement: its self-assessment covers Core Web Vitals, HTTPS, display on mobile devices, ads, intrusive interstitials and a clear main content area.

#How to test mobile speed in the lab and in the field

#Lighthouse mobile emulation settings

Lighthouse’s default mobile run emulates a Moto G Power (2022) with a 412 by 823 pixel viewport, set in the Lighthouse configuration constants. The throttling documentation gives the network preset as 150 ms latency, 1.6 Mbps down and 750 Kbps up, labelled “Slow 4G” and described as roughly the bottom quarter of 4G connections. CPU throttling uses a constant 4x multiplier, meant to move a high-end desktop into the mid-tier mobile bracket. On a slower laptop that multiplier overshoots, so check the “CPU/Memory Power” value at the bottom of the report before comparing runs from different machines.

• Lighthouse (Chrome DevTools): mobile emulation with CPU and network throttling
• PageSpeed Insights: real-user data (CrUX) plus a Lighthouse lab run
• WebPageTest: tests on real devices from different locations

#Field data from CrUX and Search Console

Field data is what the Core Web Vitals assessment uses. The CrUX methodology collects data only from Chrome users who enable usage statistic reporting and sync their browser history, and Chrome on iOS is excluded. Safari is not Chrome, so it contributes nothing either. A site whose mobile audience is mostly on iPhones gets its mobile field score from its Android visitors.

• Chrome User Experience Report (CrUX): real Chrome user data
• Google Search Console (Core Web Vitals report): mobile and desktop groups for your own URLs
• RUM (Real User Monitoring): tools such as SpeedCurve, Calibre or New Relic for continuous monitoring across all browsers

#Which real phones to test on

No emulator fully reproduces a real device. Keep at least these for testing:

• a mid-range smartphone (Moto G or Samsung Galaxy A)
• a recent high-end smartphone (iPhone or Pixel)
• a tablet (iPad or Samsung Tab)

#Adaptive loading by device in WordPress

Adaptive loading serves different weights of the same page depending on what the visitor’s device can handle.

#How to detect device capabilities with JavaScript

// Detect device capabilities, with defaults where an API is missing
const getDeviceCapabilities = () => {
  return {
    // CPU cores
    cores: navigator.hardwareConcurrency || 4,
    // Approximate device memory in GB (not available in every browser)
    memory: navigator.deviceMemory || 4,
    // Effective connection type
    connection: navigator.connection?.effectiveType || '4g',
    // Reduced data preference
    saveData: navigator.connection?.saveData || false,
  };
};

MDN marks navigator.deviceMemory as limited availability, not Baseline, available only over HTTPS, and deliberately imprecise: the value is rounded to a power of two to make fingerprinting harder. Treat it as a hint with a safe default. Image format choice does not need detection at all, because the picture element shown below lets the browser pick AVIF or WebP itself.

#What to serve to high, mid and low-end phones

Based on the detected capabilities:

High-end devices (8+ cores, 8+ GB RAM, fast connection):

• full-quality AVIF images
• complete JavaScript with animations
• broader speculative loading of likely next pages
• video backgrounds where they serve the content

Mid-range devices (4 to 6 cores, 4 to 6 GB RAM, 4G):

• medium-quality images
• reduced JavaScript, simple CSS animations
• speculative loading only for main links
• static images instead of video backgrounds

Low-end devices (2 to 4 cores, under 4 GB RAM, slow connection or Save-Data):

• aggressively compressed images
• only essential JavaScript
• no speculative loading, to save bandwidth
• a simplified layout without visual effects

#Client Hints, Accept-CH and page caching in WordPress

Client Hints let the server make the same decision before it sends HTML. The browser does not send them unprompted. According to MDN’s Client Hints guide, the server announces which hints it wants in an Accept-CH response header, and the browser includes them in subsequent requests. The first page view of a new visitor therefore arrives without them. Only the low entropy hints (Save-Data, Sec-CH-UA, Sec-CH-UA-Mobile and Sec-CH-UA-Platform) may be sent by default. Device memory travels as Sec-CH-Device-Memory, and network quality as ECT, RTT and Downlink.

// 1. Ask the browser for device and network hints on later requests
add_action('send_headers', function () {
    header('Accept-CH: Sec-CH-Device-Memory, ECT');
    header('Vary: Sec-CH-Device-Memory', false);
});

// 2. Read the hints and choose a performance tier
function device_aware_content_strategy() {
    $memory = isset($_SERVER['HTTP_SEC_CH_DEVICE_MEMORY'])
        ? (float) $_SERVER['HTTP_SEC_CH_DEVICE_MEMORY']
        : null;

    $ect = $_SERVER['HTTP_ECT'] ?? null;

    if ($memory && $memory >= 8 && $ect === '4g') {
        define('WP_DEVICE_TIER', 'high');
    } elseif (($memory && $memory <= 2) || in_array($ect, ['slow-2g', '2g'], true)) {
        define('WP_DEVICE_TIER', 'low');
    } else {
        define('WP_DEVICE_TIER', 'medium');
    }
}
add_action('init', 'device_aware_content_strategy');

The caching side is where server-side adaptation usually breaks. A full-page cache plugin or a CDN stores one copy of the HTML per URL unless its cache key includes the hint. Without that, the tier chosen for the first visitor is served to everyone after them. MDN recommends listing the hints that change a response in the Vary header, and warns that hints with many possible values, such as Downlink and RTT, make a response effectively uncacheable. For most WordPress sites the safer split is to keep the HTML identical for every device, let srcset and sizes choose image files, and do JavaScript adaptation on the client. That also keeps the content parity Google’s mobile-first documentation asks for.

#How to improve mobile LCP

Largest Contentful Paint is usually the hardest metric to improve on mobile, because it depends on the network, the CPU and the size of the content at once.

#Which element is the LCP on mobile

On most WordPress pages the mobile LCP element is one of these:

• the hero or featured image of the post
• a banner image in a slider
• the first long block of text, on pages without images

#LCP subparts and where the time goes

web.dev’s guide to optimizing LCP splits the metric into four subparts: time to first byte, resource load delay (from TTFB until the browser starts loading the LCP resource), resource load duration, and element render delay (from the end of the download until the element is fully rendered). The guide’s budget is that most of the time should go to loading the HTML document and the LCP resource, about 40 percent each, while each of the two delays stays under 10 percent. A long resource load delay almost always means the browser found the image late. The same guide lists an LCP image set as a CSS background as a case the preload scanner cannot discover in the HTML, and says never to lazy-load the LCP image.

#How to speed up LCP with preload, format and image size

Preload the LCP resource:

<link rel="preload" as="image" href="/images/hero-mobile.avif"
      type="image/avif" fetchpriority="high">

Remove discovery chains: The browser should find the LCP resource as early as possible:

1. The HTML downloads (TTFB)
2. The LCP resource is discovered in the HTML
3. The resource download starts

If your hero image is referenced in an external stylesheet as a background-image, the browser will not discover it until it has downloaded and parsed the CSS. Put an <img> directly in the HTML with fetchpriority="high".

Optimal image format:

<picture>
  <source srcset="/images/hero-400.avif 400w,
                  /images/hero-800.avif 800w"
          type="image/avif" sizes="100vw">
  <source srcset="/images/hero-400.webp 400w,
                  /images/hero-800.webp 800w"
          type="image/webp" sizes="100vw">
  <img src="/images/hero-800.jpg"
       alt="Relevant description"
       width="800" height="450"
       fetchpriority="high"
       decoding="async">
</picture>

Mobile-specific image sizes: Do not send the same file to phones and desktops. A 400 pixel wide phone screen does not need a 1920 pixel image (more in our image optimization and critical CSS guide):

// Add image sizes for mobile layouts
function add_mobile_image_sizes() {
    add_image_size('mobile-hero', 480, 270, true);
    add_image_size('mobile-thumbnail', 320, 180, true);
}
add_action('after_setup_theme', 'add_mobile_image_sizes');

#WordPress core features for responsive images and lazy loading

Much of the image work above is already in WordPress core, and a plugin that repeats it can get in the way.

• WordPress 4.4 (2015): srcset and sizes. Joe McGill’s dev note explains that WordPress adds srcset and sizes to the image markup it generates, so the browser can download the most appropriate size. The default sizes value assumes the image is shown at its own width up to full viewport width, and the note tells themes to adjust it with the wp_calculate_image_sizes filter (wp_calculate_image_srcset changes the candidate list). The max_srcset_image_width filter caps the widths included, 1600 pixels by default. The same release added the medium_large size, 768 pixels wide with no height limit, generated only for new uploads or when sizes are regenerated.
• WordPress 5.5: native lazy loading. The loading attribute is controlled by wp_lazy_loading_enabled, introduced in 5.5 and enabled for iframes by default since 5.7.
• WordPress 6.3: loading optimization attributes. wp_get_loading_optimization_attributes decides whether an image gets loading="lazy", fetchpriority="high" or decoding="async". It leaves attributes already present untouched and warns if an element would get both lazy loading and high priority. Since 7.0 it also accepts fetchpriority="low" and fetchpriority="auto" so that lazy loading is not added.

The practical check is in the rendered HTML of a real page on a phone viewport: the hero image should carry fetchpriority="high" and no loading="lazy", and its sizes value should match the space the image actually takes in the mobile layout. A theme that prints the hero as a CSS background skips all of this.

#Speculative loading in WordPress 6.8

WordPress 6.8 turned on speculative loading through the browser’s Speculation Rules API. Felix Arntz’s dev note sets out the defaults:

• It is enabled on the frontend of all sites, except for logged-in users and sites with pretty permalinks disabled.
• URLs are prefetched with conservative eagerness, which triggers when a user starts to click a link.
• URLs with query parameters are excluded automatically, which covers most “action URLs” that change state on a GET request.
• Chrome, Edge and Opera support the API; other browsers ignore it, so nothing breaks.

The note reports that the feature plugin ran on over 50,000 sites before the merge, and that sites using it improved their LCP passing rate by about 1.9 percent at the median, measured with HTTP Archive and CrUX data. On mobile, where back and forward taps and link taps are the whole navigation model, this matters more than on desktop. Plugins with their own action paths, such as a cart, should exclude them:

add_filter( 'wp_speculation_rules_href_exclude_paths', function ( $href_exclude_paths ) {
    $href_exclude_paths[] = '/cart/*';
    return $href_exclude_paths;
} );

#How to improve mobile INP

INP measures how quickly the page responds to user input. web.dev’s INP article counts three interaction types: mouse clicks, taps on a touchscreen, and key presses on a physical or onscreen keyboard. Hovering, zooming and scrolling are not observed. Each interaction’s latency has three parts: input delay before any handler runs, processing time of the handlers, and presentation delay until the next frame is painted. On a phone every interaction is a tap, and the CPU is slower, so all three parts grow.

#Main causes of poor mobile INP

1. Heavy JavaScript on the main thread: third-party scripts (analytics, chat, ads) that block interaction.
2. Framework hydration: React, Vue or Angular hydrating components after the initial load.
3. Expensive event handlers: listeners that run heavy calculations on tap.
4. Long tasks: web.dev’s guide to optimizing long tasks defines a long task as any task that takes longer than 50 ms.

#How to reduce INP by deferring JavaScript

Defer non-critical JavaScript:

<!-- Load analytics after the first user interaction -->
<script>
  let analyticsLoaded = false;
  function loadAnalytics() {
    if (analyticsLoaded) return;
    analyticsLoaded = true;
    const script = document.createElement('script');
    script.src = '/analytics.js';
    document.head.appendChild(script);
  }

  // Load on first touch, scroll or key press, or after 5 seconds
  ['touchstart', 'scroll', 'keydown'].forEach(event => {
    document.addEventListener(event, loadAnalytics, { once: true, passive: true });
  });
  setTimeout(loadAnalytics, 5000);
</script>

Use requestIdleCallback for non-urgent work:

// Run non-critical work while the browser is idle
requestIdleCallback((deadline) => {
  while (deadline.timeRemaining() > 0) {
    processNonCriticalTask();
  }
});

Yield inside event handlers:

function yieldToMain() {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }
  return new Promise((resolve) => setTimeout(resolve, 0));
}

button.addEventListener('click', async () => {
  showSpinner();        // visible feedback in the next frame
  await yieldToMain();  // let the browser paint first
  heavyCalculation();   // the slow part runs in a later task
});

Wrapping the heavy work in requestAnimationFrame does not help, because that callback runs right before the next paint and still holds the frame back. Yielding splits the work so the browser can paint the response to the tap first. The long tasks guide notes that scheduler.yield() is supported in Chrome and Edge 129 and Firefox 142 but not in Safari, which is why the setTimeout fallback is there.

#How to prevent mobile CLS in WordPress

Cumulative Layout Shift (CLS) hurts most on a phone, where the screen is small and any movement is visible. On a phone, a shift of 10 pixels is far more disruptive than on a 27-inch monitor.

#What causes CLS on mobile

• images without explicit dimensions
• web fonts that cause FOUT or FOIT
• ads and dynamically injected content
• navigation bars that change size on scroll
• the virtual keyboard pushing content

#How to reserve space for images, fonts and ads

Reserve space for images:

/* Aspect ratio boxes for images */
.wp-post-image {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
  object-fit: cover;
}

Preload critical fonts:

<link rel="preload" href="/fonts/main-font.woff2"
      as="font" type="font/woff2" crossorigin>

/* font-display: swap with a metric-matched fallback */
@font-face {
  font-family: 'MainFont';
  src: url('/fonts/main-font.woff2') format('woff2');
  font-display: swap;
  size-adjust: 98%;
  ascent-override: 95%;
  descent-override: 22%;
}

Reserve space for ads:

.ad-slot {
  min-height: 250px; /* Expected ad height */
  background: #f5f5f5;
  contain: layout;
}

#How to make WordPress pages eligible for bfcache

The back/forward cache keeps a complete snapshot of a page in memory, including the JavaScript heap, so going back restores it almost instantly without touching the network. Philip Walton and Barry Pollard’s bfcache guide on web.dev cites Chrome usage data showing that 1 in 5 navigations on mobile is a back or forward navigation, against 1 in 10 on desktop. All major browsers have a bfcache, Chrome since version 96.

#What blocks the bfcache

• unload listeners. Since Chrome 155, unload handlers no longer fire by default in Chrome, and the change is coming to other Chromium-based browsers. They can still fire in Chrome on iOS and on sites that opt back in through Permissions Policy (Chrome for Developers, 16 October 2026). Chrome says this cut the share of navigations where unload was the only bfcache blocker from 6% to about 1%. Firefox still makes a page with an unload listener ineligible, except on iOS (web.dev). Use pagehide or visibilitychange instead; Lighthouse has a no-unload-listeners audit that also catches third-party code.
• Cache-Control: no-store on the HTML. Browsers have historically refused to put such pages in the bfcache. For content that must stay fresh but is not sensitive, the guide recommends no-cache or max-age=0, which do not affect eligibility.
• window.opener references. A page opened with window.open() and controlled from its opener cannot be cached. rel="noopener" avoids it and is now the browser default for target="_blank".
• Open connections. Some browsers skip pages with an open IndexedDB connection, an in-progress fetch() or XMLHttpRequest, or an open WebSocket or WebRTC connection. The guide notes that Chrome (as of version 149) and Safari no longer block on open WebSockets. Close connections on pagehide and reopen them on pageshow.

Mobile users navigate with the Back button constantly. When a page comes back from the bfcache, it appears without a new request.

#How to check whether a page was restored from the bfcache

// Check whether the page was restored from the bfcache
window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    console.log('Page restored from bfcache');
    // Refresh dynamic content such as cart counts if needed
    refreshDynamicContent();
  }
});

The guide also recommends refreshing stale or sensitive data on pageshow when persisted is true, for example a cart total after the user changed it on another page.

#WordPress settings for bfcache

// Send cache and policy headers before any output
add_action('send_headers', function () {
    if (!is_user_logged_in()) {
        header('Cache-Control: public, max-age=300');
        // Refuse unload handlers, including those added by third parties
        header('Permissions-Policy: unload=()');
    }
});

// Remove a plugin script known to register an unload handler
add_action('wp_enqueue_scripts', function () {
    wp_dequeue_script('plugin-with-unload-handler');
}, 99);

Headers belong in send_headers, because wp_enqueue_scripts runs inside wp_head, after output has started. The Permissions Policy line follows the bfcache guide’s advice for sites that do not use unload at all. Chrome DevTools has a back/forward cache test in the Application panel that names the exact blocking reason for a page.

#Touch targets and mobile menus that are easy to tap

Touch targets matter for usability and accessibility. They are not described by Google as a ranking signal.

#Minimum touch target size

• WCAG 2.2, success criterion 2.5.8 (level AA): the Understanding document requires pointer targets of at least 24 by 24 CSS pixels, with exceptions for spacing, an equivalent control, inline targets in text, user agent controls and essential cases. For important controls it points to the stricter 2.5.5 Target Size (Enhanced).
• Lighthouse tap targets guidance: the audit documentation says 48 by 48 pixel targets never fail and 8 pixels between targets is a good starting point.

The inline exception matters for CSS. Links inside paragraphs do not need a minimum height, so apply sizing to navigation, buttons and form controls only:

/* Minimum touch targets for controls, not for links inside text */
nav a, button, input, select, textarea, .wp-block-button__link {
  min-height: 48px;
  min-width: 48px;
  padding: 12px;
}

#How to make a mobile menu easy to tap

Mobile navigation menus need extra care with touch targets:

.mobile-nav a {
  display: block;
  padding: 16px 24px;
  min-height: 48px;
  font-size: 16px; /* Readable without zoom */
  line-height: 1.5;
}

.mobile-nav li + li {
  border-top: 1px solid #eee;
}

#Mobile Core Web Vitals optimization by WPPoland

At WPPoland, we build for the device in the user’s hand, not the monitor on our desk.

1. Adaptive loading: we keep HTML identical across devices and adapt images and scripts where the measurements show a gain.
2. Mobile-specific auditing: we test on real mobile devices, not only in browser emulation.
3. Field data first: we work on the mobile CrUX report, taking URL groups from “Poor” or “Needs improvement” to “Good”.

#Mobile performance FAQ

1. Does a mobile app mean I don’t need a fast mobile site? No. Most of your traffic still comes from search engines and social media links. If your mobile site is slow, visitors leave before they ever see the link to your app.
2. Is “Dynamic Serving” better than “Responsive Design”? In practice the answer is often a hybrid. HTML and CSS stay responsive and identical for every device, while image files, JavaScript and non-critical features are adjusted to the device and connection.
3. What is the LCP goal for mobile in 2026? The “good” threshold is 2.5 s at the 75th percentile of mobile page loads. Aim below it with enough margin that a heavier campaign week does not push the page over.

#Conclusion

Google has crawled and indexed the web as a smartphone since the migration finished in 2023 and 2024. Mobile performance work for WordPress now comes down to a few measurable things: the same content on every device, an LCP image the browser finds in the HTML, short tasks around every tap, reserved space for everything that loads late, and pages that the bfcache can keep. Measure them in CrUX for your mobile visitors, check them with Lighthouse on a throttled profile, and fix each Core Web Vitals metric in that order. For INP specifically, see the INP optimization guide.

If your mobile Core Web Vitals are holding back your rankings, contact WPPoland for a mobile audit.