What slows a site down.

The page redirects in a loop

What it means. A redirect is your server saying "this page has moved, go here instead". In a loop, one address sends the browser to another that sends it back (or round a longer circle), so it never reaches a page.

Why it matters. Visitors see a "too many redirects" error instead of your site, and Google can't reach it either. While the loop lasts, the page is effectively down.

How to fix it. Start with whatever changed most recently. Loops usually come from two settings that disagree, each "correcting" the other:

• http and https: for example, Cloudflare's Flexible mode talks to your host over http while the host sends every http request to https. If your host has its own certificate, Cloudflare's Full or Full (strict) mode usually ends it.
• www and no www: the address set one way in WordPress (Settings, General) and the other way at your host or domain registrar.
• Two redirect rules or plugins pointing at each other.

Then clear any caches and test in a private window, because browsers remember permanent redirects.

How the check spots it: the check follows each redirect itself, one step at a time, starting from the address you entered. If it's sent back to an address it has already asked for, with the same cookies, that's a loop: it's listed as Fix first and the check stops there. A site that sets a cookie and sends you back to the same page once isn't counted. A long chain that never repeats is covered in several redirects.

The page isn't set up for phones

What it means. The viewport tag is one line in the page's <head> (the hidden top part of its code) that tells a phone how wide to draw the page. Without it, phones draw the page at desktop width and shrink it to fit.

Why it matters. Visitors get tiny text and buttons they have to pinch and zoom to use, and many give up. Google uses the phone version of your pages for indexing and ranking (it calls this mobile-first indexing), so what phone visitors struggle with is what Google judges.

How to fix it. Add <meta name="viewport" content="width=device-width, initial-scale=1"> inside the <head>. It tells the phone to use its own screen width at normal zoom. Then look at the page on a phone: a design never built for small screens may need more work than the tag alone.

• WordPress: almost every current theme includes the tag, so if it's missing, the theme is very old or a customised header has dropped it.
• Wix, Squarespace and Shopify usually add it for you. If it's missing there, look at custom header code or an older theme.

How the check spots it: the check reads the page's HTML for a <meta name="viewport"> tag with a content attribute. If there isn't one, it's listed as Fix first. Google's PageSpeed Insights test checks for the same tag, and the report shows both under this heading. A tag set to a fixed width is covered in fixed width.

The page tells phones it's a fixed number of pixels wide

What it means. The page has a viewport tag (see not set up for phones), but it sets a width in pixels, such as width=1024, instead of width=device-width. Phones then draw the page that wide and shrink it to fit.

Why it matters. The effect is much like having no tag at all: the page appears zoomed out, the text is too small to read, and people pinch and scroll sideways to use it. It's usually left over from a site designed for desktops.

How to fix it. Change the tag to <meta name="viewport" content="width=device-width, initial-scale=1">, then check the page on a phone. If the layout itself was built at a fixed width, content may spill off the screen, and the design needs to become responsive (able to rearrange itself for small screens). The tag usually lives in the theme's header template, so ask whoever looks after your theme if you're not sure where.

How the check spots it: the check reads the page's viewport tag and reports it when it includes width= followed by a number of three or more digits, such as 980 or 1200. It's listed as Worth fixing.

The server is slow to send the page

What it means. When someone opens your page, their browser asks your server (the computer hosting your site) for it and waits for the reply to start, a delay often called time to first byte. Nothing else can load until then.

Why it matters. The delay is added to every visit, on every page. Common causes are crowded budget hosting, a site that builds each page from scratch for every visitor, a slow plugin, and a server far from your visitors. Google suggests aiming for under about 0.8 seconds.

How to fix it.

• Turn on page caching, so the server keeps ready-made copies of your pages. In WordPress, that's a caching plugin or your host's caching setting.
• If it's still slow, switch plugins off one at a time on a copy of the site to find the culprit.
• Ask your host where your server is. A server in Australia, or a content delivery network (CDN) such as Cloudflare, brings the site closer to local visitors.
• On Wix, Squarespace and Shopify, hosting is the platform's job. If this keeps appearing, raise it with their support.

How the check spots it: the check times its own request for the page, after any redirects, from the Cloudflare data centre that ran your check (usually the one nearest you). It measures from sending the request to the first reply, setting up the connection included. Over 1 second is Worth fixing, over 2 seconds is Fix first, and 1 second or less is a pass. It's one measurement, so run the check again to confirm. Google's PageSpeed Insights test also times the server, and reports a slow response under this heading.

Images are bigger than they need to be

What it means. Google's test found pictures that could be much smaller files without looking any different on screen. Usually they aren't compressed, they're in an older format such as JPEG or PNG where WebP or AVIF would be smaller, or they're far wider than the space they fill.

Why it matters. Images are often the heaviest part of a page. On a phone with patchy signal, oversized pictures can be the main delay before your page appears, and they use up visitors' mobile data.

How to fix it.

• Resize photos before uploading, so they're not much wider than the space they fill on a large screen.
• Compress them, and use WebP or AVIF where your platform allows.
• Offer several sizes with the srcset attribute, so phones get a smaller copy. WordPress does this for uploads, and image optimisation plugins can compress and convert images already on the site.
• Shopify, Squarespace and Wix usually resize images for you. If some are still listed, they're often added by an app or custom code.

How the check spots it: this comes from Google's PageSpeed Insights test of the page, on a phone unless you chose Desktop. Google's checks for compression, image formats and sizing report under this heading whenever Google scores the page under 90 out of 100 on one of them. It's ranked by the time Google estimates you'd save: a second or more is Fix first, 0.3 seconds or more is Worth fixing, and less is Nice to have. If every image named comes from another company, the report says so, and drops the finding when there's no time to gain and less than 20 KiB to save.

Files hold up the first paint of the page

What it means. Before a browser shows anything (the "first paint"), it has to fetch every stylesheet and ordinary script listed in the page's <head>, the hidden top part of its code. Files that hold the page up like this are called render-blocking.

Why it matters. Each is another download before your content appears, so a phone shows a blank screen for longer. Themes, page builders and plugins often each add their own.

How to fix it.

• Remove plugins and theme features you don't use; each often brings its own files.
• Add defer to scripts that don't need to run before the page appears, or move them to the end of the page.
• Combine small stylesheets, and put the few styles the first screen needs straight into the page.
• In WordPress, many optimisation plugins can do this; on hosted platforms, the apps and custom code you've added are the part you can change. Test afterwards, since deferring the wrong script can break a menu or form.

How the check spots it: the check reads the page's HTML and counts the stylesheets linked in the <head> with no media setting, or one that's all, screen or starts with screen (a print stylesheet isn't counted) and the scripts there that load a file without async, defer or type="module". It reports four or more files in all, or two or more such scripts: eight or more is Worth fixing, fewer is Nice to have. Google's PageSpeed Insights test, which measures what actually held the page up, reports under this heading when Google scores the page under 90 out of 100 on it. Google's version is rated by the time it estimates you'd save, so it can be Fix first, and the report keeps whichever rating is higher. See also unused styles.

Things move around while the page loads

What it means. Google's test saw content jump while the page loaded: text or buttons moving as something appeared near them. This is called layout shift. Common causes are images and embeds with no space saved for them, banners or cookie notices that push the page down, ads, and web fonts a different size from the font shown first.

Why it matters. People reach for a button, it moves, and they tap the wrong thing. Layout shift is one of Google's Core Web Vitals, the measurements Google uses to sum up how a page feels to use, and Google counts a layout shift score of 0.1 or less as good.

How to fix it.

• Give every image and video a width and height (see no width and height set).
• Reserve space for things that arrive later, such as ads, embeds and review widgets.
• Show banners and cookie notices over the page, fixed to the top or bottom of the screen, rather than above the content.
• If text jumps when a web font arrives, ask your developer for a fallback font closer to it in size.

How the check spots it: this comes from Google's PageSpeed Insights test of the page, on a phone unless you chose Desktop. Google records how far things moved, and the report lists it when Google scores the page under 90 out of 100 on it. An estimated improvement of 0.1 or more in the layout shift score makes it Fix first, and 0.05 or more Worth fixing. Where Google names what moved, the report shows it as examples.

The page loads more JavaScript than it needs

What it means. JavaScript is the code behind menus, sliders, forms, chat windows and tracking. Google's test found scripts that are bigger or slower than they need to be: code the page never uses, code for very old browsers, a library loaded twice, or files that aren't minified (stripped of the spaces and comments only people need).

Why it matters. A phone has to download the code and then run it, and running it is often the slow part. While a script runs, the page can look ready but not respond to taps.

How to fix it. The biggest wins usually come from removing things, not tuning them.

• List the plugins, apps, widgets and tracking codes on the site, and remove any you can't name a reason for.
• Load scripts only on the pages that need them, such as a booking widget on the booking page. Many WordPress optimisation plugins can do this.
• On Shopify, uninstalling an app doesn't always remove its code from your theme, so check the theme or ask the app's developer.

How the check spots it: this comes from Google's PageSpeed Insights test of the page, on a phone unless you chose Desktop. Google's checks for unused, old, duplicated and unminified scripts, and for time spent running them, report under this heading when Google scores the page under 90 out of 100 on one of them, ranked by the time Google estimates you'd save. If every script named comes from another company, the report says so, and drops the finding when there's no time to gain and less than 20 KiB to save. See also scripts from other companies.

Scripts and embeds from other companies slow the page

What it means. Many pages load code from other companies' servers: analytics and advertising tags, chat widgets, booking and review tools, social media buttons, videos and maps. These are called third parties.

Why it matters. For each new company, a phone has to find its server and open a fresh secure connection before downloading and running the code. That code runs on your page with full access to it, and its owner can change it at any time.

How to fix it.

• For each service the report names, ask what it does for your business, and remove the ones nobody uses.
• Load the rest only where they're needed: the map on the contact page, not every page.
• If you use a tag manager, review the tags inside it too.
• Host fonts on your own site (see fonts from Google's servers) and lazy-load videos and maps (see embeds that load straight away).

How the check spots it: the check reads the page's HTML and counts the different outside addresses its scripts and embedded frames load from (one that differs from your page's address only by www. counts as yours, but your own subdomains, such as shop.yoursite.com.au, count as other addresses). Four or more is Nice to have; eight or more is Worth fixing. Scripts added later by other scripts aren't seen here, but Google's PageSpeed Insights test sees them, and reports under this heading when Google scores the page under 90 out of 100 on other companies' code. Google's version is rated by the time it estimates you'd save, so it can be Fix first, and the report keeps whichever rating is higher.

It takes several redirects to reach the page

What it means. A redirect sends the browser from one address to another. One is normal, such as smith.com.au to www.smith.com.au. A chain is two or more in a row, such as smith.com.au to www.smith.com.au to www.smith.com.au/home/.

Why it matters. Each hop is another request and answer before the page starts loading, and on phones the waits add up. Chains grow as a site moves to https, changes its main address or is rebuilt. Browsers give up after a long enough chain.

How to fix it. Send every old address straight to the final one in a single step. Redirects can be set at your host, in an .htaccess file, in a WordPress plugin, in Cloudflare's rules and at your domain registrar, and two of these often each add a hop. Then update the links you control (your own site, your Google Business Profile, social media) to use the final address.

How the check spots it: the check follows the redirects itself, starting from the address you entered, and shows the whole chain. One redirect is a pass, two or more is Worth fixing, and more than six is Fix first, at which point the check stops following them. An address that leads back to itself is covered in redirects in a loop. Google's PageSpeed Insights test can report redirects under this heading too.

The first picture on the page is set to lazy-load

What it means. Lazy-loading, set with loading="lazy" on an image, tells the browser to wait until the image is about to scroll into view. That helps further down the page (see images out of sight), but here it's on the main picture at the top, usually the hero photo or banner.

Why it matters. The browser puts off the most important picture on the first screen, then fetches it late. Google measures how long the biggest thing on the first screen takes to appear (Largest Contentful Paint, one of its Core Web Vitals), and this makes it slower.

How to fix it. Remove loading="lazy" from that image and keep it on pictures lower down; your developer can also add fetchpriority="high" so it's fetched first. Themes, page builders, sliders and lazy-loading plugins often add it to every image, and many have a setting to skip the first ones.

How the check spots it: at first this is a potential issue, a guess from the HTML. The check takes the first image that looks like a main picture (not an SVG, an embedded image, a likely logo or icon, or one set narrower than 300 pixels or shorter than 200) and lists it as Nice to have if it has loading="lazy". Google's PageSpeed Insights test measures what's really biggest on screen. If its check of the main image finds it isn't lazy-loaded, or the biggest thing isn't an image at all, the guess is dropped. If it is lazy-loaded, Google reports it in its own words, as the main image being found late.

Files aren't kept for repeat visits

What it means. A browser can keep copies of your images, stylesheets, scripts and fonts so it needn't download them next time. This is caching. Your server sets how long copies may be kept with a header (a note sent with each file) called Cache-Control, and Google's test found files on your site with no lifetime or a short one.

Why it matters. Returning visitors, and anyone moving between pages, download the same files again, so later pages are slower and use more mobile data.

How to fix it.

• Set long cache lifetimes for images, fonts, stylesheets and scripts. Pages themselves usually need short ones, so updates show straight away.
• When a cached file changes, its address must change too, or visitors keep the old copy. WordPress adds ?ver= to many files for this reason.
• In WordPress, caching plugins and many hosts can set this for you. On Apache servers it's often in the .htaccess file, and in Cloudflare the Browser Cache TTL setting controls it.

How the check spots it: this comes from Google's PageSpeed Insights test of the page, on a phone unless you chose Desktop, when Google scores the page under 90 out of 100 on caching; it's ranked by the time Google estimates you'd save. Only files on your own domain (subdomains included, and addresses Google counts as your site's) are counted, since other companies' settings aren't yours to change, and if none are yours, nothing is reported.

The page itself isn't compressed

What it means. Servers can squeeze text files before sending them, and browsers unpack them on arrival, using gzip or Brotli. The page's HTML, its own code, shrinks a lot this way, but Google's test found your server sending it uncompressed.

Why it matters. The HTML is the first thing a browser needs, and everything else waits on it. Uncompressed, it takes longer to arrive, especially on a slow mobile connection.

How to fix it. Compression is on by default on most hosting, so if it's off, something has usually switched it off or is getting in the way.

• Look for a compression setting in your hosting control panel, or ask your host to turn it on.
• On Apache or Nginx servers, it's a module your host or developer can enable.
• Cloudflare compresses pages for browsers that ask for it. If your site uses Cloudflare and this still appears, check whether a rule is turning compression off.

How the check spots it: this comes from Google's PageSpeed Insights test of the page, on a phone unless you chose Desktop. It's one item on Google's checklist for the request that fetches the page, so it covers the HTML only; uncompressed stylesheets and scripts are reported separately. If the uncompressed HTML is 50 KiB or more it's Worth fixing; smaller pages are Nice to have.

Images have no width and height set

What it means. An image's width and height attributes tell the browser its shape before the file arrives, so it can save the right amount of room. Without them, the page is laid out with no space for the picture, and everything is pushed down when it loads.

Why it matters. That jump is layout shift (see things move around): people lose their place or tap the wrong thing, and Google measures it as one of its Core Web Vitals.

How to fix it. Add width and height to each <img> tag, matching the image's size in pixels, or at least its shape. The stylesheet can still show it bigger or smaller. WordPress adds them to images inserted from its media library, so missing sizes there usually come from a theme, page builder or custom HTML.

How the check spots it: this is a potential issue, a guess from the HTML. It's reported when the page has at least three images, all ordinary picture files rather than SVGs or embedded images, and not one has a width and height set in its attributes or its own style. The stylesheet may size them, which the HTML doesn't show, so Google's PageSpeed Insights test settles it where it can: if its layout-shift check finds nothing moving as the page loads (or, in older versions of the test, no images without a set size), the guess is dropped. Shifts it does find are reported under things moving around while the page loads.

All the images load straight away, including the ones out of sight

What it means. By default, a browser downloads every image as soon as the page opens, including ones at the bottom that nobody may scroll to. Lazy-loading, set with loading="lazy" on an image, tells it to wait until the image is nearly in view.

Why it matters. Pictures further down compete with the top of the page for the phone's connection, so the first screen fills in more slowly, and visitors download pictures they never see.

How to fix it. Add loading="lazy" to images below the first screen, but not to the main picture at the top (see first picture set to lazy-load). WordPress adds it to most images automatically, so if it's missing there, a theme, page builder or plugin may be removing it or loading images its own way. On hosted platforms, it's usually up to the theme.

How the check spots it: the check reads the page's HTML and lists this as Nice to have when there are eight or more images and none has loading="lazy". Only that attribute counts, so a theme that lazy-loads with its own script can show up here. Google's PageSpeed Insights test, which watches what actually loads, can report off-screen images under this heading too.

Embedded videos or maps load straight away

What it means. An embed shows something from another site on your page, such as a YouTube video, a Google Map or an Instagram post. Each one is an <iframe>, a small web page inside yours, and by default it loads in full as soon as your page opens.

Why it matters. A single video or map pulls in a lot of files and code from another company, whether or not anyone scrolls down to it or presses play (see scripts from other companies).

How to fix it.

• Add loading="lazy" to the embed's <iframe> tag, unless it's at the very top of the page. You can add it to most embed codes before pasting them in.
• For videos, a "click to load" version (a picture that swaps in the player when tapped) saves even more. Many themes and plugins offer one.
• For maps, consider a picture of the map linked to Google Maps, or keep the live map on your contact page only.

How the check spots it: the check reads the page's HTML for embedded frames from YouTube, Vimeo, Google (Maps included), Facebook, Instagram, Spotify and SoundCloud that don't have loading="lazy". One or more is listed as Nice to have. Embeds added later by a script aren't seen.

Text is invisible while fonts load

What it means. Web fonts are typefaces downloaded with the page. Browsers may hide text set in one until the font file arrives, so visitors briefly see headings and buttons with no words. The CSS setting font-display: swap shows the text straight away in a standard font, then switches when the web font is ready.

Why it matters. On a slow connection the gap can be long enough that people see empty boxes, or leave. Your words needn't wait for a typeface.

How to fix it.

• Add font-display: swap to each @font-face rule in the site's stylesheet.
• For Google Fonts, current embed codes include display=swap. For an older one, add &display=swap to the end of its address.
• In WordPress, check the theme's or page builder's font settings. On hosted platforms, start with fonts added through custom code or apps.

How the check spots it: this comes from Google's PageSpeed Insights test of the page, on a phone unless you chose Desktop. It's listed when Google scores the page under 90 out of 100 on how its fonts show text while loading, and ranked by the time Google estimates you'd save. If the font files come from another company, the report adds a note saying you can't change them, and the finding is dropped when there's no time to gain and under 20 KiB to save. For Google Fonts, though, the display=swap change is still yours to make. See also fonts from Google's servers.

Fonts load from Google's servers

What it means. Your page loads its fonts from Google Fonts rather than from your own site: first a small stylesheet from fonts.googleapis.com, then the font files from fonts.gstatic.com.

Why it matters. That's two more servers to connect to before text can appear in those fonts. Browsers no longer share stored files between websites, so a copy saved while visiting another site doesn't help yours. It also means every visitor's browser contacts Google, which some businesses prefer to avoid.

How to fix it. Google Fonts are released under open licences, so you can host them yourself. Download the WOFF2 files for the weights and styles you use, put them on your site, and load them with an @font-face rule that includes font-display: swap (see text invisible while fonts load). Then remove the old Google Fonts links, including any preconnect or dns-prefetch hints. Many WordPress themes and font plugins have a setting to host Google Fonts locally; on hosted platforms, check custom code for Google Fonts links added by hand.

How the check spots it: the check reads the page's HTML for stylesheets, scripts, and preload, preconnect or dns-prefetch links that point at fonts.googleapis.com or fonts.gstatic.com, or at Google's Web Font Loader. Any one is listed as Nice to have, so a leftover preconnect is enough on its own.

Stylesheets carry code the page doesn't use

What it means. Stylesheets (CSS files) hold the rules for how the site looks. Google's test found many rules this page never uses, or files that aren't minified (stripped of the spaces and comments only people need).

Why it matters. The browser reads every stylesheet before it shows the page (see files hold up the first paint), so unused rules add to the wait. Themes and page builders often load styles for features you never switched on.

How to fix it.

• Remove plugins and theme features you don't use.
• In WordPress, many optimisation plugins can minify CSS, and some can remove unused rules or load a plugin's styles only where it's used. Page builders often have a similar performance setting.
• Google looked at this page only, so rules it calls unused may be needed elsewhere. Test the whole site after trimming.

How the check spots it: this comes from Google's PageSpeed Insights test of the page, on a phone unless you chose Desktop. Its checks for unused and unminified CSS report under this heading when Google scores the page under 90 out of 100 on one of them, ranked by the time Google estimates you'd save. If every stylesheet named comes from another company, the report says so, and drops the finding when there's no time to gain and less than 20 KiB to save.

The page's structure is very complex

What it means. Every heading, paragraph, image, button and box on a page is an element in its structure, which developers call the DOM. Google's test found a very large number of elements, or many layers nested inside each other.

Why it matters. The browser works out the size, position and style of every element, and redoes some of that whenever something changes, such as a menu opening. A huge structure makes a phone slower to show the page and to respond to taps.

How to fix it.

• Page builders are the usual cause, wrapping each section, column and widget in layers of boxes. Rebuilding heavy sections with fewer, simpler blocks helps.
• Hidden content counts too: menus built twice (once for desktops, once for phones), sliders with many slides, and tabs.
• Pages that show everything at once, such as every product or every review, can be shortened or split up.

How the check spots it: this comes from Google's PageSpeed Insights test of the page, on a phone unless you chose Desktop. Google counts the page's elements and how deeply they're nested, and the report lists it when Google scores the page under 90 out of 100 on that, ranked by the time Google estimates you'd save.

The page's HTML is very large

What it means. The HTML is the page's own code: its text, its structure and the instructions for loading everything else. Separate image, stylesheet and script files don't count towards it. Most pages' HTML is under 100 KB; this page's is several times that.

Why it matters. The browser needs the HTML before anything else, and a very large one takes longer to download and read, especially on a phone. It usually means something is inside the page that belongs elsewhere.

How to fix it. Your developer can view the page's source and see what's taking up the space. Common culprits:

• Images written in as text (see images embedded as text).
• Page builder markup (see very complex structure).
• Data, styles or scripts that a theme or plugin writes into the page.
• Every product, post or review on one long page.

How the check spots it: the check downloads the page's HTML, unpacked, and measures it, so turning on compression won't change the result. More than 500,000 bytes (about 500 KB) is Nice to have. Over 1 MB it's Worth fixing, and only the first 1 MB is checked.

Images are embedded in the HTML as text

What it means. Normally an image is a separate file the page links to. It can also be written into the page's code as a long string of text, called a data URI, which starts with data:image/. Tiny icons are sometimes done this way on purpose, but this page carries a lot of picture data in its HTML.

Why it matters. These pictures can't be stored by the browser on their own, so every visit downloads them again, and they arrive as part of the HTML, before the page can show. The text form is also about a third bigger than the original file.

How to fix it. Common causes are images pasted into an editor rather than uploaded, and page builders or plugins that embed images to save a download. Save each image as a file, preferably WebP or AVIF, upload it and link to it instead. The tiny placeholders some lazy-loading tools use are fine to leave.

How the check spots it: the check adds up the length of every <img> address in the HTML that's a data: URI. More than 30,000 characters in all (roughly 30 KB) is listed as Nice to have. Images embedded in stylesheets aren't counted.

The site doesn't offer HTTP/3

What it means. HTTP is how browsers and servers talk to each other, and HTTP/3 is its newest version. It connects in fewer steps and copes better with patchy phone signal or a switch between Wi-Fi and mobile data. Browsers use it only when a site offers it, and otherwise fall back to HTTP/2 or HTTP/1.1.

Why it matters. It's a modest gain, mostly for visitors on mobile, and not a fault: your site works the same without it.

How to fix it. It's a setting on your server or the service in front of it, not a change to the site.

• On Cloudflare, HTTP/3 is a switch in its settings.
• Many hosts and content delivery networks (CDNs) offer it; ask yours.
• On Shopify, Squarespace and Wix, it's up to the platform.

How the check spots it: browsers learn about HTTP/3 from an Alt-Svc header sent with the page, or from an HTTPS record in the domain's DNS, so the check looks for both. If either offers h3, it's a pass; if neither does, it's listed as Nice to have. If the page ended up on a different host from the one you entered, or DNS didn't answer, only the header counts, and there's no verdict without it. Only pages served over https are checked.