How to read your PageSpeed Insights report

Google's verdict on three measurements from real visits: Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. It passes when all three are "good" for at least 3 in 4 visits (Google calls this the 75th percentile). If Google doesn't have enough tap data, it judges on the other two.

"Not Applicable" means Google doesn't have enough real visits to judge. That's normal for small or new stores. It also happens when the page's main content fades in from invisible, because Chrome never counts it as shown. Either way, Google then has no speed data to rank you on, good or bad.

"This URL" is data for the exact page you tested. "Origin" is your whole store added together. A single product page often has too few visits, while the whole store has enough, so switch to Origin if the page shows no data.

How long until the biggest thing on the first screen appears: usually your banner image, main product photo or headline. Good is 2.5 seconds or less. This is the one most Shopify stores struggle with, usually because of a heavy banner or apps that load before it.

When a visitor taps a button, opens the menu or picks a size, how long until the screen reacts. Good is 200 milliseconds (a fifth of a second) or less. Slow taps usually come from too many scripts running at once: apps, tracking and chat.

How much the page jumps around while it loads, for example when a banner pushes the text down just as someone goes to tap. It's a number, not a time: good is 0.1 or less. On Shopify the usual causes are announcement bars and app widgets (reviews, pop-ups, cookie bars) that appear late, and images without a set size.

How long until anything at all appears: the first bit of text, the logo, a colour block. Good is 1.8 seconds or less. It isn't one of the three Core Web Vitals, but a slow FCP drags everything else back.

How long until your store's server starts sending the page. Good is 0.8 seconds or less. On Shopify this is mostly Shopify's job, but very long pages (huge menus, big product grids) and redirects make it slower. Visitors far from Shopify's servers also see higher numbers.

Green, orange and red show what share of visits were good, needed improvement or were poor. The marker shows where the 75th percentile falls. A mostly green bar with a thin red end is normal: some visitors are always on bad connections.

"Latest 28-day collection period", "Various mobile devices", "Many samples (Chrome UX Report)", "Full visit durations", "Various network connections" and "All Chrome versions". Together they say the same thing: this is real data from many real Chrome users on all sorts of phones and connections, collected over four weeks and over whole visits, not one test.

How fast the page loads on a simulated slow phone. It's worked out from the five lab metrics in section 3, nothing else. The long list of suggestions below it doesn't change the score directly; it only explains it. This is the number that swings between runs (see section 7).

Whether people using screen readers, keyboards or zoom can use the page, and whether text is easy to read. It's the share of automatic checks your page passes, with the important ones counting more. A 100 doesn't prove the page is fully accessible: a computer can only check some things.

Basic quality and safety: secure connection, no errors, images shown at the right shape, no outdated browser features. Apps are the usual reason a Shopify store loses points here.

Whether search engines can read and list the page: it's allowed to be indexed, has a title and description, links can be followed. It's a basic health check, not a ranking prediction. A 100 here doesn't mean you'll rank; a low score means something is stopping you.

A newer section about how well AI assistants can read and use your page when they browse on someone's behalf. Instead of a score out of 100 it shows how many checks passed, for example 4/4. Google says this section is still being developed and may change. It doesn't affect your other scores. The checks are listed in section 5.

When the first text or image appears in the test. Same idea as the real-visitor FCP, but measured once on the simulated phone. A blank white start here usually means files are blocking the page (see "Render-blocking requests").

When the biggest thing on the first screen appears in the test. The biggest single part of most scores. "LCP breakdown" in the Insights tells you where the time went.

The lab test can't tap anything, so this stands in for how responsive the page is. It adds up the time the phone was too busy running scripts to react to a tap, counting only the part of each job over 50 milliseconds. It's the heaviest-weighted metric. On Shopify it's almost always apps, tracking pixels and chat widgets.

How much things jumped during the test. Only shifts during loading count here, while real visitors' CLS counts the whole visit, so the two can differ.

How quickly the screen fills in, on average, judged from the screenshots. A page that shows most of its content early scores well even if one image is late.

Google's own warning that the numbers are from one simulated run and will change if you run it again. The "calculator" link next to it lets you see how each metric adds up to the score.

Snapshots of the page loading over time, left to right. If the first several are blank white, the page started late on that run. "View Treemap" opens a map of every script on the page, sized by how big it is, so you can see which apps are heaviest.

Filter buttons. Pick LCP, for example, and the list below shows only the items that affect that metric. Useful when one metric is red and you want to know why.

A yellow note that sometimes appears at the top, for example "The page loaded too slowly to finish within the time limit". It means the run itself had a problem, so don't trust that run's numbers. Run the test again.

Files the phone must download before it can draw anything, mostly stylesheets and some scripts. Until they're done, the screen stays blank.

Matters: a lot, it delays the first frame directly. On Shopify: your theme's main stylesheet is needed, but stylesheets added by apps (from cdn.shopify.com/extensions), Google Fonts and app scripts in the theme's head usually don't need to block. They can load in the background.

Splits the time to your main content into parts: how long the server took (time to first byte), how long before the image started downloading, how long it took to download, and how long it waited after that before being shown (element render delay).

Matters: it tells you where to look. On Shopify: a large "element render delay" means the content was ready but something held it back: blocking files, a slideshow script, or a fade-in animation.

Checks that the main image can be found straight from the page's code, isn't set to load lazily, and is marked as high priority. Shows "not applicable" when your main content is text.

Matters: yes when it fails. On Shopify: a banner set to lazy-load, a banner added as a background picture in the styles, or a slider that builds the banner with a script.

The very first request, for the page itself. Google checks there's no redirect, that the server answers quickly and that the page is compressed.

Matters: everything waits for it. On Shopify: compression and hosting are handled for you. Redirects are the usual problem: testing yourstore.com when the store lives at www.yourstore.com, or links in your menu that go through an old address.

Chains of files where one has to finish before the next is even found: a stylesheet that then asks for a font, a script that loads another script. It may also suggest connecting to some outside servers early ("preconnect").

Matters: sometimes. Long chains on the first screen delay it. On Shopify: fonts loaded from stylesheets and app scripts that load more scripts. It often shows a warning even on fast pages, so judge it by the timings, not the colour.

Images that are bigger than they're shown, in an older format, or could be compressed more.

Matters: yes for the first screen, less for images further down. On Shopify: Shopify already serves modern formats when the theme asks for the right size. Big savings usually come from apps that load full-size images, or a theme section showing a 3,000-pixel photo in a small box.

Files that tell the browser to keep them only for a short time, so returning visitors download them again.

Matters: little. It only helps repeat visits and doesn't change the lab score much. On Shopify: your theme files are already cached well. What's listed is usually other companies' files (tracking, reviews, chat), which you can't change.

Text that stays invisible while a custom font downloads.

Matters: yes if it shows up. On Shopify: most themes handle this already. It usually comes from an app's font or a font added by hand.

Names what made the page jump: images without a set size, fonts swapping, or content added late.

Matters: yes, layout shift is a quarter of the score and a Core Web Vital. On Shopify: announcement bars, review stars, pop-ups, cookie bars and currency or shipping banners that appear after the page has drawn.

The page is built from too many pieces (the "DOM" is the page's building blocks). More pieces means more work for the phone on every tap and scroll.

Matters: moderately, mostly for tap speed. On Shopify: big mega menus, long product grids, review widgets, and themes that build the menu twice, once for phones and once for computers.

The same code downloaded twice, in two different files.

Matters: usually a little. On Shopify: two apps that each bring their own copy of the same library.

Extra code written so very old browsers can cope. Modern phones don't need it.

Matters: a little. On Shopify: it's inside apps' files, so the only fix is a lighter app or none.

A script changes the page and immediately asks how big something is, so the phone has to recalculate the layout on the spot instead of later in one go.

Matters: a little, mostly for responsiveness. On Shopify: sliders, sticky headers and app widgets measuring the page as it loads.

A list of other companies' code on your page (analytics, ads pixels, chat, reviews, email pop-ups), with how much each downloads and how long it keeps the phone busy.

Matters: yes, often the biggest single cause of slow scores. On Shopify: every app and pixel shows up here. Most can wait until the visitor first taps or scrolls without losing anything.

Splits the time of a tap into waiting, processing and drawing. The standard PageSpeed run doesn't tap anything, so it usually says "not applicable". Real tap speed is in the top half of the report.

Checks that the page tells phones to use their real screen width. Without it, taps can be delayed by up to 300 milliseconds. Every current Shopify theme has it, so this should always pass.

Script code that downloads but isn't used while the page loads.

Matters: yes when it's large and loads early. On Shopify: app scripts, tracking and theme scripts for features not on this page. Some of it is used later (when someone opens the cart), so not all of it is waste.

Style rules that download but aren't used on this page.

Matters: a little, unless the styles block the first frame. On Shopify: themes ship one big stylesheet for every page type, and apps add their own. Some is used later, for menus and the cart.

Files that still contain spaces, comments and long names that could be squeezed out.

Matters: small savings. On Shopify: usually flagged for app files or code pasted into the theme by hand.

The total size of everything the page downloads. On a phone, several megabytes is heavy and costs data.

Matters: yes when the heavy part loads early. On Shopify: autoplay videos, big banners, embedded YouTube players and many apps.

How long the phone spends reading and running scripts, listed by file.

Matters: yes, it drives Total Blocking Time. On Shopify: the top entries are usually apps and tracking, not the theme.

Everything the phone's main processor did: running scripts, working out styles and layout, and drawing. The phone can't react to taps while it's busy with these.

Matters: yes, same cause and cure as the item above.

The longest single jobs the phone did, over 50 milliseconds each. During each one, a tap has to wait.

Matters: yes for Total Blocking Time. On Shopify: usually a tracking script or app starting up.

Animations the phone has to redraw frame by frame instead of handing to its graphics chip. They can stutter and make things shift.

Matters: a little. On Shopify: scrolling announcement bars, fade and slide effects on load, animated badges.

Images that don't say how big they'll be, so the page doesn't keep space for them and jumps when they arrive.

Matters: yes for layout shift. On Shopify: images in custom sections, product descriptions and app widgets.

Lists timing labels a developer added to the code. Information only, nothing to fix.

• Buttons, links, form fields, menus and frames have a name: so a screen reader can say "Add to cart" instead of just "button". Icon-only buttons (search, cart, close) are the usual misses.
• Image elements have alt text: a short description of each picture. Decorative images can have an empty one. Also covers image buttons and embedded objects.
• Alt text isn't redundant: it doesn't just repeat the text next to the image.
• Form elements have labels, and only one each: the newsletter box and search box need a proper label, not just grey placeholder text.
• Select menus have labels: for example the size and colour pickers.
• Document has a title: the page name shown in the browser tab and in Google.
• Skip links are focusable: a "skip to content" link, if you have one, actually works.

ARIA is extra code that tells screen readers what something is, like "this is a menu" or "this is hidden". Google runs about twenty checks that it's used correctly:

• Each kind of control has a name: buttons and links, dialogs, input fields, toggles, meters, progress bars, tooltips and tree items.
• Roles and attributes are valid: real role names, correctly spelt attributes, sensible values, nothing outdated, and only attributes allowed for that role.
• Required parts are present: roles that need certain attributes, child items or a parent have them.
• Hidden things stay hidden: the whole page isn't marked hidden, and hidden areas don't contain buttons you can still tab to.
• Text groups and IDs: "role=text" isn't wrapped around clickable things, and ARIA IDs aren't used twice.

On Shopify, failures usually come from apps (pop-ups, chat, review carousels) rather than the theme.

• Text has enough contrast: light grey text on white, or white text on a pale photo, is hard to read. The most common accessibility miss on Shopify stores, usually sale badges, footers and banner text.
• Links don't rely on colour alone: links inside paragraphs need an underline or another visible difference, not just a different colour.

• Headings go in order: no jumping from a main heading straight to a small one. Themes where section titles are styled as random heading levels fail this.
• No custom tab order: the Tab key moves through the page in reading order.
• Access keys are unique: keyboard shortcuts, if any, don't clash.
• There's a way to skip repeated content: a heading, skip link or landmark so keyboard users can jump past the menu.

• The page says its language, and it's a valid one: so screen readers pronounce the text correctly. Also checks any language set on parts of the page, and that two ways of stating the language agree.

• Lists are built properly: list items sit inside a list, and lists contain only list items. Same for definition lists.
• Table headings point at the right cells: so size charts and spec tables make sense when read aloud.

• Zoom isn't blocked: visitors can pinch to zoom. Some older themes switch this off.
• Touch targets are big enough and spaced out: small swatches, dots under sliders and footer links packed together fail this.
• The page has one main area marked as main content.
• No automatic page refresh.
• Autofill hints are correct: name, email and address fields use valid autocomplete values.
• Headings aren't empty, identical links lead to the same place, and icons drawn in code have a text alternative.
• Elements marked as decoration really are decoration, roles are used only on elements that allow them, and tables don't repeat their caption.

• Videos have captions: a captions track for people who can't hear. Applies to video files on your page, not YouTube embeds.

Ten things a computer can't judge, listed for a person to test by hand: controls can be reached and seen with the keyboard, interactive things look interactive, the Tab order follows the layout, the visual order matches the code order, focus never gets stuck, focus moves to new pop-ups, landmarks are used, off-screen content is hidden from screen readers, and custom controls have labels and roles. They never change the score.

• Uses HTTPS, and sends HTTP visitors to HTTPS: Shopify does both for you.
• Doesn't ask for location or notification permission on load: pop-ups asking to "show notifications" the moment someone arrives cost points. Usually a push-notification app.
• Content Security Policy, HSTS, origin isolation (COOP), clickjacking protection and Trusted Types: technical security settings sent by the server. They're information only and don't change the score. On Shopify they're set by Shopify, not you.

• Allows pasting into input fields: blocking paste annoys people and breaks password managers.
• Displays images with the correct aspect ratio: images aren't squashed or stretched.
• Serves images with appropriate resolution: images aren't blurry on sharp phone screens.

• Page has the HTML doctype, and properly defines charset: the first lines of the page that tell the browser how to read it. Every Shopify theme has them.
• Baseline features: a list of web features the page uses and whether all current browsers support them. Information only.

• No browser errors logged to the console: no scripts failing behind the scenes. On Shopify, usually an app or an old tracking code.
• No issues in the Issues panel: Chrome's own list of problems, often cookie or security warnings from outside scripts.
• Avoids deprecated APIs: no browser features that are being removed.
• Avoids third-party cookies: cookies set by other companies' scripts, which browsers increasingly block. Ad and tracking pixels are the usual cause.
• Detected JavaScript libraries, and valid source maps: a list of code libraries found, and developer debugging files. Information only.

• Page isn't blocked from indexing: nothing tells Google to leave the page out of search. Fails if a page is set to "noindex", or if your store is password-protected.
• Page has a successful HTTP status code: the page loads normally, not as an error.
• Links are crawlable: links are real links Google can follow, not buttons that only work with a script.
• robots.txt is valid: the file that tells search engines what they may visit is written correctly. Shopify makes this for you.

• Document has a title, and a meta description: the page name and the short summary Google may show in results. Set them in Shopify under each page's "Search engine listing".
• Links have descriptive text: "Shop all skates" rather than "click here" or "learn more".
• Image elements have alt text: the same check as in Accessibility; it also helps Google Images.
• Valid hreflang: if you have versions for other languages or countries, they're marked correctly.
• Valid canonical: the page names its main address, so Google doesn't treat copies (with filters or tracking tags) as separate pages.

Structured data is hidden code that tells Google "this is a product, this is its price, these are its reviews", which can show stars and prices in search results. PageSpeed doesn't test it; it reminds you to check it in Google's Rich Results Test.

• Accessibility tree is well-formed: the page's structure makes sense to software reading it, the same thing screen readers rely on. Good accessibility helps here.
• Cumulative Layout Shift: the page doesn't jump around, so an AI assistant clicking a button doesn't hit the wrong one.
• llms.txt follows recommendations: if your store has an /llms.txt file (a short summary of the site written for AI tools), it's in the expected format. Many Shopify stores already have one.
• WebMCP schemas are valid: WebMCP is a new way for a page to tell AI assistants what actions it offers, like "search products". If your page declares any, they must be written correctly.
• WebMCP tools registered, and WebMCP form coverage: information only. Lists any actions the page offers to AI assistants, and forms (like the cart or newsletter) that could be marked up for them.
• ARD manifest is valid: checks an optional file that lists a site's resources for AI agents. Usually "not applicable".

None of this affects your Google ranking today. Google labels it as still in development.

The date and time of the run, in your time zone. Compare runs by this, and remember real-visitor data at the top covers the 28 days before it.

The test pretends to be a mid-range Android phone (a Motorola Moto G Power, with a screen 412 pixels wide). Lighthouse is the name of Google's testing tool, and 13.6.0 its version. Scores from different versions aren't always comparable. The Desktop tab at the top runs the same test as a laptop on a fast connection, which almost always scores higher.

The test opens one page, fresh, with nothing saved from earlier visits. Real shoppers usually browse several pages and their phone keeps files from the first one, so later pages load faster for them than the test shows.

The test only measures the page loading, not scrolling, tapping or shopping. That's why tap speed in the test is estimated (Total Blocking Time) rather than measured.

The test acts as if the phone were on a weak mobile connection: about 1.6 megabits a second, with a 150 millisecond delay on every request, and a phone processor about four times slower than the test computer. Google doesn't actually slow the connection down; it loads the page fast and calculates what a slow phone would have seen. Most Singapore shoppers on 5G or Wi-Fi get much faster pages than this.

The browser used: Chrome running on Google's test servers, with no screen attached ("headless"). "lr" is the name of Google's own testing service. Running the same tool on your own computer gives different numbers, because the computer and connection are different.