A site can look polished on a desktop and still be awkward on the phone a customer is using. Test the task they came to complete: checking a service, reading a menu, calling, or requesting a quote.
Start With a Quick Phone Test
Pull up your website on your own phone. Can you read the main text without pinching to zoom? Can you tap the call or contact button without hitting the wrong thing? Does the page become usable while the images are loading?
If any answer is no, write down the page and the exact problem. A specific note such as “the cookie banner covers the booking button” is more useful than “mobile looks bad.”
Follow a Real Customer Task
- Start on a service page. Visitors may arrive from search without seeing your homepage. Confirm the service, area, and next step are clear there too.
- Use the navigation. Open and close the menu. Check that the page can scroll again after you close it.
- Try the main action. A call link should open the dialler with the correct number. An ordering or booking link should reach the right business. Stop before calling or making a booking unless you intend to do so.
- Test your own form deliberately. Submit a clearly labelled test enquiry to your business. Confirm it arrives, the reply address works, and the page shows a meaningful success message. Also try an incomplete form to see whether the error explains how to fix it.
- Enlarge the text. Check that important words, controls, and prices remain available when text is enlarged.
Check More Than Your Own Phone
A laptop preview has a large screen and often a steady connection. Try a second phone if you can, and compare Wi-Fi with mobile data. A private browsing window can help reveal first-visit banners you no longer see.
At RaizHost, our standard phone layout checks include 375, 412, and 430 CSS pixels wide, plus behaviour between breakpoints. Those are test widths, not a claim to cover every device. Browser resizing helps find layout issues, but a physical phone is still useful for testing taps and the on-screen keyboard.
Watch for the Quiet Failures
Text that requires zooming, pages that scroll sideways, buttons too close together, and popups that cannot be closed all add work for visitors. Fixed headers and bottom bars can also cover a form field when the keyboard opens.
Test the entire task, not just the top of the page. Accessibility adds other checks, including keyboard operation and visible focus; see our accessibility first checks.
Measure Speed Without Chasing a Perfect Score
Use PageSpeed Insights to investigate a slow page. Google’s Core Web Vitals cover loading, responsiveness, and visual stability. The “good” thresholds are LCP at most 2.5 seconds, INP at most 200 milliseconds, and CLS at most 0.1, evaluated at the 75th percentile of visits.
The report may show real-user data and a separate simulated lab test. Smaller sites may not have enough traffic for field data. A lab score is a diagnostic snapshot, not proof that every visitor has the same experience or that the page will rank well.
Oversized photos and unnecessary scripts are useful places to investigate. Size and compress images for their displayed use; do not delay the main visible image just to make every image lazy-loaded.
Fix the Worst Problem First
Fix a failed enquiry or booking path before a cosmetic detail. Then address unreadable content, blocked controls, and slow loading. Repeat the same customer task after each fix so you can tell whether it worked.
For help, send us your site and the failing step. You may need a focused repair rather than a full rebuild.