← All guides

Our website, tested

How we tested Orlando Advertising’s website

A dated look at our own site: measured speed, practical usability checks, one improvement and the limits of the evidence.

Orlando Advertising · Published October 21, 2026 · Sources checked October 21, 2026

What this report covers

This is a report about our own website, not a client case study. The linked homepage reports were run on October 21, 2026 at 06:12 UTC, after changes to navigation and the homepage. They are a snapshot of that tested version. Later content or design changes may produce different results.

We used Google PageSpeed Insights for the homepage on simulated mobile and desktop conditions. Its automated reports cover performance, accessibility, best practices and search engine optimization, often shortened to SEO. We did not measure search rankings, leads or sales for this report.

The measured homepage results

Mobile: performance 99, accessibility 100, best practices 100 and SEO 100. Desktop: 100 in all four categories. The exact mobile and desktop reports are linked below so the result can be checked rather than accepted as a badge without context.

Largest Contentful Paint was about 1.5 seconds in the mobile lab test and 0.4 seconds on desktop. That measures when the largest eligible visible text or image element is rendered, not when every part of a page has finished loading. Both tests recorded zero total blocking time and zero cumulative layout shift. These are specific measurements, not a claim of instant response in every situation.

Real-user field data was unavailable. Google explains that lab tests use controlled conditions, while field data reflects real visits when enough samples exist. We therefore cannot use these reports to claim that every visitor has the same experience or that the site passes a real-user Core Web Vitals assessment.

A real improvement, not a score trick

During an earlier check that morning, we found styling instructions generated from unused starter components. The pages did not need those instructions. We narrowed the build’s source scanning while keeping the actual site styles and base formatting intact.

In the tested service-page reports, the stylesheet transfer fell from 18.1 KiB to 5.2 KiB, and the unused-CSS diagnostic disappeared. We then checked representative desktop and narrow-screen pages for missing styles. We did not hide content, remove working features or weaken checks to improve the result.

That is a concrete reduction in unnecessary data. It is not evidence of a ranking increase or higher conversion rate. We keep that distinction because a useful technical improvement should be described accurately, without turning it into an unmeasured business claim.

What we check beyond the score

Practical browser checks included representative pages at 320- and 390-pixel widths, readable labels and buttons, the contact section, keyboard-operated questions and links to article sections. We checked whether pages forced sideways scrolling and whether the next step remained understandable. These are sampled checks, not a claim that every device and assistive-technology combination was tested.

A separate, clearly marked dummy inquiry was submitted on October 20, 2026 and confirmed in the private receiving system. We rechecked that stored test record on October 21. The later visual checks did not send additional inquiries. This distinction matters: a working-looking button alone cannot prove that a message was saved.

Our review separates source checks, browser behavior and automated reports. Each answers a different question: whether a statement is supported, whether a person can complete a task, and whether a tool detects a particular issue.

What these results do not establish

A Lighthouse accessibility score of 100 is not an accessibility certification. Google’s documentation notes that some manual checks do not affect that score. A formal assessment would require a separately defined review, including people and technologies beyond these practical tests.

Some unscored performance advisories remained, including unused framework JavaScript and render-blocking styling. We assessed them rather than assuming every advisory justified a risky rewrite. A one-point change between lab runs is not a reason to keep retesting until a preferred number appears.

This report is not a security audit, a promise of indexing or a prediction of search placement. Google’s page-experience guidance asks site owners to consider the whole experience, not just one metric. Useful content, accurate business details and the actual customer journey still matter.

How this informs our client work

The method is repeatable: agree on the pages and tasks to examine, capture evidence, prioritize meaningful defects, make a defined change and check the result. Record what was tested and what was not. That gives the business something more useful than an unexplained score or a long list of warnings.

For a different website, the priorities may be different. A confusing service explanation or a form that loses inquiries can deserve attention before a small speed improvement. A scoped review should make those trade-offs clear and leave a practical next-step list.

A practical starting checklist

Sources and context

This is an original AI-assisted explanation, with factual statements checked against the linked sources. The practical workflow is our recommendation, not a claim that Google requires every step. Guidance can change. No rankings, traffic or business results are guaranteed.

Put this into practice

Keep learning