mobile-checker

Mobile Checker

Scores how well your booking page works on a phone, out of 100, with the same fixed rubric every time, and hands back a fix list ranked by the points each fix wins back. No installs and no code: you give the page link, some phone screenshots, and the numbers from Google's free PageSpeed Insights tool. Use it before you send ads or emails to a page, after a redesign, or when booked calls drop and most of your visitors are on phones. It fits any page that ends in a booked call: a landing page, a video sales letter (VSL) page, an application page, or your main site's homepage. A page hosted by your calendar tool is not scored on its own; it is checked as the booking path of the page that links to it.

Before you start

1. Look for a Business Context file in this project or chat. If it exists, read it first and pull: the booking page link, the offer the page sells, what the main button should say, the calendar or booking tool, the page builder, who edits the page (you or a developer), where visitors come from (ads, Instagram, LinkedIn, email), and the share of visitors on mobile if known.
2. If you already have the link and web search or web fetch is on, open the page yourself before asking anything (Step 3). Then you know whether you still need the page source.
3. Ask only for what is still missing. Put every question in one message, each with a short reason why you need it. Never ask for more than these:
   • The live page link. So you can read the page, and so PageSpeed tests the real page, not an editor preview. If the link is a page hosted by the calendar tool, ask for the page that sends people to it. If there is none, see "Hosted calendar pages" in Step 6.
   • The phone model used for the screenshots. Screen width changes how text wraps and how big a button really is.
   • The main action. Which button counts as "book", if the page has more than one.
   • Phone screenshots. Normal screenshots, not one tall capture. If one message won't take them all, send the page in the first message and the rest in a second. a. First screen: exactly as it loads, no scrolling, browser bar showing. One image. b. Whole page: scroll one screen at a time and take a normal screenshot each time, so about a fifth of each screen shows again at the top of the next. About 12 at most per message; if the page runs longer, send the rest in the next message. Optional, for reading the words only: the iPhone Safari "Full Page" PDF or the Android "Scroll capture". c. Booking path: tap the main button and screenshot every step up to the final Confirm button, about 5 at most. Stop there. Only submit if you accept that a real booking fires your ad pixels (Meta and Google count it as a lead or a scheduled call), adds a CRM contact and pipeline stage, and sets off your confirmation texts and emails, team alerts, and any setter or AI agent call. Cancelling can then start no-show or cancel sequences. If you do submit: pick a slot 2 or more weeks out, use a name or email marked TEST, tell your team first, and cancel right after. d. Popups: any popup the page opens, taken while it is open. e. In-app browser: send yourself the page link in an Instagram DM (or open it from your bio or an ad) and tap through the booking path inside the Instagram or Facebook in-app browser. Screenshot any step that looks or works differently from Safari or Chrome. Most social traffic lands here, and it is where booking pages break most often.
   • PageSpeed numbers, 2 screenshots. Search "PageSpeed Insights", paste the live link, pick Mobile, run it. Capture the lab section ("Diagnose performance issues"), not the real-user data at the top: the Performance score, LCP, CLS, TBT, the Accessibility score, and the names of the failing items under Performance, Accessibility, and Best Practices, with their "Est savings".
   • Page source, only if you could not read the page yourself. On a computer: open the page, right-click, pick View Page Source, save it, and upload it as a .txt file. Don't paste it into the chat: page-builder source can run past 1 MB. If you don't have the link yet, list this item as optional ("if I can't read your page from the link, this saves a second round").
4. Do not stall. Score what the evidence you have can prove, mark the rest Not checked, and name the one missing input that would add the most points to the check. Without PageSpeed numbers, 55 points stay unchecked, so ask for those first.

How it works

Work the steps in order. Plain words throughout: define a technical term once, the first time you use it.

Step 1. Set the phone size

The rubric is built for a small phone: 375 by 812 CSS pixels. A CSS pixel is the unit web pages are built in; a phone screenshot has 2 to 3.5 real pixels per CSS pixel.

Phone	CSS width
iPhone SE, 12 mini, 13 mini	375
iPhone 12 and newer, standard and Pro	390 to 402
iPhone Plus, Air, and Pro Max	420 to 440
Most Android phones	360 to 412

• Scale = screenshot width in pixels divided by the CSS width (usually 3 on an iPhone). Any length in the screenshot divided by the scale gives CSS pixels.
• One screen = 812 CSS px on every phone. On a 3x iPhone that is 2436 screenshot pixels. A real screenshot shows less page than that because the browser bars take room: by eye, one screenshot is about 0.8 to 0.9 screens. Use 812 for E2, E5, and every screen count, so scores compare across phones and runs.
• Positions: stack the overlapping screenshots by matching the repeated strip, add up the new page height each one shows in CSS px from the very top of the page (just under the address bar), and divide by 812 to get screens. Label it Est. unless you measured it with code.
• Text column (C) = the width of a full line of body text, in CSS px. Measure it; if you can't, use the phone's CSS width minus 40.
• Wide phones wrap text into fewer lines than the 375 px rubric phone. When a headline or paragraph sits right at a line limit on a wide phone, count it as one line over.
• If code execution is on, open the screenshots in it to measure pixel sizes. If not, judge by eye and label the line Est.

Step 2. Read the speed numbers (sections A, B, C, and line D10)

Use the PageSpeed mobile lab numbers. Explain them in plain words:

• LCP (Largest Contentful Paint): when the biggest thing on the first screen (hero image, video poster, or headline) finishes showing.
• CLS (Cumulative Layout Shift): how much the page jumps while it loads. A jump that moves the button from under a thumb loses bookings.
• TBT (Total Blocking Time): how long the page is too busy to react to a tap. It stands in for INP, Google's measure of tap response.

PageSpeed swings a few points between runs. If a number sits within 3 points (or 0.3 s) of a scoring line, say so in the Evidence column and ask for three runs on the re-check, using the middle one. "Browser errors were logged to the console" under Best Practices means D10 fails. Always test the live page, never an editor preview: previews fail compression and caching checks the real host passes. Keep PageSpeed's "Est savings" for each failing item; they set the order of the speed work in Step 7.

Step 3. Read the page source

If web fetch or web search is on, open the page link and read the HTML. Many page builders draw the page with JavaScript, so a fetch can return mostly scripts. Then use the uploaded source if there is one; if not, lean on the screenshots and mark the HTML-only lines Not checked. If the source is over about 150 KB and code execution is on, search it for the items below instead of reading it all. If code execution is off and the file is too big to read whole, check what you can and mark the rest Not checked.

Look for these, and note the line each one feeds:

• The viewport tag: width=device-width (D1) and viewport-fit=cover (D6).
• Every img: has width and height, or a CSS aspect ratio (D5). Is the hero image a real img or a CSS background? Is it wrongly set to loading="lazy"? (speed work)
• Every iframe: loading="lazy" and a set height of 300 px or more (D5, E6). YouTube or Vimeo iframes present on load, or a thumbnail that loads the player on tap (D7).
• video tags with autoplay but no muted (D7).
• In the CSS: safe-area-inset (D6), prefers-reduced-motion and :focus-visible (D9), and the font-size of body text, paragraphs, labels, and captions (D4). External stylesheets may not come through; if you can't see the CSS, mark those lines Not checked.
• Visible form fields: count input (not hidden), select, textarea (E6).
• Competing destinations (E3): links to another offer, a different product or checkout, or a social profile, and whether the page has a navigation menu.
• Scripts in the head without async or defer. Sort them into two groups: chat widgets, heatmaps, and session recorders (these can wait), and ad pixels, conversion tags, and analytics (these load on arrival) (speed work).

To search a large file, look for: viewport, <img, <iframe, <video, <input, <select, <textarea, safe-area, prefers-reduced-motion, focus-visible, font-size, <a href, <nav, and the <script tags inside <head>.

Step 4. Read the screenshots

First check what you got. If you receive a single capture taller than 3 screens (a full-page PDF or a scroll capture), do not read positions from it. If code execution is on, cut it into screen-height tiles and look at each one. If it is off, ask for overlapping screenshots, and meanwhile mark the lines that need positions (D3, D4, E2, E4, E5, E7) Not checked. You can still read the words and button labels from it.

Walk the page from top to bottom:

• First screen (E1): find the first booking button that sits in the page itself, not in the header and not in a sticky bar. Judge it on the real first screenshot: fully visible with no scrolling passes. If it is cut off only by the browser bar but its bottom still sits within 812 CSS px of the page top, it passes too; add the Extra finding "hidden on your phone by the browser bar".
• Sideways scroll (D2): content cut off at the right edge, a horizontal scrollbar, or a page that looks zoomed out. Ask the user to try swiping sideways.
• Tap targets (D3): every link and button on the page itself, footer links included, but not the buttons inside an embedded calendar (Step 5). 44 CSS px is about one ninth of the screen width; 24 px is about one sixteenth. Text links in footers and inline "privacy" or "terms" links are the usual failures.
• Text size (D4): if the CSS gave font sizes, use them; that is exact. From screenshots only, count the characters (letters, spaces, and punctuation) in a full-width line of body text and compare with the text column C:
  • About C/8 characters or fewer: 16 px or more, pass.
  • More than about C/7.3: under 16 px, fail.
  • More than about C/6.2: near or under 12 px.
  • On a 375 phone (C about 335): 42 or fewer pass, 46 or more fail, 54 or more is near 12. From 43 to 45 is too close to call from a picture: leave that half of D4 Not checked and ask for the CSS.
  • Check small print too: labels, captions, button subtext, dates. Label every screenshot result Est.
• Headlines (E4): count the lines in the main headline (H1) and in the longest section heading (H2).
• Proof (E5): where the first logo row, testimonial, client result, or review starts, in screens from the top.
• Buttons (E2, E3): list every booking button with its position in screens and its exact wording. Note any sticky bar. Measure the biggest gap between buttons, including the gap from the last button to the end of the page.
• Exits (E3): note any menu, social icons, and links to other offers, products, or checkouts.
• Paragraphs (E7): count paragraphs that run past 6 lines, out of all paragraphs.

Step 5. Walk the booking path

From the tap-through screenshots, in Safari or Chrome first, then the in-app browser:

• Count the form fields on screen before the calendar times appear (E6). A form split into steps counts its longest step.
• Small tap targets inside the calendar (time slots, day cells, month arrows) don't score, because the page owner can't resize them. List them under Extra findings with a tool-level fix: switch on the calendar tool's mobile layout, or link to its hosted booking page instead of embedding it.
• For any popup: does it fit the screen width, does it have a clear close button, and does the page behind it stay still? Ask the user to try scrolling behind the open popup (D8).
• In-app browser: compare every step with Safari or Chrome. Common breaks: the embedded calendar loads blank, a popup or new tab is blocked, Google sign-in is refused, a redirect gets stuck. Any break goes at the top under Booking path, for example "BROKEN in Instagram in-app browser: calendar blank". It adds no points and changes no line.
• Note anything else that breaks booking even though the rubric has no line for it: the keyboard hides the submit button, the wrong time zone shows, a step never loads. A broken booking path goes at the very top of the report, above the score.
• Confirmation screen (Extra findings): if the user submitted a test booking, say whether a clear confirmation showed. If not, write "not submitted".

Step 6. Score every line

Use this rubric exactly. It adds up to 100. Label each line's source: PS (PageSpeed), HTML, Shot (screenshot), Test (tap-through), Est. (estimated from a screenshot), Not checked, or N/A.

Line	Check	Max	Scoring
A1	PageSpeed mobile Performance score	30	90 or more = 30. 50 or less = 0. Between: 30 x (score minus 50) / 40
B1	LCP 2.5 s or less	7	4.0 s or more = 0. Between: 7 x (4.0 minus LCP) / 1.5
B2	CLS 0.1 or less	4	0.25 or more = 0. Between: 4 x (0.25 minus CLS) / 0.15
B3	TBT 200 ms or less	4	600 ms or more = 0. Between: 4 x (600 minus TBT) / 400
C1	PageSpeed Accessibility score	10	Score divided by 10
D1	Viewport tag with width=device-width	2	Present = 2, else 0
D2	No sideways scroll at phone width	3	None = 3, else 0
D3	Every tap target on the page itself 44 by 44 px or larger (not inside an embedded calendar)	3	All 44+ = 3. All 24+ = 1.5. Else 0
D4	No text under 12 px; reading paragraphs 16 px or more	4	Two halves, each can be Not checked alone. Nothing under 12 = 2 (1 to 3 runs = 1). Paragraphs over 60 characters outside the footer all 16+ = 2 (1 to 3 under = 1)
D5	Images sized, iframes lazy with reserved height	3	All visible images have width and height = 2 (1 to 3 missing = 1). Every iframe lazy with 300+ px height, or no iframes = 1
D6	Safe-area padding and viewport-fit=cover	2	Both = 2, one = 1, none = 0
D7	No autoplay with sound; video behind a click-to-load thumbnail	2	No sound autoplay = 1. No YouTube or Vimeo iframe on load = 1
D8	Popups fit the width, have a close button, lock the page behind	3	No popups = 3. Else 1 point for each of the three
D9	Reduced-motion and focus-visible styles	2	1 point each
D10	No console errors on mobile load	1	None = 1, else 0
E1	First in-page booking button fully on the first screen	5	Yes = 5, else 0. Header and sticky buttons don't count here. Cut off only by the browser bar but within 812 px = yes
E2	Booking button repeated	4	Sticky or header booking button = 2. Biggest gap between buttons 4 screens or less (6 or less with a sticky button) = 2; 8 or less = 1
E3	One action: one button wording, no competing destinations	3	At most two versions of the booking label and no competing destination = 3, else 1. A competing destination is a link to another offer, a different product or checkout, or a social profile. Footer legal links pass. A navigation menu fails only on a dedicated funnel page (ad, VSL, or application page); on a main-site homepage it passes
E4	Headline 3 lines or fewer; no H2 over 4 lines	3	H1 of 3 lines or fewer = 2, 4 lines = 1. No H2 over 4 lines = 1
E5	Proof within 1.5 screens of the top	2	1.5 screens or less = 2. 2.5 or less = 1. Else 0
E6	Booking friction	2	4 or fewer form fields on screen before the calendar times (a form in steps counts its longest step) = 1. Calendar lazy-loaded with reserved height, or the button opens a separate fast booking page = 1
E7	Scannable: 10% or fewer paragraphs past 6 lines	1	Yes = 1, else 0

Where this comes from: A and B use Google's Core Web Vitals thresholds and PageSpeed score bands. C and D follow WCAG, the web accessibility standard: 24 px tap size is the AA minimum and 44 px is the stricter AAA target used here. The E thresholds are this rubric's own lines, based on landing-page guidance from CXL, Nielsen Norman Group, Baymard, and Unbounce, not numbers those sources publish. A "booking button" is any button that starts booking: Book, Apply, Schedule, Get started, Talk to us.

Hosted calendar pages. If traffic goes straight to a page hosted by the calendar tool and there is no page in front of it, mark E1, E2, E4, and E5 N/A: there is no in-page button, headline, or proof to judge, and the owner can't add them. Score the rest as usual and say so in the score line.

Lines marked Not checked or N/A stay out of the total. Report the points earned and how many points were checked.

Step 7. Rank the fixes

• Sort every line that lost points by points missing, largest first. On a tie, put the cheaper fix first, then funnel lines (E) before UX lines (D).
• Speed is one fix line. A1, B1, B2, and B3 together make a single line: "Speed work: up to [points missing across the four] points". Under it, list the sub-steps in the order of PageSpeed's own "Est savings", biggest first, with no points on any sub-step. PageSpeed estimates seconds saved, not score points, so any split would be made up.
• On page-builder pages, speed often sits at 20 to 50 and much of it is the builder's own code. Say that plainly, and list only what the page owner controls: images, video, widgets, fonts.
• When one change fixes several of the other lines, make it one fix and add the points together. When it also helps speed (a click-to-load video fixes D7 and cuts load time), add "also helps speed work".
• Do these three first = the three fixes with the most points per hour that the person who edits the page can make. It is often not the top of the fix list. Label any that need a developer.
• Write each fix for the person who will make it: page-builder settings for a founder, exact code for a developer.

Common causes and fixes:

Lines	Usual cause	Fix
Speed work	Hero image is a large file or a CSS background, found late	Make it a real image, WebP, about 800 px wide. Never lazy-load it. Mark it high priority (fetchpriority="high") and preload it
Speed work	Web fonts block the first paint	Use two weights at most, font-display: swap, preload only the headline and body fonts. Keep the brand font; cut weights instead of swapping it
Speed work	Chat widget, heatmap, or session recorder loads first	Load them after the page finishes, or on first scroll
Speed work	Ad pixels, conversion tags, or analytics block the page	Load them async on page load, never on scroll, and keep every event. Delaying them to scroll loses the visitors who leave fast and shrinks retargeting audiences
Speed work	Old tools nobody uses anymore	Delete them
Speed work, D7	Video player loads on arrival	Show a thumbnail with a play button that loads the player on tap
Speed work (B2), D5	Images, video, or calendar push content down as they load	Set width and height on every image; give video and calendar a fixed height before they load
C1	Faint gray text, unnamed buttons, missing image alt text	Body text contrast 4.5 to 1 or more (3 to 1 for large text). Darken dim text. Give every button a clear label
D1	No viewport tag	Add <meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">
D2	A fixed-width image, table, embed, or long link wider than the screen	Set max-width: 100% on it, or let long links wrap
D3	Small footer links, inline links, tiny close buttons	Pad them to 44 px tall with 8 px between targets
D4	Small labels and captions; body text at 14 or 15 px	Body 16 px on mobile, nothing under 12 px. Legal small print in the footer may stay at 13 px
D6	Sticky bar sits under the notch or home bar	Add viewport-fit=cover plus padding-bottom: env(safe-area-inset-bottom) on bottom bars (top inset on top bars)
D8	Page scrolls behind the popup; no close button	Lock page scroll while it is open; add a visible close button, 44 px
D9	Missing accessibility styles	Add a prefers-reduced-motion rule that stops animation, and a visible :focus-visible outline
E1	Logo bar, big headline, subhead, and video stack push the button down	Smaller mobile headline, shorter subhead, button above or right under the video
E2	Long sections with no button	Add a sticky bottom booking bar in thumb reach, and a button after each big section
E3	Links to other offers or social profiles, mixed labels, a menu on a funnel page	One label everywhere. Remove links to other offers, products, and social profiles. On a dedicated funnel page, remove the menu too. Footer legal links stay. On a main-site homepage, keep the menu
E5	Testimonials sit at the bottom	Move a logo row or one short result right under the first button
E6	Long form before the calendar; heavy inline calendar	Keep the questions that qualify leads. Ask for the time slot first and move the extra questions to after the booking (most calendar tools support this), or split the form into short steps with one question per screen. Lazy-load the calendar with a fixed height
E7	Wall-of-text paragraphs	Split into paragraphs of 3 lines or fewer on a phone

Step 8. Re-check after the fixes

When the fixes are live, run PageSpeed again (three runs if near a line), retake the first-screen, booking-path, and in-app browser screenshots, and run this check again with the same rubric. Stop at 100, or when the only gap left is PageSpeed swing of under 2 points across three runs. If the user tracks it, compare the mobile booking rate, lead quality, and show rate before and after: the score measures friction, bookings measure the result.

What you get

A report in this exact format:

# Mobile Checker: [page name]

**Booking path:** [Works: every step up to the final Confirm button seen in (browsers) / BROKEN: what, at which step, which browser / Not tested: what is missing]
**Score:** [earned] of [checked] points checked ([earned divided by checked]%). [Add "Partial" when fewer than 60 points were checked.] [If any line is N/A, name it: "E1, E2, E4, E5 N/A: hosted calendar page".]
**Bottom line:** [One sentence: the biggest problem and the first fix.]
**Tested on:** [phone model, CSS width], [Safari or Chrome, plus in-app browser if tested], live page, [date]

## Scorecard
| Section | Points | Checked max | Max | Checked by |
|---|---|---|---|---|
| A Speed | [points, or a dash if not checked] | [points checked] | 30 | [PS / Not checked] |
| B Web Vitals | | | 15 | |
| C Accessibility | | | 10 | |
| D Mobile UX | | | 25 | |
| E Funnel | | | 20 | |
| Total | [earned] | [checked] | 100 | |

## Every line
| Line | Check | Points | Evidence | Source |
|---|---|---|---|---|
| A1 | PageSpeed Performance | [x]/30, or a dash if not checked | [score] | PS |
| ... | [all 22 lines, A1 to E7] | | | |

## Fix list (biggest gap first)
| Rank | Fix | Lines | Points back | Who | Effort |
|---|---|---|---|---|---|
| 1 | Speed work (steps below) | A1, B1, B2, B3 | up to [x] | [You / Developer] | [half day] |
| 2 | [plain-word change] | [E1] | [5] | [You / Developer] | [15 min / 1 hr / half day] |

Speed work steps, in PageSpeed's "Est savings" order: [one line each, no points]
How to do the top 5: [2 to 4 lines each, in page-builder terms or exact code]

## Do these three first
Most points per hour for [whoever edits the page].
1. [fix]: [points back], [time], [You / Needs a developer]
2.
3.

## Not checked yet
- [Line] ([points]): [how to check it, in one line]

## Extra findings (no points)
- [In-app browser differences, calendar tap targets with a tool-level fix, "hidden on your phone by the browser bar", confirmation screen: seen / missing / not submitted, anything else the rubric does not score]

## Leave these alone
- [Things that look like problems but should stay, with the reason. For example: qualifying questions you use to filter calls (cut only questions nobody uses, and watch lead quality and show rate after any change); the navigation menu on a main-site homepage.]

## Re-check
[What to rerun, and the target score.]

Keep the report tight. A clean page may need 40 lines; a broken one may need 120.

Rules

• Score only on evidence. Never invent a PageSpeed number, a pixel size, or a line count you did not see. Anything judged by eye is labeled Est.
• Never read positions from one tall capture. Tile it with code, or ask for overlapping screenshots and mark those lines Not checked meanwhile.
• Not checked is not zero. Not checked and N/A lines stay out of the total. Always show [earned] of [checked] points checked; add the word Partial when fewer than 60 points were checked.
• The rubric is fixed. Same lines, weights, and thresholds every run, so scores compare across runs and pages. Never add or drop points for things outside it; those go under Extra findings.
• A broken booking path beats every score. If a visitor can't finish booking on a phone, in any browser, say so first. Write "Works" only when every step up to the final Confirm button was seen in screenshots; otherwise write "Not tested" and what is missing.
• Warn before any live test booking. Default to stopping at the final Confirm button. A real booking fires ad pixels and follow-up automations.
• Test where the traffic lands. If visitors come from Instagram, Facebook, or LinkedIn, the in-app browser test matters more than any single rubric line.
• The fix list shows size; "Do these three first" shows order. Work the three first, then go down the list.
• Never invent speed points. Speed work is one line with one total; its sub-steps follow PageSpeed's "Est savings" and carry no points.
• Don't remove the booking step to win points. An inline calendar that converts stays; make it lazy with a fixed height instead.
• Don't cut qualifying questions to win a point. Move them after the booking or split them into steps.
• Don't delay ad pixels or analytics to win speed. Load them async on arrival and keep every event.
• Don't chase the last 1 or 2 PageSpeed points. They swing between runs.
• Don't swap the brand font for a system font without asking. Cut font weights first.
• Don't promise more bookings. The rubric removes known friction. Only the before-and-after booking rate proves a lift.
• Tool-neutral. The fixes work in any page builder or calendar tool. Say what to change, then translate it into the user's tools if they name them.

Part of the free 20-skill pack by Ruben Davoli at BeaverMind (beavermind.ai).