DEV Community: Yuri Tománek

Your Lighthouse Score Is Only Half the Story

Yuri Tománek — Sun, 22 Feb 2026 04:24:03 +0000

A Lighthouse score of 95 feels great. Until you check what your actual users experience and find that 40% of them are getting a Poor LCP.

How? Because Lighthouse runs in a controlled environment. Fixed CPU, fixed network, no browser extensions, cold cache. Your real users are on old Android phones, congested Wi-Fi, with 12 Chrome extensions installed. The test and reality can be very different.

We just shipped Field Data in Ahoj Metrics to close that gap. You can now look up real Chrome user experience data for any domain or URL, right alongside your Lighthouse audits.

What Is Field Data?

The data comes from Google's Chrome User Experience Report (CrUX). It's an aggregated, anonymised dataset of real performance timings collected from Chrome users who have opted in to sharing usage statistics.

When someone visits your site in Chrome, their browser quietly measures how long things take to load, how quickly the page responds to clicks, and how much the layout shifts around. Google aggregates this data across all opted-in Chrome users and makes it available through the CrUX API.

A few important details about how CrUX works:

28-day rolling window. The data represents the last 28 days of real user visits. No single bad day can spike the numbers. No single good day can hide persistent problems.

75th percentile (p75). The reported value isn't the average. It's the experience of someone at the 75th percentile, meaning 75% of your visitors had a better experience than this number, and 25% had a worse one. This is intentional. Google wants you to optimize for the tail, not the middle.

Good / Needs Improvement / Poor distribution. Every page load gets classified against Google's thresholds. You can see what percentage of your users fall into each bucket. A site might have 80% Good, 12% Needs Improvement, and 8% Poor for LCP. That distribution tells you more than any single number.

Lab Data vs Field Data

This is the core concept. Both are useful. Neither is complete on its own.

Lab data (Lighthouse) tests your site in a controlled environment. Same CPU, same network throttling, same browser config, every time. It's reproducible. It's great for finding issues, comparing before/after a deployment, and running automated tests in CI/CD. But it's synthetic. It doesn't represent any real user.

Field data (CrUX) measures what your actual visitors experience. Real devices, real networks, real browser configurations. It's messy and variable, but it's the truth. It's also what Google uses for Core Web Vitals in Search ranking.

Here's where it gets interesting: these two numbers can disagree significantly.

A site might score 68 on Lighthouse (worrying) but show 85% Good LCP in CrUX (fine in practice). Why? Maybe most of your users are on fast connections with warm caches, so the real experience is better than what the lab predicts.

Or the reverse: a Lighthouse score of 92 (looks great) but only 55% Good LCP in CrUX (a real problem). Maybe your audience skews toward mobile users in regions with slower connectivity, and the lab test doesn't capture that.

Neither number is "right." Lab data tells you what's wrong. Field data tells you the impact. You need both to make good decisions about where to spend your optimization time.

The Five Metrics

Field Data in Ahoj Metrics shows five metrics:

LCP (Largest Contentful Paint) measures how quickly the main content loads. This is usually the hero image, a large heading, or a video thumbnail. Google considers under 2.5 seconds "Good."

INP (Interaction to Next Paint) measures how responsive the page is to user input. When someone taps a button or clicks a link, how long before something visibly happens? Under 200ms is "Good." INP replaced FID (First Input Delay) as a Core Web Vital in 2024.

CLS (Cumulative Layout Shift) measures how much the layout jumps around while loading. You know when you're about to tap a button and an ad loads above it, pushing everything down? That's layout shift. Under 0.10 is "Good."

FCP (First Contentful Paint) measures how quickly the first piece of content appears. Not the main content (that's LCP), just anything: text, an image, the background color. Under 1.8 seconds is "Good."

TTFB (Time to First Byte) measures how quickly the server responds to the browser's request. Under 800ms is "Good."

LCP, INP, and CLS are Google's three Core Web Vitals. These are the metrics that directly feed into Google's search ranking signals. If you can only focus on three things, focus on these.

How to Use It

Go to Field Data in the Ahoj Metrics sidebar. Enter any domain (like https://stripe.com) or a specific URL. Hit Look Up Field Data.

You'll see the p75 value and the Good/Needs Improvement/Poor distribution for all five metrics. Instant results, no audit credits used.

A few things to know:

It works for any public site. You can look up your competitors, your clients, or any site you're curious about. The data is public.

Not every URL has data. CrUX needs a meaningful amount of Chrome traffic to generate a record. If you look up an internal tool, a brand new site, or a low-traffic page, Google won't have data for it. You'll see a clear message when that happens. Origin-level lookups (the whole domain) are more likely to have data than individual URLs.

It's available to all users. Free tier, paid plans, everyone. Field Data lookups don't count against your audit quota. The CrUX API is free from Google, and we saw no reason to gate it.

How This Changes Your Workflow

Before, an Ahoj Metrics workflow looked like this:

Run Lighthouse audit from multiple regions
See scores and recommendations
Fix issues
Run another audit to verify

Now it looks like this:

Check Field Data for a baseline of what real users experience
Run Lighthouse audit from multiple regions to find specific issues
Fix issues
Run another audit to verify the fix
Wait for field data to update (28-day rolling window) to confirm the real-world impact

Field data gives you the "why" behind your optimization work. You're not fixing things because a synthetic test says so. You're fixing things because 30% of your real users are getting a Poor LCP.

Why Not Just Use PageSpeed Insights?

Google's PageSpeed Insights already shows CrUX data. It's free and it works. So why look at it in Ahoj Metrics?

Context. In PSI, field data lives on Google's website, separate from everything else. You look up a URL, see the numbers, close the tab. In Ahoj Metrics, field data lives next to your Lighthouse audits, your monitors, and your historical data. You can see how your lab scores compare to real-world experience for the same site, in the same tool, without switching between tabs.

PSI also doesn't save history, doesn't compare across sites, and doesn't integrate into a monitoring workflow. It's a snapshot tool. Ahoj Metrics is trying to be the place where all your performance data lives together.

Technical Details

For anyone curious about the implementation:

We built a thin Ruby wrapper around the CrUX API (ahojmetrics/crux-api). Results are cached server-side for 12 hours using Solid Cache (PostgreSQL-backed, same as the rest of our infrastructure). Repeat lookups for the same URL are instant.

The API response from Google is verbose. Metric names are long (largest_contentful_paint), CLS comes back as a string float, and the structure is nested. Our serializer normalizes everything into a clean JSON shape with short keys (lcp, inp, cls) that the frontend can work with easily.

Authentication is the same as every other Ahoj endpoint. Standard JWT/session auth, no separate API key needed.

What's Next

Field Data is a lookup tool today. You search for a URL and see the current CrUX data. We're thinking about:

Historical field data tracking. Store CrUX snapshots over time so you can see trends, not just the current 28-day window.
Field data alongside monitors. When your automated Lighthouse monitor runs, also pull the CrUX data for that URL and display them together.
Field vs lab comparison view. A side-by-side showing your Lighthouse lab metrics and CrUX field metrics for the same URL, highlighting where they agree and where they diverge.

If any of those would be particularly useful to you, I'd love to hear about it.

Try It

Sign in to Ahoj Metrics and go to Field Data in the sidebar. Look up your own site, look up your competitors, look up anything. No credits used, no limits.

If you don't have an account, the free tier gives you 20 Lighthouse audits per month plus unlimited Field Data lookups.

Ahoj Metrics is a performance monitoring tool that runs Lighthouse audits from 18 global regions and now shows real Chrome user experience data via CrUX. Built with Rails 8, Solid Queue, and Fly.io.

How We Run Lighthouse from 18 Regions in Under 2 Minutes

Yuri Tománek — Sat, 14 Feb 2026 12:19:08 +0000

Most performance monitoring tools test your site from one location, or run tests sequentially across regions. That means testing from 18 locations can take 20+ minutes.

We needed something faster. Ahoj Metrics tests from 18 global regions simultaneously in about 2 minutes. Here's how.

The Architecture

The core idea is simple: don't keep workers running. Spawn them on demand, run the test, destroy them.

We use Fly.io's Machines API to create ephemeral containers in specific regions. Each container runs a single Lighthouse audit, sends the results back via webhook, and destroys itself.

Here's how a request flows through the system:

The key design decision: one audit = one ReportRequest, regardless of how many regions you test. Test from 1 region or 18 - it's the same user action.

Spawning Machines with the Fly.io API

Here's the actual code that creates a machine in a specific region:

class FlyMachinesService
  API_BASE_URL = "https://api.machines.dev/v1"

  def self.create_machine(region:, env:, app_name:)
    url = "#{API_BASE_URL}/apps/#{app_name}/machines"

    body = {
      region: region,
      config: {
        image: ENV.fetch("WORKER_IMAGE", "registry.fly.io/am-worker:latest"),
        size: "performance-8x",
        auto_destroy: true,
        restart: { policy: "no" },
        stop_config: {
          timeout: "30s",
          signal: "SIGTERM"
        },
        env: env,
        services: []
      }
    }

    response = HTTParty.post(
      url,
      headers: headers,
      body: body.to_json,
      timeout: 30
    )

    if response.success?
      Response.new(success: true, data: response.parsed_response)
    else
      Response.new(
        success: false,
        error: "API error: #{response.code} - #{response.body}"
      )
    end
  end
end

A few things worth noting:

auto_destroy: true is the magic. The machine cleans itself up after the process exits. No lingering containers, no zombie workers, no cleanup cron jobs.

performance-8x gives us 4 vCPU and 8GB RAM. Lighthouse is resource-hungry - it runs a full Chrome instance. Underpowered machines produce inconsistent scores because Chrome competes for CPU time. We tried smaller sizes and the variance was too high.

restart: { policy: "no" } means if Lighthouse crashes, the machine just dies. We handle the failure on the Rails side by checking for timed-out reports.

services: [] means no public ports. The worker doesn't need to accept incoming traffic. It runs Lighthouse and POSTs results back to our API. That's it.

The Worker

Each Fly.io machine runs a Docker container that does roughly this:

Read environment variables (target URL, callback URL, report ID)
Launch headless Chrome
Run Lighthouse audit
POST the JSON results back to the Rails API
Exit (machine auto-destroys)

The callback is a simple webhook. The worker doesn't need to know anything about our database, user accounts, or billing. It just runs a test and reports back.

Handling Results

On the Rails side, each Report record tracks its own status:

class ReportRequest < ApplicationRecord
  has_many :reports

  def check_completion!
    return unless reports.all?(&:completed?)

    update!(status: "completed")
    update_cached_stats!
    check_monitor_alert if site_monitor.present?
  end
end

When a worker POSTs results, the corresponding Report is updated. After each update, we check if all reports for the request are done. If so, we aggregate the results, calculate averages, and update the dashboard.

Each report is independent. If the Sydney worker fails but the other 17 succeed, you still get 17 results. The failed region shows as an error without blocking everything else.

Cost Math

This is the part that makes ephemeral workers compelling. Compare two approaches:

Persistent workers (18 regions, always-on):

18 performance-8x machines running 24/7
Based on Fly.io's pricing calculator: ~$2,734/month
Mostly sitting idle waiting for audit requests

Ephemeral workers (our approach):

Machines run for ~2 minutes per audit
performance-8x costs roughly $0.0001344/second
One 18-region audit costs about $0.29
100 audits/month = ~$29

At low volume, ephemeral is dramatically cheaper. The crossover point where persistent workers become more cost-effective is well beyond our current scale.

The tradeoff is cold start time. Each machine takes a few seconds to boot. For our use case (users expect a 1-2 minute wait anyway), that's invisible.

The Background Job Layer

We use Solid Queue (Rails 8's built-in job backend) for everything. No Redis, no Sidekiq.

# config/recurring.yml
production:
  monitor_scheduler:
    class: MonitorSchedulerJob
    queue: default
    schedule: every minute

The MonitorSchedulerJob runs every minute, checks which monitors are due for testing, and kicks off the Fly.io machine spawning. Monitor runs are background operations - they don't count toward the user's audit quota.

This keeps the architecture simple. One PostgreSQL database handles the queue (via Solid Queue), the application data, and the cache. No Redis to manage, no separate queue infrastructure to monitor.

What We Learned

Lighthouse needs consistent resources. When we first used shared-cpu machines, scores would vary by 15-20 points between runs of the same URL. Bumping to performance-8x brought variance down to 2-3 points. The extra cost per audit is worth the consistency.

Timeouts need multiple layers. We set timeouts at the HTTP level (30s for API calls), the machine level (stop_config timeout), and the application level (mark reports as failed after 5 minutes). Belt and suspenders.

Region availability isn't guaranteed. Sometimes a Fly.io region is temporarily unavailable. We handle this gracefully - the report for that region shows an error, but the rest of the audit completes normally.

Webhook delivery can fail. If our API is temporarily unreachable when the worker finishes, we lose the result. We're adding a retry mechanism and considering having workers write results to object storage as a fallback.

The Numbers

After running this in production since January 2026:

Average audit time: ~2 minutes (single region or all 18)
P95 audit time: ~3 minutes
Machine boot time: 3-8 seconds depending on region
Success rate: ~97% (3% are timeouts or region availability issues)
Cost per audit: $0.01-0.29 depending on regions selected

Try It

You can test this yourself at ahojmetrics.com. Free tier gives you 20 audits/month - enough to see how your site performs from Sydney, Tokyo, Sao Paulo, London, and more.

If you have questions about the architecture, ask in the comments. Happy to go deeper on any part of this.

Built with Rails 8.1, Solid Queue, Fly.io Machines API, and PostgreSQL. Frontend is React + TypeScript on Cloudflare Pages.

Building Ahoj Metrics: Nearly 2 Years, Multiple Rewrites, One Rails SaaS

Yuri Tománek — Mon, 19 Jan 2026 06:05:25 +0000

TL;DR: I spent nearly 2 years building a SaaS that runs Lighthouse audits from 18 global regions in ~2 minutes average. After exploring Go, Rust, and TypeScript, I came back to Rails. Here's the journey, the tech stack, and what I learned.

The Problem

As a developer, I've always struggled to answer one question: "How fast is my site... really?"

Sure, you can run Lighthouse locally. But your MacBook on fast WiFi doesn't represent your users in Sydney on 3G, or customers in São Paulo on a typical mobile connection.

I wanted a tool that could:

Test from multiple global regions simultaneously
Run automated monitoring with alerts
Track performance over time
Be fast and reliable (no 10-minute waits)

Nothing on the market hit all these points at a reasonable price, so in February 2024 I started building Ahoj Metrics.

The Journey: Nearly 2 Years of Iteration

I started this project on February 20th, 2024 with a TypeScript version. Since then, I've:

Rewritten the backend multiple times (lost count honestly)
Explored Go, Rust, and pure TypeScript for the backend
Kept coming back to Rails - I've been using it since version 1.0 in early 2006 (20+ years!)
Completely overhauled the UI 3-4 times

Why did I keep rewriting? I was chasing "the perfect stack." Go felt too verbose. Rust was overkill. TypeScript for backend felt like reinventing the wheel.

Final decision: Rails. I have 20+ years of experience with it, the ecosystem is mature, and I can ship fast. Sometimes the best tool is the one you know deeply.

The Tech Stack

Backend: Rails 8.1

Why Rails? 20+ years of experience, mature ecosystem, fast prototyping
Solid Queue for background jobs (no Redis needed)
Nanoid IDs instead of integers for cleaner URLs and security
Multi-database setup: Primary, Cache, Queue, Cable databases
JWT authentication for API access

Frontend: React + TypeScript + Vite

Hosted separately on Cloudflare Pages for edge performance
Brutalist design system (clean, fast, no-nonsense)
DaisyUI for component primitives
PostHog for product analytics

Infrastructure: Fly.io + AWS ECS

Fly.io Machines API for ephemeral Lighthouse workers, spawn on-demand, test from 18 regions, destroy immediately
ARM64 architecture (Graviton) for cost efficiency
Self-hosted Raspberry Pi runner for CI/CD (4.5x faster builds, $0 cost)

Payments: Polar

Clean API, developer-friendly webhooks
Supports subscription lifecycle (upgrades, downgrades, failed payments)

Key Technical Decisions

1. Ephemeral Workers on Fly.io

Instead of keeping workers running 24/7, we spawn Fly.io machines on-demand using their Machines API.

Here's the actual code:

class FlyMachinesService
  API_BASE_URL = "https://api.machines.dev/v1"

  def self.create_machine(region:, env:, app_name:)
    url = "#{API_BASE_URL}/apps/#{app_name}/machines"

    body = {
      region: region,
      config: {
        image: ENV.fetch("WORKER_IMAGE", "registry.fly.io/am-worker:latest"),
        size: "performance-2x",  # 4 vCPU, 8GB RAM
        auto_destroy: true,      # Key: destroy after completion
        restart: {
          policy: "no"
        },
        stop_config: {
          timeout: "30s",
          signal: "SIGTERM"
        },
        env: env,
        services: []
      }
    }

    response = HTTParty.post(
      url,
      headers: headers,
      body: body.to_json,
      timeout: 30
    )

    if response.success?
      Response.new(success: true, data: response.parsed_response)
    else
      Response.new(
        success: false,
        error: "API error: #{response.code} - #{response.body}"
      )
    end
  end
end

Why this works:

No idle worker costs (only pay for seconds of actual usage)
~2 minute average audit runtime
Scales to 18 regions simultaneously
Clean slate for every test (no cache pollution)
performance-2x size gives Lighthouse enough resources to run smoothly

2. Self-Hosted ARM64 CI/CD

Building Docker images on GitHub-hosted x86 runners using QEMU emulation was painfully slow (18+ minutes).

Solution: Raspberry Pi 4/5 as a self-hosted runner with native ARM64 builds.

Results:

Build time: 4m 25s (down from 18+ min)
Cost: $0/build (vs $0.035/build on GitHub-hosted)
Deploys to AWS ECS Graviton (ARM64)

3. Solid Queue for Background Jobs

Rails 8 ships with Solid Queue, and I leaned in hard:

# config/recurring.yml
production:
  monitor_scheduler:
    class: MonitorSchedulerJob
    queue: default
    schedule: every minute

No Redis, no Sidekiq, no extra infrastructure. Just PostgreSQL.

Jobs run every minute to check which monitors are due for testing, spawn Fly.io workers, and aggregate results.

Challenges & Lessons Learned

1. Quota Management: Simpler Than Expected

Free users get 20 audits/month. I initially overcomplicated this.

Key insights:

An audit is an audit, regardless of how many regions you test
- Test from 1 region? 1 audit consumed.
- Test from 5 regions? Still 1 audit consumed.
Monitor runs don't count toward quota - they only track usage in the background job, not through the quota system
Monitors are only available on paid plans (Starter+) anyway

The tier limits are defined in a simple config:

module HasTierLimits
  TIER_CONFIG = {
    free:       { quota: 20,             retention_days: 30,  monitors: 0,              team_members: 0,              max_regions: 5 },
    starter:    { quota: 100,            retention_days: 90,  monitors: 5,              team_members: 3,              max_regions: 5 },
    pro:        { quota: 500,            retention_days: nil, monitors: 20,             team_members: 10,             max_regions: 5 },
    enterprise: { quota: Float::INFINITY, retention_days: nil, monitors: Float::INFINITY, team_members: Float::INFINITY, max_regions: 18 }
  }.freeze
end

Quota tracking only happens for user-initiated audits:

def track_usage
  period = Time.current.strftime("%Y-%m")
  billable_user = quota_owner  # Team owner or current user
  usage = billable_user.usage_records.find_or_create_by(period: period)
  usage.increment!(:reports_count)
end

2. Multi-Region Testing Architecture

Testing from multiple regions simultaneously is the core feature. Here's how it works:

ReportRequest → Multiple Reports

User creates 1 ReportRequest (e.g., "Test example.com from 5 regions")
System creates 5 Report records (one per region)
5 Fly.io workers spawn simultaneously
Each worker runs Lighthouse and reports back independently
ReportRequest aggregates results and determines overall status

The challenge: handling timeouts, retries, and partial failures.

class ReportRequest < ApplicationRecord
  has_many :reports

  # After each report updates, check if all are done
  def check_completion!
    return unless reports.all?(&:completed?)

    update!(status: "completed")
    update_cached_stats!  # Calculate avg performance across regions
    check_monitor_alert if site_monitor.present?  # Alert if below threshold
  end
end

Key decisions:

Each report is independent (can fail without blocking others)
Cached stats on ReportRequest for fast dashboard queries
Monitor alerts trigger after aggregating all regional results

3. Frontend Performance Matters

We're a performance monitoring tool. If our site is slow, we lose credibility.

Stats (Lighthouse from 18 regions):

Performance: 95-100 across all regions
LCP: < 1.2s globally
CLS: 0.001

How:

Static React frontend on Cloudflare Pages (edge network)
Aggressive code splitting
No heavy frameworks (no Next.js, just Vite)

What I'd Do Differently

1. Stop Chasing Perfection, Start Shipping

This is the biggest lesson. I wasted nearly 2 years rewriting and polishing, trying to build the "perfect" stack and the "perfect" UI.

Then I heard a quote by Eugène Delacroix: "The artist who aims at perfection in everything achieves it in nothing."

That hit hard. I realized that was me - constantly chasing perfection, never shipping.

So I stopped. I gave myself 2-3 days to finish core features, make sure it worked, and shipped it last Saturday. Any issues can be fixed while it's live.

Lesson: Done is better than perfect. Ship, iterate, improve based on real feedback.

2. Stop Rewriting, Use What You Know

I wasted months rewriting in different languages. Go, Rust, TypeScript - none of them were fundamentally better than Rails for this use case.

Lesson: Use what you know. Ship fast. Iterate based on real feedback, not hypothetical performance gains.

3. Start with Waitlist + Landing Page

I built the entire product before validating demand. Bad move.

Better approach: Landing page → waitlist → validate → build MVP.

4. Simpler Pricing Tiers

Four tiers (Free, Starter, Pro, Enterprise) is too many. Should've started with Free + Pro.

5. Public API from Day 1

Everyone asks for API access. Should've prioritized this earlier.

What's Next

Now that it's live, here's what I'm working on:

Webhooks & API - Full REST API for programmatic access and CI/CD integration
CrUX API Integration - Real User Monitoring data from Google's Chrome UX Report
Custom RUM Tool - Installable Real User Monitoring for your own customers
AI Insights - Automated performance recommendations and anomaly detection
Improved Graphs - Better data visualization for performance trends over time
More Regions - Expanding beyond 18 regions to cover more edge locations

Want to see something specific? Let me know in the comments!

Current Status

✅ Launched on ahojmetrics.com
✅ Free tier: 20 audits/month
✅ Paid plans: $35-$299/month
✅ 18 global regions available
✅ ~2 minute average audit runtime
✅ Automated monitoring with alerts
✅ Team collaboration

Try It Out

You can sign up for free at ahojmetrics.com (no credit card required).

Test your site from Sydney, London, Tokyo, São Paulo, and 14 other regions. See how Core Web Vitals, performance scores, and load times differ globally.

I'd love feedback from the dev community! What features would make this more useful for you?

Questions? Drop them in the comments or connect with me on LinkedIn.

Happy to share more details about any part of the stack!