Check Page Fifty, Not Page One: Our Own Lighthouse Scores, Published

Short answer: quality that holds on every page, not only the homepage, comes from a delivery process that checks every page the same way, not from extra effort on the pages people look at. If you are choosing who builds your site or product, the decision at stake is whether quality is checked by the process or by attention. Ask how a team checks page fifty, not page one.

Could your team build a website where every page - not just the homepage - is held to the same quality checks? It’s a question that reveals more about your engineering culture than it does about your technical capabilities.

Most development teams follow a predictable pattern when it comes to website quality. They pour their energy into the pages customers see first, and let everything else slide. It’s not malicious—it’s just how priorities naturally shake out when deadlines loom and resources are finite.

The 80/15/5 Rule of Web Development

A common pattern in how optimization effort gets distributed (a rule of thumb, not a measured ratio):

Homepage gets 80% of optimization effort — This is the showcase page. Everyone reviews it. The CEO sees it. It gets obsessive attention.
Main pages get 15% — Service pages, product pages, about pages. They get some polish, but not the same level of scrutiny.
Everything else gets 5% — Blog posts, legal pages, terms of service, deep product pages. "Good enough" becomes the standard.

The usual result: quality degrades as you go deeper into the site. The homepage looks fine; three clicks in, it doesn’t.

Our Numbers, Published

We ran Google Lighthouse on twelve pages of ioanyt.com on 14 October 2026, from the homepage to blog posts, case studies and the contact page. The scores are below, including the ones we are not happy with.

Consistency across pages is the part that held. The absolute scores are not all where we want them, and we say which ones.

The Data

Measured 14 October 2026 with Lighthouse 12.8 on 12 pages, desktop and mobile settings (reports on file). Lighthouse scores move a little between runs, so treat each as plus or minus a few points, and run it yourself.

Metric	Desktop: average (range)	Mobile: average (range)	What it means
Performance	95 (85–98)	59 (42–68)	Fast on desktop; on a throttled mobile connection, our pages are too heavy. This is the gap we are fixing first
Accessibility	96 (94–96)	96 (94–100)	Consistent on every page measured
Best Practices	78 (78–78)	79 (79–79)	Same on every page: third-party analytics cookies cost the points
SEO	100 (100–100)	99 (92–100)	Consistent on every page measured

Pages measured: home, about, contact, blog index, this post, case studies, insights, commitments, compiled AI, AI Code Rescue, legacy systems, Workflow Diagnostic.

The Key Insight

The point isn't one high score. Anyone can tune a homepage. The signal is the spread: on our own site, accessibility, SEO and best practices barely move between the homepage and a blog post, because every page goes through the same checks. Where a score is low, it is low everywhere, which tells you it's a site-wide decision to fix, not a neglected corner.

Why This Matters for CTOs

This isn’t just about website performance metrics. The deeper meaning reveals itself when you understand what consistent quality signals about an organization’s delivery culture.

1. It’s a Proxy for Process

The Real Signal

If we can maintain consistency on a website—where the temptation to cut corners is enormous and the cost of doing so is relatively low—we can maintain it on infrastructure where the stakes are exponentially higher. The same approach of checking every page the same way applies to everything we build: Terraform modules, monitoring dashboards, CI/CD pipelines, API implementations.

When you see consistent quality across every page—from the homepage your CEO scrutinizes to the privacy policy nobody thinks about—you’re seeing evidence of process, not heroics. You’re seeing a team that doesn’t rely on last-minute optimization sprints or individual developers going above and beyond. You’re seeing automation, standards, and systematic enforcement.

2. The 80/15/5 Rule Reveals Delivery Culture

Where attention goes shows what teams actually prioritize. The distribution of optimization effort across a website is like a cultural X-ray of how a team approaches delivery.

Ad-Hoc Approach

Hero pages get all the attention
"Less important" pages actively neglected
Quality variance = 30+ points across site
Manual optimization sprints before launches
Standards applied inconsistently

Systematic Approach

Every page follows same standards
No "unimportant" page designations
Quality variance < 3 points across site
Automated quality gates on every deploy
Standards enforced by tooling, not discipline

Here’s the uncomfortable truth that most teams don’t want to acknowledge: in production systems, there are no unimportant pages.

Your terms of service page matters to your legal team when they’re defending a contract dispute. Your blog posts matter to your SEO team when they’re trying to drive organic traffic. Your deep product pages matter to enterprise buyers who spend three months researching before they pick up the phone. Every page matters to someone, which means every page deserves the same quality standard.

3. SOC2 Implications

Compliance Reality Check

When auditors assess your SOC2 compliance, they don't look at your best systems—they look at your least-maintained systems. They're trying to understand your baseline, not your ceiling. A pristine homepage and a neglected terms page tells them you apply standards selectively, which is exactly what compliance frameworks are designed to prevent.

Your terms page matters as much as your homepage when an auditor is evaluating your organization’s commitment to systematic quality. The variance between them reveals whether quality is a value or a feature.

The Question for Your Current Vendors:

Run Google Lighthouse on any page of your contractor’s website. Then compare it to their homepage. The delta—the difference in scores—tells you everything you need to know about their delivery discipline. If they can’t maintain quality on their own website, they won’t maintain it on yours.

How Systematic Delivery Works

We can share the philosophy and approach without exposing specific implementation details. This is how systematic teams maintain consistent quality across every component they ship.

1. Standards Apply to Everything, Not Just Flagships

The Checklist (Same for Every Component)

Performance budgets — One load-time budget that every page type is measured against
Accessibility standards — WCAG 2.1 AA as the target on every page
SEO requirements — Proper meta tags, structured data, semantic HTML
Security headers — Content Security Policy, HTTPS, secure cookies
Best practices compliance — Asset optimization, proper caching, modern APIs

Every page. No exceptions. No "this one doesn't matter" designations.

The moment you create two tiers of pages—important and unimportant—you’ve introduced technical debt that will compound over time. Systematic teams reject this binary from the start.

2. Automation Enforces Consistency

Humans set the standards. Automated checks prevent regression. This is the only scalable way to maintain quality as your codebase grows.

What This Means in Practice

No manual heroics required — Individual developers don't need to remember to optimize. The build fails if standards aren't met.
No "optimization sprints" before launches — Quality is baked into every commit, not bolted on at the end.
No degradation over time — Automated testing catches regressions before they reach production.

Quality becomes the default state, not the exception achieved through extra effort.

3. Quality Gates, Not Quality Sprints

The difference between systematic and ad-hoc approaches comes down to this: systematic teams treat quality as a continuous state that must be maintained, not as a periodic event to be scheduled.

Instead of periodic audits followed by scrambling, systematic teams use continuous measurement:

Every Deploy

Automated checks run before anything reaches production, and a failure blocks the deployment.

Every Change

Problems are caught immediately in CI, not months later in production. Feedback loops measured in minutes, not sprints.

Every Page

Regression is prevented, not detected. No page can slip below the threshold without triggering alarms.

This is the difference between treating quality as an event (something that happens before launches) versus quality as a state (something that’s continuously maintained).

Try It Yourself

The Challenge

Don't take our word for it. The proof is completely verifiable by you, right now, using free tools. Here's what to do:

1 Run Google Lighthouse on ioanyt.com—pick any page, we don't care which one
2 Run it on your current vendor's website—start with their homepage
3 Run it on your own company's website—be honest with yourself
4 Compare homepage scores to the deepest pages you can find—legal pages, old blog posts, forgotten documentation

What you’ll likely find when you do this exercise:

Many sites show a clear drop from the homepage to the deep pages. This is the 80/15/5 rule made visible.

On ioanyt.com, accessibility, SEO and best practices stay within a few points across the pages we measured. Desktop performance varies more (85 to 98), and mobile performance is lower everywhere (42 to 68). That is what we are fixing next; this table will be updated when we re-measure.

The Proof Is Verifiable

No marketing claims required—just open Chrome DevTools and run Lighthouse yourself
Any third party can validate—auditors, clients, competitors, anyone
Results speak for themselves—no interpretation or spin required

Go ahead. We'll wait.

What This Means for Client Work

The Connection to Your Infrastructure

The same systematic approach that built this website—the automation, the quality gates, the refusal to accept "good enough"—is what we apply to client infrastructure. This isn't theoretical. It's how we work.

Here’s how systematic delivery translates to DevOps work:

Every Terraform module gets the same review standard, whether it’s the flagship API gateway or an internal logging bucket
Every monitoring dashboard follows the same completeness checklist—production services and development environments alike
Every handoff includes the same documentation depth—no “this part is obvious” shortcuts

Without Systematic Delivery

"Some infrastructure is excellent, some is acceptable"

• Hero deployments that can't be reproduced by other team members
• Code optimized for the demo that falls apart in production
• Quality that varies depending on which developer built it
• Standards applied when someone remembers, ignored when deadlines loom

With Systematic Delivery

"Everything at the same standard"

• All deployments follow the same automated process
• Production-ready from day one, not after months of hardening
• Quality independent of who built it—tooling enforces standards
• Standards enforced by automation, failures block deployment

When you receive a delivery from IOanyT, you’re not getting code that was optimized for the proof-of-concept demo and then abandoned. You’re getting infrastructure that maintains the same quality standards in production—week one and week fifty-two—because the standards are enforced by automation, not by individual discipline.

The Bottom Line

The Question

What would it mean for your infrastructure if every component—not just the flagship services that executives care about—maintained production-grade quality? If your monitoring dashboards were as polished as your API endpoints? If your internal tooling met the same standards as your customer-facing features?

That's the question we answer with every project.

Systematic processes produce consistent results at scale. Not just hero pages that get obsessive attention. Not just flagship features that make it into the marketing deck. Everything.

When quality is a systematic property of your delivery process—not an aspirational value or a best-effort target—it stops being something you have to think about and starts being something you can rely on.

Want to see how we apply this to your infrastructure?

📋 View our public delivery standard — The complete checklist we use for every project
🔧 See our engineering — The team that builds what we recommend
🧭 How we work — From a first review to a system you own