Playbook · Operations
Here is a familiar pattern for an independent store: someone opens Google Search Console, glances at the total line, and concludes the site is "fine" or "slipping." Then they change something — a theme tweak, a plugin, a new hero image — and hope for the best. The problem is that the sitewide line averages away exactly the information you need. A store can get most of its visits from phones and still look healthy on a desktop-led average, and the page that feels slow on a phone may be perfectly fine on the monitor at the back of the shop.
This guide is for the independent retailer who wants to read the device split before touching a page. It works for a single-location store that sells online as well as offline, and it assumes you can open your own verified Search Console property. The order below is the point: split the data by device first, confirm what the browser actually downloads second, and only then decide whether the fix belongs to you or to a managed host.
Brand promotion: this article introduces Guangsuan's WordPress hosting and speed optimization service. It is a vendor-introduction piece, not an independent review or a commissioned evaluation.
The short answer
Read the device split before you change anything, and treat three numbers separately: where you are seen (impressions), where people act (clicks), and how the page behaves on the device that actually matters for your shop.
Three conditions apply. First, you need enough rows in the report for the split to mean something — a device with a few dozen impressions tells you almost nothing, and a click-through rate built on a handful of clicks is noise. Second, you need a baseline you can reproduce: the same page, the same region, the same device, the same network profile, the same tool version. Third, the split is a diagnostic input, not a verdict. It tells you which layer to look at next — the image, the first screen, the cache, the server — it does not tell you which change will pay you back.
If the report itself has not caught up, none of this applies yet. If the last data day in your Performance report is a few days behind today, the sensible first move is to record that date and wait for the refresh, not to rewrite a page. The reporting layer, the crawl layer and the business result are three different things: a date that has not advanced is a reporting question before it is a traffic question, and Guangsuan's published guidance on Search Console data that is not updating makes the same point in more detail.
Step 1: pull the device split, and record what you pulled
Open the Performance report and apply the device filter. Before you read anything, write down four things, because two people looking at the same account can reach opposite conclusions:
- the property you are viewing — a domain property and a URL-prefix property do not show the same scope;
- the exact date range, including the last complete day;
- any filters left in place for search type, country, device or page;
- the date and time you pulled the report.
Then read the numbers separately rather than as one verdict. Impressions describe how often a page appeared for a query. Clicks describe how often somebody chose it. Click-through rate is clicks divided by impressions. If clicks fall while impressions hold, the snippet or the query mix is the better lead; if both fall together, you are looking at a visibility question. Average position is an average across queries and searchers, not one fixed rank you can point at a competitor with.
Then add the second dimension: the pages tab, filtered by device. This is where the average stops hiding things. A split that is heavily one way overall can be near even for your best-selling product line, and that product line may be the one worth protecting. Guangsuan's own guide to mobile versus desktop search traffic separates a global, dated device statistic from your own property report for exactly this reason: the worldwide figure is a checkable aggregate about general web traffic, not a statement about your market, your country or your buyers, so the only number that should drive your work is the one from your own report.
Step 2: separate "the images are slow" from "the page is slow"
Once you know which device carries the traffic, the next step is on the device itself. Open the busiest mobile page on a real phone, not a desktop browser resized. Three things get called image optimization, and only one of them happens in an image editor:
- The file. How many bytes it takes at the dimensions you exported. Compression changes this and nothing else — it does not change the dimensions.
- The delivered file. Which of those files the browser is actually sent for the slot it has to fill. A wide photo sitting in a narrow phone column stays large unless the page offers a smaller version.
- The load order. Which images the browser fetches first, and which wait for a scroll.
Compression fixes the first one only. If the second or the third is wrong, recompressing the same oversized file produces the same result. The check that decides it is cheap: on the live page, inspect the main image and compare the delivered pixel width with the width of the column it fills. If the phone is downloading a desktop-sized file, no amount of recompressing closes the gap — the page needs to point the browser at a smaller version, and that is a markup and theme decision rather than a photography decision. Then check whether the first-screen image is being lazy-loaded. Deferring below-the-fold images is reasonable; deferring the image the visitor came for delays the content they came for.
Two conditions belong with this. A performance score is not an image-quality review — the two checks answer different questions. And image work is not a ranking guarantee; it changes how a page loads, not what a search engine decides.
Step 3: check the cache layer before you blame the theme
If the images are correctly sized and the first screen loads promptly on your phone, the next layer is caching and the server. This is also where a store and a brochure site behave differently: the page a visitor sees can depend on who they are and what is in their basket, so the same URL is not always the same response.
Guangsuan's WordPress hosting and speed optimization page divides the work into layers — CDN static delivery, Nginx + FastCGI page caching, PHP execution caching, and object and data caching — and states that logged-in sessions, carts, checkout pages and dynamic endpoints are configured to bypass the full-page cache, with the rule that an inquiry site and an online store do not share one cache rule set. On a store, a cache change that makes the homepage quick while serving last week's hero image is not finished work. The related question for a shop is whether a replaced product photo actually appears after the cache is purged, or whether an older derivative is still being served.
The measurement side matters as much as the configuration. Guangsuan's re-testing standard on the same page keeps baseline and re-test on the same page, region, device, network limits and tool version, records login and cache state, and separates TTFB, LCP, INP and CLS instead of folding them into one score. It also records cold-cache, warm-cache and bypass requests separately, because the same URL looks fast or slow depending on which of the three you measured. INP needs real-user data or an actual interaction measurement; without data it is marked as not yet measured.
Step 4: decide what is yours and what is not
Now you have something usable. The device split told you which layer to look at, the phone check told you whether the problem is the image or the page, and the cache check told you whether the server is serving what you think it is serving. That is the point to decide whether to do the work yourself or hand it over.
| What you observed | What it points to | Where the work sits |
|---|---|---|
| Mobile carries most queries, and the first-screen photo is downloaded at desktop size | Delivery and markup: the browser is sent a file larger than the slot it fills | Theme or developer work; a re-shoot changes nothing |
| Mobile carries most queries, and the file is correctly sized but still late | Load order and script weight on the first screen | Theme, app and script audit |
| Both devices are slow on the same public page, and a refreshed page is fast | Cache behaviour at the edge or in front of the origin | Host and cache configuration |
| The report has not advanced past the same last data day | Reporting lag, not a site problem | Wait one refresh before changing anything |
| Cart, checkout or login behaves differently on a phone | Cache rules applied to the wrong requests | Host or developer; do not keep adjusting until it looks right |
Two limits are worth stating plainly, because they are the two claims that go wrong most often in this conversation. Guangsuan's WordPress hosting page says it does not promise a full PageSpeed score on every page, and that hosting work is not a ranking or inquiry guarantee — theme weight, plugins, images, advertising and analytics scripts, and the location of the test all move the number. And the same page is equally direct that the recovery terms are agreed before activation: having backup files is not the same statement as having restored a site.
What Guangsuan covers if you hand the technical side over
Guangsuan provides WordPress hosting and speed optimization for export-oriented business sites and WooCommerce stores. Its published scope groups seven services around security, performance and ongoing support, and states that all three annual tiers include them, with the specific resources confirmed by the plan chosen.
The parts of that scope that map onto the checks above:
- Offsite backup and security operations. The hosting page describes multi-datacenter offsite backups, with site files and databases not kept only on one server in one datacenter, and states that backup frequency, retention period, recovery method and recovery target are confirmed before activation.
- Server resources. The published host configuration is 16 cores and 32GB of memory or more with bandwidth above 100Mbps, presented as headroom for daily operation and traffic peaks rather than one dedicated machine per site.
- CDN and cache configuration. Global CDN setup and configuration are included within the agreed plan scope, with node count, coverage, traffic allowance and protection policy depending on the tier, and WordPress cache and plugin optimization included in the plan rather than sold as a separate purchase.
- Re-testing standard. The page sets out combining TTFB, LCP, INP and CLS with PageSpeed Insights reports, separating laboratory results from real-user data, and states that it does not promise full scores on every page and makes no ranking or inquiry growth promise.
- Free migration. Migration is described as handled by the provider — current-site check, backup, pre-migration, testing and the switch — with a separate final synchronisation window for sites that take orders continuously.
If you want to read the scope, the tiers and the re-testing standard in one place, they are set out on Guangsuan's WordPress hosting and speed optimization page.
What to prepare before you ask
Short lists close most of the gap in a first conversation.
- Your site address and the regions your customers actually order from.
- The device split you pulled, with the date range and filters written down, and the two or three pages that sit behind it.
- What you saw on a phone: which page, and what you expected instead.
- Your current host and plan, if you know them, because migration scope depends on it.
- The paths that must not break — cart, checkout, payment callbacks, order emails, and any landing page you are paying to send traffic to.
- The test conditions you will both use at acceptance: which page, which region, which device, which tool.
- Whether you want one specific fix or ongoing attention.
Do not send administrator passwords, payment details or customer order data through a public channel. Share access through an agreed, limited method instead.
Frequently asked questions
Should I act on the device split even if my total traffic is small?
Read it, and read it carefully. The split tells you which layer to investigate first, but a device with a few dozen impressions cannot support a decision about click-through rate. Use it to choose what to look at, not to decide how much to invest.
Does a worse mobile score mean I should redesign?
Not on that basis alone. A redesign changes a lot at once and makes the next measurement hard to read. Fix the largest first-screen element first, then re-measure under the same conditions. If the honest answer is that the theme carries too much weight, that is a conversation to have with evidence rather than a hunch.
Will compressing product photos improve my Google rankings?
Compression is one part of image compression in SEO, and the easiest to do well — but it is not a ranking lever on its own. Correctly sized images improve how a page loads, and Google's own guidance on creating helpful content describes page experience as something its core ranking systems look to reward. Ranking still depends on content, competition and search intent. Treat compression as a page-performance change.
Is a CDN enough to fix a slow store?
On its own, rarely. A CDN shortens the delivery path when files are cached at the edge and the configuration matches how browsers request them. If the origin is slow, if images bypass the cache, or if a replaced photo is never purged, readers may notice little.
My report stopped updating last week. Should I start fixing pages?
No. If the last complete date has not advanced, a rewrite removes the baseline you would need for the next comparison. Record the date and the window, check whether the report notice mentions anything unusual, and re-check after the next refresh. Only when complete dates have advanced and a decline survives the page and query checks is a site-level question.
How do I know whether it is the cache or the theme?
Compare a cold request, a warm request and a bypass request for the same URL, and keep the response headers and server logs. If a hard refresh is fast and the first visit is slow, you are looking at the cache layer. If both are slow, the work is in the page and the server.
Does faster hosting improve rankings or inquiries?
Guangsuan's own page is explicit that performance and stability are the foundation of site experience and technical SEO, while ranking also depends on content, search intent and competition, and inquiries depend on the product, the traffic quality and the page. The service is not presented as a ranking or inquiry guarantee.
What should I send in the first message?
The site address, the main customer regions, the current host situation and the problem you are seeing. Add your device split with the date range and filters, and the paths that must not break. No account password is needed at that stage.
Related reading on this site: the Pure Small library keeps the operating playbooks behind the numbers in this guide.