Skip to content
Searcle Book a demo

Why Your Mobile Speed Score Stalls—and How to Find the Real Bottleneck

Nina Okonkwo

The short answer: mobile testing exposes costs that desktop testing can hide

PageSpeed Insights generates separate mobile and desktop reports because its Lighthouse lab audits evaluate the page under different simulated conditions. The mobile environment is more constrained in processing power and network delivery, so work that finishes quickly in the desktop test can become much more visible on mobile. Google’s PageSpeed Insights documentation explains how PSI combines Lighthouse lab testing with Chrome UX Report field data and is the best reference for the active configuration.

The page may be identical in both audits, but its costs are not. Under tighter constraints:

  • JavaScript takes longer to parse, compile, and execute.
  • Images, fonts, CSS, and video take longer to transfer.
  • Long request chains become more consequential.
  • Main-thread tasks delay rendering and responsiveness for longer.
  • A slow initial HTML response postpones every resource discovered afterward.
  • Render-blocking dependencies consume more of the time available before useful content appears.

That is why a mobile performance score can be harder to increase. A faster desktop environment may conceal inefficient code, an oversized hero image, or a crowded initial loading sequence. The mobile audit magnifies those costs.

A large mobile-versus-desktop gap does not automatically prove that the responsive template has a mobile-only defect. It may indicate one—for example, a mobile-menu script that misbehaves or a hidden carousel that still downloads every slide—but the gap can also arise because the same resources are being evaluated under more demanding conditions.

This also explains why a page can feel fast on your personal phone while receiving a weak mobile score. Your device may have a faster processor, a strong connection, cached resources, or a geographically close route to the server. You may also be judging a repeat visit, while the lab audit evaluates a controlled page load.

That difference does not make the audit useless. Constrained testing can reveal risks faced by people using slower hardware, weaker connectivity, an empty cache, or a more distant server route. Treat the lab result as a stress test rather than a universal description of every visit: it shows where the page becomes vulnerable when resources are limited.

Finally, do not rely on old articles that permanently associate PageSpeed Insights with a particular phone, network profile, metric set, or scoring formula. Lighthouse changes over time. Historical descriptions can explain an older test, but they should not be assumed to describe the current environment. Verify exact configurations and scoring details against current documentation before using them to make technical decisions.

Why meaningful technical work may barely move the headline score

The performance score is not a direct measurement of page weight, request count, or total loading time. It is calculated from multiple lab measurements. You can therefore reduce hundreds of kilobytes, improve caching, or eliminate several requests and still gain only a few points if those changes do not materially improve the measurements constraining the score.

The Lighthouse performance report commonly surfaces these measurements:

  • First Contentful Paint (FCP): When the browser first displays visible page content, such as text or an image.
  • Largest Contentful Paint (LCP): When the largest visible content element in the initial viewport is rendered. This is often a hero image, heading block, poster image, or large content panel.
  • Total Blocking Time (TBT): The blocking caused by long main-thread tasks during the measured lab loading period. It helps diagnose JavaScript and main-thread pressure.
  • Cumulative Layout Shift (CLS): Unexpected visual movement as the page loads.
  • Speed Index: How quickly visible page content appears during the recorded loading sequence.

The active metric set and scoring model are version-sensitive. A third-party overview of how PageSpeed’s aggregate score is constructed describes the score as a combination of several measurements, but current Lighthouse documentation should be checked before relying on an exact list or fixed weighting.

The current Core Web Vitals are LCP, Interaction to Next Paint (INP), and CLS. Lighthouse’s aggregate lab score and CrUX field assessment serve different purposes. In particular, TBT is a lab diagnostic, while INP is a field responsiveness metric. They may both reveal responsiveness problems, but they are not interchangeable.

The bottleneck principle

Think of the score as being strongly influenced by the most severely degraded measurements—not as a literal weakest-link formula. Lighthouse combines multiple metric scores, and its effects can be nonlinear and version-dependent. In practice, however, one poor, influential measurement can dominate score movement.

If the LCP element remains very late, making an already small secondary image even smaller may barely affect the result. If main-thread blocking is severe, minifying a modest stylesheet may not move the score enough to distinguish the improvement from normal test variation.

This creates a common pattern:

  1. You enable caching and compression.
  2. The initial score improves.
  3. You optimize several minor assets.
  4. The score moves by only one or two points—or fluctuates backward.
  5. You assume the optimizations failed.

The changes may have worked exactly as intended. They simply did not resolve the limiting measurement.

Metric influence can also change between Lighthouse versions, so historical weights should not be treated as permanent. The durable lesson is that improvements to severely degraded or more influential measurements will usually matter more than polishing measurements that are already healthy.

Why later gains require more difficult work

Early improvements often come from straightforward delivery changes:

  • Compress text resources.
  • Cache reusable assets.
  • Reduce obvious image waste.
  • Remove accidental duplicate requests.
  • Minify production files.
  • Improve CDN delivery.

Once those measures are in place, the remaining delays may be structural. Raising the score further can require changing when code runs, how templates render, which dependencies are shipped, how the application produces HTML, or whether a feature loads before it is needed.

This is a common form of diminishing returns, not a universal two-stage process. Basic delivery work removes obvious overhead. If the score then plateaus, the next useful change may involve architecture, dependencies, loading order, or feature behavior.

Find the limiting metric before choosing a fix

Do not begin with a generic optimization checklist. Start with the measurement that remains poor, identify the element, request, task, or server delay affecting it, and then choose a fix.

Symptom in the mobile report Likely investigations Questions to answer first
Poor LCP Reported LCP element, origin response, resource discovery, image dimensions and bytes, request priority, render-blocking resources, client-side rendering What is the LCP element? When is its resource discovered? Is the browser waiting on HTML, CSS, JavaScript, or the asset itself?
High TBT or extensive main-thread work First-party JavaScript, plugins, tag-manager entries, chat, advertising, analytics, animation libraries, large bundles, long tasks Which scripts execute before the page becomes usable? Which tasks are longest? Does disabling a candidate reduce blocking consistently?
Poor CLS Unsized images and embeds, advertisements, banners, font swaps, injected notices, late content above existing elements Which element moves? What causes the movement? Could space be reserved before the resource arrives?
Weak FCP Slow initial HTML, render-blocking CSS or JavaScript, font loading, long dependency chains, client-rendered page shells Is the browser waiting for the server, a stylesheet, a script, or a font before anything can be painted?
Weak Speed Index Excessive above-the-fold work, late styles, heavy fonts, large initial imagery, rendering dependencies Does visible content appear progressively, or does the page remain blank until several resources finish?
Score varies without a clear metric trend Server variability, cache state, resource contention, inconsistent third-party responses, measurement variation Are you comparing repeated runs under similar conditions? Did the median metric improve?
Fast transfer but poor TBT CPU work rather than network weight Is the browser executing code long after it has downloaded?
Slow initial response followed by weak paint metrics Origin, application, database, cache, redirects, or geographic delay How long does the browser wait for the initial HTML, and is that response cached?

If LCP is poor

Start with the LCP element identified in the report. Do not assume it is the hero image; it could be a heading, poster frame, content image, or large background area.

Then inspect the loading sequence:

  1. Check how quickly the initial HTML arrives.
  2. Identify the LCP element named in the diagnostics.
  3. Find the request that supplies that element, if it uses an external asset.
  4. Check whether the request begins early or only after CSS or JavaScript reveals it.
  5. Compare the resource’s intrinsic dimensions with its displayed dimensions.
  6. Review its transfer size and loading priority.
  7. Determine whether rendering waits on CSS, fonts, JavaScript, or client-side rendering.

This separates several different delays:

  • Server delay: The browser is waiting for HTML.
  • Discovery delay: The browser does not learn about the LCP resource early enough.
  • Transfer delay: The asset takes too long to download.
  • Render delay: The resource is available, but CSS or JavaScript prevents it from appearing.

A late LCP can involve one or several of these stages. Compressing the image addresses only transfer size; it does not fix late discovery, slow HTML, or delayed rendering.

If TBT or main-thread work is high

Use the report’s main-thread and JavaScript diagnostics to identify expensive categories, then inspect a performance trace for long tasks. Expand a long task carefully enough to connect it to a script, bundle, or function rather than blaming the first recognizable third-party name.

Common candidates include:

  • Theme and page-builder code
  • WordPress plugins
  • Tag-manager containers and their tags
  • Analytics and experimentation scripts
  • Chat and support widgets
  • Advertising and audience scripts
  • Animation libraries
  • Large framework bundles
  • Client-side rendering and hydration
  • Libraries shipped to pages that do not use them

These are candidates, not convictions. A site with many plugins may still have one first-party bundle as its main problem. A chat widget may be expensive on one page and negligible on another. Disable or defer candidates individually and look for a repeatable reduction in the relevant tasks.

If CLS is poor

Watch the recorded load and identify what moves. Common causes include media without reserved dimensions, embeds that expand after initialization, banners inserted above the header, advertisements with unpredictable slots, and fonts that substantially change text geometry.

The fix should stabilize the layout rather than merely load the moving resource faster. Reserve appropriate space, choose predictable placement, control font behavior, and avoid inserting new content above what the user is already viewing.

If FCP or Speed Index is weak

Check the initial HTML response and the critical rendering path. A page can be modest in total size and still render late because the browser must follow a long dependency chain before it knows what to display.

Look for:

  • A slow document response
  • Stylesheets that block the first render
  • Synchronous or render-blocking JavaScript
  • Font files required before text appears
  • CSS imports that reveal more CSS
  • Content generated only after JavaScript executes
  • Excessive above-the-fold markup or styling
  • Redirects before the final page

PageSpeed audit opportunities are diagnostic clues, not a mandatory checklist. A red warning unrelated to the limiting measurement may be lower priority than a less prominent audit that explains the LCP delay or blocking time. Address the largest measured bottleneck, record the metric change as well as the score, and then diagnose again.

The mobile bottlenecks that become expensive under constrained conditions

CPU-intensive JavaScript

JavaScript has both delivery and execution costs. Much of this work competes for the main thread that also supports rendering and user interaction.

A smaller JavaScript file is generally easier to transfer, but transfer size alone does not reveal execution cost. A compressed bundle can still create long tasks, initialize unnecessary components, or repeatedly recalculate the page.

Under constrained processing, work that appears brief on a modern desktop can occupy the main thread long enough to delay paints or make the page temporarily unresponsive. Hosting-provider guidance on PageSpeed Insights’ constrained lab environment similarly distinguishes JavaScript execution, main-thread work, render-blocking resources, and server response.

Test likely sources rather than removing them indiscriminately. Theme code, plugins, tag-manager entries, analytics, chat, advertising, animations, and framework code can all be expensive, but their actual cost depends on implementation, page context, and execution timing.

Hero images and video

The largest above-the-fold visual is frequently the LCP element. It can become late when:

  • Its source dimensions greatly exceed its rendered dimensions.
  • The file contains more bytes than necessary.
  • It is loaded as a CSS background and discovered late.
  • JavaScript inserts it after the initial page parse.
  • A preload points to the wrong variant or competes with more important resources.
  • A video poster or first frame is delayed.
  • The server is slow to return the HTML or media.
  • The browser selects an unsuitable responsive candidate.

Different image remedies solve different problems:

  • Responsive variants address inappropriate intrinsic dimensions.
  • Compression reduces transferred bytes.
  • Modern formats can improve encoding efficiency.
  • Markup and loading priority affect discovery and scheduling.
  • Caching and CDN delivery reduce retrieval overhead.
  • Changing the visual or template can reduce the work fundamentally.

Converting an enormous source image to WebP does not make its dimensions appropriate. Preloading a poorly compressed asset does not reduce its bytes. Diagnose the stage that is slow before selecting the remedy.

Render-blocking CSS, fonts, and dependency chains

A page can have a reasonable total transfer size but a poor first render because the browser cannot display it until critical dependencies arrive.

CSS may reference fonts or background images. One stylesheet may import another. JavaScript may assign required classes, reveal content, or construct the page. A consent tool may delay tags, while a tag manager loads scripts that initiate further requests.

Each dependency introduces another possible wait. Under a constrained network and processor, those waits become more visible.

Reduce unnecessary critical CSS, avoid deep import chains, load noncritical styles later where safe, and ensure that the first view does not depend on code intended for lower-page components. With fonts, balance visual consistency against the cost of blocking text or causing disruptive swaps.

Origin and application delay

The browser cannot discover most page resources until it receives enough HTML to parse their references. Slow dynamic HTML therefore delays almost everything that follows.

Possible causes include:

  • Database queries
  • Uncached template generation
  • Remote API calls made during page construction
  • Overloaded hosting
  • Expensive personalization
  • Redirect chains
  • Application initialization
  • Cache misses
  • Geographic distance from the origin

A CDN can cache and deliver eligible content closer to visitors, but it cannot automatically eliminate expensive uncached generation at the origin. If every document request still reaches an application that performs costly work, the CDN may accelerate static assets while the initial HTML remains late.

A 2019 Cloudflare community discussion separated slow dynamic HTML and oversized source images from the improvements edge delivery could provide for one Magento site. It is useful as a historical example of origin and image diagnosis, not as a current benchmark or a universal conclusion.

Loading content before it has user value

Hidden content is not free merely because it is invisible. The browser may still download its images, parse its markup, execute its component code, and calculate its layout.

Review whether the initial visit loads:

  • Every carousel slide
  • Media in hidden tabs
  • Below-the-fold videos
  • Large menu panels
  • Desktop-oriented components hidden with CSS on mobile
  • Maps or embeds that are not yet visible
  • Recommendation modules far below the fold
  • Animation libraries used for one minor effect

Prefer loading what is needed for the initial view and making deferred features available before the user reaches or activates them. The objective is not to make the page incomplete; it is to prevent nonvisible work from competing with the first meaningful experience.

Why caching, a CDN, WebP, and minification may stop helping

Standard speed fixes remain valuable, but they primarily improve delivery. A plateau can mean that the remaining problem is structural.

Delivery optimization versus structural optimization

Delivery optimizations include:

  • Browser and server caching
  • CDN delivery
  • Text compression
  • Asset minification
  • Efficient image encoding
  • Connection and response improvements

Structural optimizations include:

  • Removing unused dependencies
  • Splitting bundles by page or feature
  • Deferring noncritical execution
  • Reducing initial content
  • Changing rendering architecture
  • Eliminating repeated application or database work
  • Replacing an expensive widget
  • Redesigning when and how a feature becomes active

Delivery changes make existing resources cheaper to obtain. Structural changes reduce, postpone, or eliminate the work itself. Some sites can continue improving through delivery changes, but a sustained plateau often warrants examining structure and behavior.

Why a CDN reaches a limit

A CDN may improve static-asset delivery and, depending on its configuration, cache HTML. It does not inherently:

  • Resize every source image to its displayed dimensions
  • Remove unused JavaScript
  • Stop expensive code from executing
  • Reserve space for shifting embeds
  • Simplify a request chain
  • Correct client-side rendering delays
  • Eliminate uncached application work
  • Decide that a carousel should not initialize on mobile

If origin generation dominates LCP, making a small icon arrive faster will not solve the problem. If TBT dominates, moving the same JavaScript closer to the user may shorten its download without reducing its execution cost.

Why WebP or another modern format may produce little movement

Changing formats can reduce bytes, but image performance depends on more than encoding.

The result may remain weak if:

  • The source dimensions are excessive.
  • The browser downloads a variant much larger than the display requires.
  • The resource is discovered late.
  • The server response is slow.
  • The image competes with more critical requests.
  • CSS or JavaScript prevents it from rendering.
  • The LCP element is not the image you optimized.

Format conversion is one part of an image pipeline, not a substitute for responsive sizing, compression, early discovery, and appropriate priority.

Why minification is not code removal

It does not necessarily remove unused modules, duplicate libraries, event handlers, component initialization, or runtime computation.

A minified script may transfer efficiently and still consume substantial CPU time. If the trace indicates that execution is the bottleneck, investigate code splitting, conditional loading, deferral, dependency removal, or a lighter implementation.

What one historical WordPress case illustrates

In a first-person WordPress case study published in 2019, caching and CDN delivery reportedly produced an early improvement. Later gains reportedly came from removing unused plugins and dependencies, loading less initial carousel and tab content, and replacing repeated dynamic work. The author’s WordPress PageSpeed case study illustrates how further progress can require changes to dependencies and feature behavior after basic delivery improvements.

The case does not predict a particular gain for another site. It was not a controlled evaluation, did not include comprehensive repeated-run or field data, and reflects an older PageSpeed environment. Its useful lesson is narrower: a plateau can persist until the site reduces the work it asks the browser and server to perform.

Do not respond to that plateau by automatically installing another optimization plugin. Additional tooling can help, but it can also add configuration complexity or code. Isolate the bottleneck first.

Use a controlled test-and-isolate workflow

Performance troubleshooting works best as an experiment rather than a sequence of unrelated tweaks.

1. Establish a baseline

Before changing anything, record:

  • Mobile performance score
  • LCP
  • TBT
  • CLS
  • FCP
  • Speed Index
  • Reported LCP element
  • Major long tasks
  • Initial HTML response timing
  • Large or late critical requests
  • Test date, environment, and relevant cache state

Save reports or screenshots where useful. Without a baseline, ordinary variation can easily be mistaken for improvement.

2. Run the baseline several times

Run multiple tests under conditions that are as consistent as practical, then compare median results rather than selecting the best, worst, or newest score.

There is no universal evidence-backed number of runs suitable for every site. A stable static page may require fewer observations to reveal a clear change than a dynamic page with variable server or third-party behavior.

Scores can vary even when the code has not changed. Server load, cache state, network availability, hardware availability, resource contention, and third-party responses can affect an individual run. Commentary on Lighthouse variability and repeated testing likewise recommends comparing multiple runs rather than treating one result as definitive.

3. Use staging for disruptive tests

Do not disable checkout code, analytics, consent management, forms, security tools, or customer-facing widgets on production merely to see whether the score changes.

Use a staging environment that resembles production closely enough for meaningful comparison. Staging may still differ in hosting, caches, data, or third-party configuration, so verify important findings through a safe production release process afterward.

4. Isolate one candidate at a time

Use this sequence:

  1. Choose one plugin, tag, script, widget, or feature.
  2. Disable or defer it on staging.
  3. Repeat the same audit process.
  4. Record both the score and the underlying measurements.
  5. Confirm whether the relevant request, script, or long task disappeared.
  6. Restore the candidate if there is no meaningful, repeatable effect.
  7. Continue with the next candidate.

In a response concerning one JavaScript-heavy WordPress site, Web Vitals specialist Barry Pollard recommended testing plugins individually and conducting disruptive investigation on staging. That is a diagnostic method, not evidence that plugins cause every weak mobile score.

5. Separate first-party and third-party work

Where your tooling permits, test first-party bundles separately from grouped third-party tags. This helps answer two different questions:

  • Is the site’s own application or theme consuming most of the main thread?
  • Is externally supplied code introducing substantial early work?

Do not expect perfect attribution. Scripts can trigger one another, compete for resources, or behave differently when a dependency is absent. The goal is to identify the expensive loading path with enough confidence to act, not to assign every millisecond precisely.

Prioritize candidates that:

  • Execute before visible content appears
  • Produce long tasks
  • Load large dependencies
  • Block rendering
  • Trigger multiple downstream requests
  • Initialize hidden components
  • Run on every page despite being needed on only a few
  • Depend on slow third-party origins

6. Decide what to do with the expensive feature

Once a feature is confirmed as costly, use four options:

  • Retain: Keep it unchanged because it is essential and no practical alternative exists.
  • Defer: Load or initialize it after the critical view, after consent, on interaction, or as it approaches the viewport.
  • Replace: Use a lighter library, static preview, server-rendered alternative, or simpler implementation.
  • Remove: Eliminate it when its user or business value does not justify its cost.

Then repeat the baseline process. A successful change should improve the limiting measurement consistently, not merely produce one unusually high score.

Separate Lighthouse lab results from real-user Core Web Vitals

PageSpeed Insights can present two kinds of evidence:

  • Lighthouse lab data: A controlled diagnostic test performed under a simulated environment.
  • CrUX field data: Aggregated experiences from eligible Chrome users who visited the URL or origin.

CrUX field data covers a rolling 28-day period, and PSI assesses field performance at the 75th percentile. The field Core Web Vitals are LCP, INP, and CLS, as explained in Google’s official overview of PageSpeed Insights lab and real-user data.

Why the two reports disagree

Lab and field results can differ because they represent different:

  • Devices and processing capabilities
  • Network connections
  • Geographic locations
  • Server routes
  • User populations
  • Cache states
  • Page states
  • Authentication or personalization states
  • Time frames
  • Interactions after the initial load

A lab test may expose a reproducible JavaScript bottleneck under constraint while most field visitors use faster devices. Conversely, a lab run may look healthy while field users encounter slow regional servers, intrusive post-load scripts, delayed interactions, or page states that the lab did not exercise.

Neither result automatically invalidates the other.

Use lab data to:

  • Reproduce a loading path
  • Inspect requests and tasks
  • Compare controlled changes
  • Identify a candidate bottleneck
  • Confirm that a resource or task disappeared

Use field data to:

  • Understand what eligible real users experienced
  • Compare meaningful segments where available
  • Monitor performance over time
  • Check whether lab improvements translate into user benefit
  • Detect interaction and post-load problems absent from a basic load test

A good lab score does not guarantee good field performance. Favorable field data also does not make risks to constrained users irrelevant. The datasets answer different questions.

What to do when URL-level CrUX data is unavailable

First, check whether PSI presents origin-level data. A specific URL may lack enough representative samples while the broader origin has sufficient data.

Interpret origin data carefully. It combines experiences from different pages, templates, and user journeys. A fast article archive can mask a slow product page, while a heavy application area can pull down an otherwise simple site.

If representative URL- or origin-level CrUX data remains unavailable, implement appropriate real-user monitoring for LCP, INP, and CLS. Ensure that the implementation follows the privacy and consent requirements relevant to the site. Where data volume permits, segment results by template, device class, geography, navigation type, and other meaningful dimensions.

Do not treat the aggregate Lighthouse performance score as a direct ranking factor or assume that crossing one score threshold guarantees search outcomes. Use it as a diagnostic indicator, then evaluate actual user experience and the site’s broader objectives.

Know when further score gains are not worth the trade-off

A perfect 100 should not be the default objective. The score is a synthetic diagnostic result, not a complete measure of whether the page is accessible, persuasive, measurable, useful, or commercially successful.

Before implementing a change, ask:

  • Will users see or feel a meaningful improvement?
  • Does it improve field LCP, INP, or CLS?
  • Could it harm keyboard, screen-reader, or other accessibility support?
  • Does it weaken analytics or experimentation needed to understand the site?
  • Does it interrupt a booking, lead, checkout, or support path?
  • Does it damage the page’s visual or editorial purpose?
  • How much engineering and maintenance cost does it create?
  • Is the improvement stable across repeated tests?
  • Does it address the limiting measurement or merely remove a warning?

Removing chat might reduce initial scripting but make support harder to reach. Removing analytics could reduce execution while undermining decision-making. Replacing video with a still image might improve LCP but weaken the explanation of a complex product. Eliminating a carousel might help performance while removing content stakeholders consider important.

None of those trade-offs has a universal answer. The correct decision depends on feature value, implementation cost, and the magnitude of the performance problem.

Apply the retain-defer-replace-remove framework:

  • Retain essential functionality when its value clearly outweighs its cost.
  • Defer valuable features that are unnecessary during the first view.
  • Replace expensive implementations when a lighter option preserves the outcome.
  • Remove features only when their value is too low to justify their performance and maintenance burden.

A defensible stopping point is reached when:

  1. The largest material bottlenecks have been addressed.
  2. Field performance is acceptable for the site’s actual users.
  3. Repeated lab tests are stable enough to support diagnosis.
  4. Essential functionality and accessibility remain intact.
  5. Remaining improvements would demand disproportionate engineering effort or weaken useful features.
  6. The next score gain is unlikely to create meaningful user value.

The practical action order is simple:

  1. Identify the limiting measurement.
  2. Trace it to a resource, task, element, or server delay.
  3. Make one controlled change on staging.
  4. Retest several times and compare median measurements.
  5. Validate the result against field evidence where available.
  6. Stop when further work no longer creates proportionate user value.

Frequently asked questions

Why does my website feel fast on my phone but score poorly on PageSpeed Insights mobile?

Your phone, connection, location, and cache state may be more favorable than the controlled Lighthouse mobile environment. You may also be judging a repeat visit on newer hardware.

The observations represent different conditions. Use the audit to identify vulnerabilities, then compare its diagnosis with real-user field data.

Why does my mobile PageSpeed score change when I have not changed the website?

Individual tests can vary because of server response, cache state, resource contention, network availability, measurement infrastructure, and third-party behavior.

Compare several runs under similar conditions and use median measurements. Look for consistent changes in LCP, TBT, CLS, FCP, and Speed Index rather than reacting to one score.

Can a caching plugin or CDN guarantee a mobile PageSpeed score above 90?

No. Caching and CDN delivery can reduce origin work and transfer delay, but they cannot guarantee a score or fix every performance problem.

They do not automatically remove unnecessary JavaScript execution, correct oversized source images, stabilize layout shifts, simplify rendering dependencies, or eliminate expensive uncached application work.

What should I do when PageSpeed Insights shows no CrUX field data?

Check whether PSI offers origin-level data when URL-level data is unavailable. Confirm that the origin’s mix of pages reasonably represents the page you are investigating.

If representative CrUX data remains unavailable, collect real-user LCP, INP, and CLS measurements through an appropriate monitoring implementation. Continue using Lighthouse for controlled diagnosis without assuming that one simulated environment describes every visit.

Should I remove chat, analytics, animations, or carousels to improve the score?

Not automatically. Test each feature in isolation and determine whether it materially affects the limiting measurement. Then compare its performance cost with its value to users and the business.

Retain an essential feature, defer it until needed, replace it with a lighter alternative, or remove it when its value does not justify the cost. The goal is a faster, more useful page—not a higher number obtained by stripping away everything that makes the page effective.