The Ops Community ⚙️: Todd H. Gardner

How to Audit Your Domain's Certificate History (And Why You Should Be Terrified)

Todd H. Gardner — Tue, 28 Oct 2025 18:45:14 +0000

You probably have no idea how many SSL certificates exist for your domains. Or who has them.

Most ops teams track the certificates they issue. Nobody tracks the certificates they didn't issue. The ones from your previous CDN. Your former hosting provider. That contractor who left six months ago. They're all still out there. Still valid.

The BygoneSSL research found 1.5 million domains with valid certificates owned by the wrong people. Your domains are probably in that list.

Time to find out.

Start with Certificate Transparency Logs

Every publicly trusted certificate gets logged. That's good news. It means you can find them.

Go to CertKit Certificate Search and search for your domain. You want to see everything. Not just valid certs. Everything.

What you'll find will make you uncomfortable.

I searched for a client's domain last week. Found over 100 certificates. They knew about 3.

The rest? Old hosting providers. Development agencies. That "quick test" someone ran with Let's Encrypt. A wildcard certificate from their previous CDN that doesn't expire until 2026.

Each one is a potential security incident.

The Vendors You Forgot About

Look at the issuer field for each certificate. See Let's Encrypt? Sectigo? DigiCert? Now ask yourself: who uses those CAs?

That Sectigo certificate from 2023? Probably your old CDN. Still valid for another 200 days.

The Let's Encrypt cert renewed every 90 days? Could be that staging server your contractor set up. The one that's supposedly decommissioned. Except someone's still renewing the certificate.

The DigiCert wildcard? Your previous hosting provider included it "free" with your plan. You moved providers. They kept the certificate.

Check the SANs (Subject Alternative Names)

This is where things get really fun. Multi-domain certificates.

Your domain might be bundled with 50 other domains on the same certificate. Maybe 500. I've seen CDN certificates with over 700 domains.

Here's why that matters: If any of those domains changes ownership, the new owner can revoke the entire certificate. Your site goes down because some random domain on your shared certificate got sold.

The Subdomain Problem

Wildcards are convenient. They're also dangerous.

That *.yourdomain.com certificate you issued two years ago? It works for every subdomain. Including the ones you delegated to vendors. The test environments you forgot about. The staging server that "doesn't exist anymore."

Search for these patterns in your CT logs:

*.yourdomain.com (wildcards)
staging.yourdomain.com
test.yourdomain.com
dev.yourdomain.com
Any vendor-specific subdomains

Each valid certificate is active infrastructure, whether you know about it or not.

Who Can Request Certificates?

This is the question nobody asks. Who can prove control of your domain?

Anyone with access to your DNS
Anyone receiving admin emails
Anyone who can place files on your web server
Anyone with access to your cloud account

That's a lot of people. Current employees. Former employees. Your DNS provider. Your CDN. Your hosting company.

They can all request certificates. Right now. And you won't know until you check the CT logs.

What To Do About It

You can't revoke certificates you don't control. Revocation barely works anyway. But you can minimize future damage.

Immediate steps:

Document every certificate you find. Note the expiration dates.
CAA records. Set them now. Lock down which CAs can issue certificates.
Monitor CT logs. Weekly at minimum. Daily is better. Or monitor them continuously with CertKit.
Rotate credentials after vendor changes. DNS passwords, cloud API keys, everything.

Long term fixes:

Short certificate lifespans. The 47 day certificates everyone's complaining about? They solve this problem. A certificate issued today expires before real damage happens.

Certificate automation. Manual processes can't track this. You need tools that discover, monitor, and manage certificates continuously.

Want to automate certificate discovery and monitoring? CertKit tracks every certificate for your domains, not just the ones you issued. Because the certificates you don't know about are the ones that hurt you.

Let's Encrypt Ate Everyone's Lunch: From 0% to 59% Market Share

Todd H. Gardner — Mon, 06 Oct 2025 21:13:49 +0000

Remember paying $300 for an SSL certificate?

Of course you do. It was 2015. You had a budget line item called "certificates." Purchasing needed three approvals. The renewal reminder went to Dave, who left six months ago.

Then Let's Encrypt showed up and chose violence.

The Numbers Don't Lie

2016: Let's Encrypt had 0.1% market share.
2024: 59%.

That's not growth. That's annihilation.

They didn't just disrupt the certificate industry. They ate it. While the traditional CAs were figuring out how to charge more for wildcard domains, Let's Encrypt was issuing millions of free certificates. Daily. With 90-day lifetimes that forced everyone to automate whether they liked it or not.

Which, surprise, is exactly what we needed for 47 day certificates.

The Business Model That Shouldn't Have Worked

Here's what Let's Encrypt proposed:

Free certificates
No phone support
No sales team
90-day expiration (not the 3-year cash cows)
API-only provisioning
Funded by... donations?

The CAs laughed. Actually laughed.

"Nobody will trust free certificates."
"Enterprises need hand-holding."
"90 days is too short."
"Automation is too complex for normal ops teams."

Turns out normal ops teams were already automating everything else. Adding one more API call? Not exactly rocket science.

The Part Nobody Talks About

Let's Encrypt didn't win because they were free.

They won because they removed the friction.

No sales calls. No "contact us for pricing." No validation documents. No account managers. No renewal reminders. No phone trees. No support tickets.

Just: Here's your cert. See you in 90 days.

We'd been so beaten down by the certificate industrial complex that we forgot what simple looked like.

certbot certonly --webroot -w /var/www/html -d example.com

Done. Cert issued. Automatically renewed until the heat death of the universe.

The Panic Was Delicious

Watch a $600 million industry realize it's been disrupted by a nonprofit:

2016: "It's just for hobbyists."
2017: "Enterprises will never adopt it."
2018: "Our Extended Validation certificates are superior."
2019: "We provide better support."
2020: "Our management platform is worth the cost."
2021: "Please?"

The best part? They started offering free certificates too. But with "premium features." Like what? Support for the free certificates that don't need support because they're automated?

DigiCert bought Symantec's certificate business for $950 million in 2017.

That same year, Let's Encrypt was running on a $2.5 million budget.

And winning.

They Fixed the Wrong Problem

The CAs spent years optimizing the wrong thing. Making certificate purchasing "easier." Building better dashboards. Adding more validation levels.

Let's Encrypt realized the problem wasn't purchasing.

It was that certificates existed at all.

Make them invisible. Make them automatic. Make them someone else's problem (specifically: nobody's problem).

Eight years later, Let's Encrypt issues certificates for most of the encrypted web. Your bank, your cloud provider, probably this blog.

All running on infrastructure that the "serious" CAs said would never work.

Turns out "never" is about 8 years in certificate time.

Why Every DevOps Team Has a Certificate Horror Story

Todd H. Gardner — Fri, 19 Sep 2025 15:40:45 +0000

The Certificate That Ruined Christmas

It was December 23rd, 4:47 PM. Sarah was halfway through her third glass of office party punch when her phone exploded. Production was down. Not slow. Not degraded. Dead.

The wildcard certificate had expired.

The one that covered *.api.company.com, *.admin.company.com, and seventeen other subdomains nobody documented. The renewal script? It had been failing silently for six weeks. The logs? Rotated into oblivion. The person who wrote it? Left for greener pastures in October.

Sarah spent Christmas Eve on a Zoom call with three other engineers, manually generating certificates while the CEO asked "how did this happen?" every fifteen minutes.

Every DevOps team has this story. The details change, but the pain is universal.

The Museum of Certificate Disasters

The Demo Day Special

Picture this: Your CEO is presenting to potential investors. Big screen. Lots of money in the room. Click to the product demo and—browser warning. "Your connection is not private."

Turns out that staging environment you spun up six months ago for "just this one demo"? Its certificate expired yesterday. The renewal was handled by Gary's laptop. Gary's in Bali. Gary doesn't check Slack on vacation.

The CEO improvises. The investors are "concerned about technical operations." You update your resume.

The Acquisition Surprise

Your company just acquired a smaller competitor. Congratulations! You now own:

47 domains nobody has a list of
Certificates from three different CAs
At least six that expired last year but "the sites still work somehow"
A WordPress multisite with a cert that expires tomorrow
No documentation

The previous team's solution? A spreadsheet on someone's desktop titled "certs_final_FINAL_v2_actually_final.xlsx". It was last updated in 2021.

The Prometheus Punishment

You built beautiful monitoring. Prometheus, Grafana, the works. Alerts for everything. CPU, memory, disk space, network latency, even that custom metric for coffee machine status.

The monitoring certificate expired on Tuesday.

Nobody knew because... the monitoring was down.

The Load Balancer Lottery

Three identical load balancers. Same config. Same automation. Same certificate renewal script.

Two renewed perfectly. The third didn't.

Why? Nobody knows. The logs show success. The script returned 0. The old certificate is still being served. You check everything twice. Time zones? Permissions? Phase of the moon?

Four hours later you manually replace it and add "investigate later" to a ticket that will never be investigated.

The Forgotten Fleet

That certificate scanner you ran last month found 73 certificates across your infrastructure. You manage 12 of them. The others?

The printer management interface (apparently it has HTTPS?)
Bob's development VM that's somehow internet-facing
A Grafana instance from a hackathon three years ago
The old CEO's vanity project that "we're definitely shutting down next month" for the past two years
Something called "test-server-do-not-delete-important"

Half expired already. The other half expire next month. None are in your renewal automation.

Why This Keeps Happening

We're smart people. We automate everything. We have CI/CD pipelines that would make NASA jealous. So why do certificates keep biting us?

Because certificate management exists in the gap between "too important to ignore" and "too boring to do right."

It's not exciting like Kubernetes. It's not trendy like observability. It's just... certificates. So we cobble together the minimum viable solution and promise to "revisit this next quarter."

Next quarter never comes. Until 4:47 PM on December 23rd.

The Universal Constants of Certificate Pain

Every certificate horror story shares the same elements:

It's always the one you forgot about. Never the main production cert you monitor obsessively. It's the Jenkins box. The VPN appliance. That API endpoint only accounting uses.

The person who knows is gone. They left for a startup. Or they're on parental leave. Or they just forgot because they set it up three years ago after four beers at the company offsite.

The documentation lies. If it exists at all. That runbook? It references servers that were decommissioned in 2020. The wiki page? Last updated by an intern who "thinks this is how it works."

It happens at the worst possible time. During the big demo. Black Friday. When you're on vacation. When the senior engineer is at a wedding. Murphy's Law was written about SSL certificates.

Breaking the Cycle

Here's the thing: we've all tried to fix this. We've written the scripts. Built the automation. Created the runbooks. Set up the monitoring.

But maintaining certificate infrastructure isn't your job. It's a distraction from your actual job. You didn't become a DevOps engineer to babysit OpenSSL.

That's why we keep having these disasters. We treat certificate management like a side project instead of the critical infrastructure it actually is. We wouldn't run our own power plant. Why are we running our own certificate authority?

Your Horror Story

Every DevOps engineer reading this is nodding along, remembering their own certificate disaster. The one that ruined a weekend. Or a holiday. Or a career.

Maybe it's time to stop collecting these war stories.

Maybe it's time to let someone else worry about whether the certificate renewal script will work next month.

Maybe it's time to stop playing certificate roulette and admit that some problems are worth paying someone else to solve.

But until then? Check your certificates. That Jenkins box is probably expiring next week.

Apple's 47-Day SSL Certificate Plan is Your Next On-Call Nightmare

Todd H. Gardner — Wed, 03 Sep 2025 21:09:04 +0000

Remember when SSL certificates lasted three years?

Pepperidge Farm remembers.

In 2020, Apple decided that was too easy. Now we're heading toward 47-day certificates. Not 45. Not 50. Forty-seven days, because apparently Apple's random number generator picked that one.

Let me walk you through the timeline of how we got here, and why your 2027 is about to become certificate renewal hell.

The Timeline to Madness

The Good Old Days (Pre-2020)

Certificate Lifespan: 3 years (1,095 days)

Life was simple. You'd buy a certificate, install it, set a calendar reminder for 2.5 years later, then forget about it. Sure, sometimes that reminder got lost and production went down, but that was a once-every-three-years problem.

My team managed 200+ certificates this way. One spreadsheet. Quarterly reviews. Bob from accounting could handle renewals. It worked.

September 2020: The First Cut

Certificate Lifespan: 1 year (398 days)

Apple announces at their developer conference that Safari will only trust certificates issued for 398 days or less. Not 365 days like a normal year. 398 days, because Apple.

Google immediately agrees. Mozilla follows. The certificate authorities cave within weeks.

Suddenly, your annual renewal process needs to happen... annually. Revolutionary.

March 2026: The Plot Thickens

Certificate Lifespan: 200 days

"Why stop at one year?" asks someone at Apple who clearly doesn't manage certificates.

Next March—that's in 6 months, people—we drop to 200 days.

200 days. That's a renewal every six and a half months. Your nice quarterly review process? Useless. That junior developer who "figured out the cert stuff"? They're now spending 15% of their time on certificates.

March 2027: Getting Ridiculous

Certificate Lifespan: 100 days

A renewal every three months. Four times a year. Per certificate.

Got 100 certificates? That's 400 renewals annually. That's more than one renewal every single working day.

March 2029: Peak Insanity

Certificate Lifespan: 47 days

Forty. Seven. Days.

Why 47? Who knows. Maybe someone at Apple lost a bet. Maybe it's a Hitchhiker's Guide reference. Maybe they just hate us.

At 47 days, you're renewing certificates eight times per year. Per certificate.

Let's do the math that Apple apparently didn't:

100 certificates × 8 renewals = 800 renewal events per year
800 renewals ÷ 250 working days = 3.2 renewals every single day
Zero room for error
Zero time for vacation
Zero patience left

The Operational Reality Nobody's Talking About

Manual Processes Are Dead

That runbook where you SSH into servers and copy certificates? Dead.

The Ansible playbook Jim wrote in 2019? Dead.

At 47-day intervals, a single failure cascades immediately. Miss one renewal because someone's on vacation? You've got 47 days to catch it. Except you won't, because certificate #2 is expiring tomorrow, and #3 the day after that.

Change Windows Become Impossible

"We only deploy on Tuesdays between 2-4 PM after CAB approval."

Cool story. Your certificates expire when they expire. That carefully planned change management process? It's about to meet the reality of 8x more certificate deployments.

Your options:

Get blanket approval for certificate renewals (good luck with that audit)
Automate everything (should've started yesterday)
Watch everything burn (honestly, might be easier)

The Hidden Costs Multiply

Every certificate renewal isn't just swapping a file:

Load balancer configs need updating
CDN certificates need propagation
Service restarts risk downtime
Monitoring needs to verify the update
Documentation needs to reflect changes

At 47 days, you're doing this dance constantly. Forever. Until you die or change careers.

The Tools Are Not Ready

Your $50,000/year monitoring platform that "supports everything"? Doesn't support 47-day automated rotation.

Your enterprise load balancer? Manual process only.

Your CDN? API supports updates, but rate-limits you to 10 changes per month.

Your managed Kubernetes service? Actually, they're probably fine. But everything else is screwed.

What This Actually Means for Your Team

Staffing Reality

At 47-day certificates, certificate management becomes a full-time job. Not hyperbole. Actual math:

200 certificates × 8 renewals × 30 minutes per renewal = 800 hours/year
That's 0.4 FTE just for basic renewals
Add troubleshooting, failures, and coordination: 1.0 FTE minimum

Congratulations, you're hiring a Certificate Engineer. That's a real job title now.

Automation Isn't Optional Anymore

"We'll automate it eventually" becomes "We automate it or we die."

But here's what automation actually means:

Rewriting deployment pipelines
Updating every system configuration
Building certificate discovery tools
Creating fallback procedures
Testing failure scenarios
Training everyone on the new process

Conservative estimate: 6-12 months of engineering work. For certificates. The things that used to just work.

The Path Forward (Since Apple Won't Stop)

Option 1: Full Automation or Death

Invest heavily now. And I mean now. Not next quarter. Not after the current sprint.

Build certificate automation that:

Handles every system, not just the easy ones
Fails gracefully with automatic rollbacks
Alerts intelligently without noise
Scales to thousands of certificates
Works with your legacy nightmare systems

Option 2: Managed Certificate Services

Give up. Pay someone else. Let it be their problem.

Whether it's your CDN provider, a managed certificate service, or something we built because we're equally frustrated, the point is: stop pretending this is sustainable.

Option 3: Proxy Everything

Put all your certificates at the edge. Cloudflare, Akamai, whatever. Let them handle the 47-day nonsense. Your internal systems keep their self-signed certs that last forever.

Not elegant. Not ideal. But it works.

The Part Where I Stop Complaining and Admit Reality

Look, I get it. Shorter certificate lifespans increase security. Compromised certificates have less time to cause damage. Automated systems are more reliable than manual processes. In theory.

But theory and practice are only the same in theory.

In practice, we're forcing massive operational changes on an industry that still runs COBOL in production. We're expecting perfect automation from companies that can barely keep their primary systems running. We're creating complexity that will cause more outages than it prevents.

Your Action Items for This Week

Count your certificates. All of them. Including that test server everyone forgot about.
Calculate your renewal burden. Multiply by 8 for the 2027 reality.
Start the automation discussion. Today. Not tomorrow.
Budget for tooling. You're going to need it.
Update your resume. Just in case.

The 47-day certificate apocalypse is coming whether we're ready or not. Apple's decided. Google's agreed. The certificate authorities are implementing it.

We built CertKit because we saw this coming and decided to do something about it. But whether you use our solution, build your own, or just pray to the certificate gods, you need to act now.

Because in 2029, while you're renewing certificates for the third time this month, remember: Apple thinks this is making the internet "more secure."

Sure it is.

How are you preparing for 47-day certificates? Drop your horror stories and survival strategies in the comments. Misery loves company, and we certificate wranglers need all the help we can get.

Monitoring Web Performance: Why Your Synthetic Tests Aren't Telling the Whole Story

Todd H. Gardner — Thu, 05 Jun 2025 15:52:00 +0000

As DevOps and SRE professionals, we're obsessed with monitoring everything. We track server metrics, application performance, and infrastructure health. But when it comes to web performance monitoring, many of us are flying blind without realizing it.

Here's a reality check that might surprise you: Google's research found that 50% of websites with perfect Lighthouse scores still fail Core Web Vitals when measured with real user data. 🚨

If you're relying solely on synthetic testing for web performance insights, you're missing critical production issues that could be impacting your users and your SLAs.

The Synthetic Testing Trap in Production Environments

Most of us use Lighthouse, WebPageTest, or similar tools in our CI/CD pipelines. These synthetic tests are great for catching obvious performance regressions before deployment, but they have serious limitations in production monitoring:

🔧 Controlled Environment Bias

Synthetic tests run in perfect conditions: clean networks, consistent hardware, no browser extensions
Real users deal with network congestion, device thermal throttling, and competing background processes
Your CDN might perform differently across geographic regions, but synthetic tests typically run from a single location

⚙️ Infrastructure Reality Gap

Synthetic tests can't simulate real database load, API response times under actual traffic, or third-party service degradation
Auto-scaling events, container restarts, and network partitions affect real users but won't show up in synthetic testing
Load balancer behavior and cache performance vary significantly between synthetic and production traffic

📊 Missing Context for SLA Management

Synthetic tests give you a single data point, not user segment analysis
You can't correlate performance issues with business metrics or user behavior
No visibility into how performance affects conversion rates or user retention

Real User Monitoring: Production Observability for Web Performance

Real User Monitoring (RUM) works by embedding a lightweight JavaScript agent in your web application that collects performance data from actual user sessions. Think of it as APM for the frontend.

How RUM Fits Your Monitoring Stack:

// RUM collection happens passively using browser APIs
const observer = new PerformanceObserver((list) => {
  list.getEntries().forEach((entry) => {
    // Send real user metrics to your monitoring platform
    sendToMonitoring({
      type: entry.entryType,
      duration: entry.duration,
      timestamp: entry.startTime,
      userAgent: navigator.userAgent,
      connectionType: navigator.connection?.effectiveType
    });
  });
});

observer.observe({ type: 'navigation', buffered: true });
observer.observe({ type: 'long-animation-frame', buffered: true });

Or use a tool that figures all this out for you, like Request Metrics

What RUM Reveals That Synthetic Testing Misses:

⚡ Production Load Reality - How your application performs under actual traffic patterns, database load, and infrastructure stress

🌍 Geographic Performance Variations - CDN effectiveness, edge performance, and regional infrastructure issues that affect different user segments

📱 Device & Network Diversity - Real device performance from your actual user base, not simulated conditions

🔄 Progressive Degradation - Performance issues that develop over time or during specific traffic patterns

Implementing RUM in Your DevOps Workflow

Integration with Existing Monitoring:

Most RUM tools can export metrics to DataDog, New Relic, or your existing observability platform
Set up alerts based on Core Web Vitals thresholds and business impact metrics
Correlate frontend performance with backend APM data for full-stack visibility

Infrastructure Considerations:

RUM agents typically add <10KB to your bundle size
Use CSP policies to ensure secure data collection
Consider GDPR compliance for user data collection in your deployment regions

The Complete Monitoring Strategy

Don't abandon synthetic testing—use both approaches strategically:

Development & CI/CD:

Synthetic tests in your pipeline to catch regressions before deployment
Performance budgets as part of your deployment gates
Consistent baseline measurements for A/B testing infrastructure changes

Production Monitoring:

RUM for continuous real-user performance monitoring
Business impact correlation and SLA tracking
Geographic and device segment analysis for capacity planning

Incident Response:

RUM identifies performance issues affecting real users
Synthetic tests help reproduce and debug specific problems
Combined data provides complete picture for post-incident reviews

Tool Selection for Operations Teams

When evaluating RUM solutions, consider:

✅ Integration capabilities with your existing monitoring stack

✅ Real-time alerting that integrates with PagerDuty/OpsGenie

✅ Geographic data collection for multi-region deployments

✅ Custom metrics for business-specific performance indicators

✅ Privacy compliance features for global deployments

Getting Started

Start small: Implement RUM on your most critical user flows first
Baseline performance: Establish current real-user performance metrics
Set meaningful alerts: Focus on business impact, not just threshold crossings
Iterate and expand: Add more pages and metrics based on initial insights

The biggest surprise most teams discover? Performance issues they never knew existed, often affecting their most valuable user segments.

For a comprehensive deep-dive into RUM implementation, business impact analysis, and tool selection criteria, check out this detailed guide: Why You Need Real User Monitoring to Really Understand Your Web Performance

Discussion Questions for the Community:

🤔 How do you currently monitor web performance in your production environments?

🚀 Have you found gaps between your synthetic test results and actual user complaints?

⚙️ What's your experience integrating frontend performance monitoring with your existing observability stack?

Drop your war stories and tool recommendations in the comments! 👇

HTTP Caching for DevOps: Supercharge Site Performance Without Code Changes

Todd H. Gardner — Fri, 28 Feb 2025 17:06:02 +0000

Let's face it: developers get the glory for performance wins, but often it's us ops folks configuring the servers who can make the biggest impact. HTTP caching is the perfect example - a few server configuration tweaks can dramatically reduce load and improve user experience without touching application code.

Server-Side Caching Configuration 🚀

Different web servers have different syntax, but the goal is the same: properly configured HTTP headers. Here are the magic incantations for common servers:

Nginx

# Inside server or location block
location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
   expires 1y;
   add_header Cache-Control "public, max-age=31536000, immutable";
}

# For HTML with validation
location ~* \.html$ {
   add_header Cache-Control "public, max-age=300, must-revalidate";
}

Apache

<FilesMatch "\.(jpg|jpeg|png|gif|ico|css|js)$">
   Header set Cache-Control "public, max-age=31536000, immutable"
</FilesMatch>

<FilesMatch "\.html$">
   Header set Cache-Control "public, max-age=300, must-revalidate"
</FilesMatch>

Monitoring Cache Effectiveness

How do you know if your caching strategy is working? Look at these metrics:

Cache Hit Ratio: Percentage of requests served from cache vs origin
Bandwidth Savings: Reduced egress traffic from your servers
Server Load Reduction: Fewer requests hitting your application

Pro tip: Set up a dashboard tracking HTTP status codes - you want to see lots of 304s!

Cache Validation: The DevOps Secret Weapon

Smart validation configuration can reduce server load dramatically:

# Enable ETags in Nginx
etag on;

# Apache ETags (already enabled by default)
FileETag MTime Size

Proper ETag configuration means your server can respond with lightweight 304 responses instead of full payloads.

CDN Integration Strategy

Your CDN's cache behavior must align with your origin headers. For Cloudflare:

# Cache Everything rule with Edge TTL:
cache_everything: true
edge_cache_ttl: 2592000

This two-tier caching approach (browser + CDN) creates a performance multiplier effect!

For more details on HTTP caching implementation patterns, check out my comprehensive HTTP caching guide covering both developer and operational aspects.

What server-side caching optimizations have you implemented? I'd love to hear your experiences!

GTMetrix Alternatives: Why You Need More Than Just Synthetic Testing

Todd H. Gardner — Thu, 27 Feb 2025 15:56:31 +0000

GTMetrix has been a go-to tool for website performance testing for years. It runs a synthetic test, gives you a score, and tells you whether your site is fast or slow. Simple, right?

Except synthetic tests don’t reflect real-world performance.

GTMetrix runs tests in ideal conditions—clean network, no background tasks, no real user interactions. But real visitors:

Load your site on unreliable mobile networks
Get hit with third-party scripts slowing things down
Experience delayed interactions and layout shifts

If GTMetrix tells you your site is fast, but your real users still struggle, you need better insights than synthetic tests alone can provide.

Why Synthetic Testing Isn’t Enough

Synthetic tests generate lab-based results, which are great for debugging but fail to capture real-world bottlenecks. A perfect synthetic score means nothing if your actual users are waiting for elements to load or watching buttons shift just as they try to click them.

The better approach? Synthetic Testing + Real User Monitoring (RUM) + Google’s Chrome UX Report (CrUX).

Synthetic Testing runs performance tests in a controlled environment.
Real User Monitoring (RUM) collects performance data from actual visitors.
CrUX pulls real-world Core Web Vitals from Chrome users.

Best GTMetrix Alternatives Right Now

If you’re running a mid-sized website with 500,000 page views per month, here’s how GTMetrix competitors compare:

1. PageSpeed Insights (Free & Simple)

💰 Free and backed by Google

Uses real Chrome UX Report (CrUX) data
No real-time monitoring

2. WebPageTest (Advanced & Free)

💰 Free with detailed synthetic test options

Supports network throttling, waterfall charts, and filmstrip views
No real user monitoring
Slow to run tests

3. Request Metrics (Synthetic + RUM in One Dashboard)

💰 $88/month for full monitoring

Learn more about Request Metrics

Combines Synthetic Testing + Real User Monitoring (RUM) + CrUX
Tracks real Core Web Vitals from actual visitors
Automates synthetic tests on your busiest pages

4. Pingdom (Integrated Uptime)

💰 $130/mo - Uptime & Basic RUM

Uptime monitoring + RUM
Limited synthetic testing flexibility

5. Speedcurve (Advanced custom reporting)

💰 $143/mo

Combines synthetic + real user monitoring
Highly customizable dashboards and reporting
Steep learning curve—complex reports can be difficult to configure

SpeedCurve offers deep performance insights, but the custom reporting system is difficult to interpret. If you need quick, actionable data, other tools may be easier to work with.

Final Thoughts

GTMetrix was great when it was free, but paying for one-off synthetic tests doesn’t make sense anymore.

If you need quick lab tests, use PageSpeed Insights or WebPageTest.
If you want to track real-world performance, go with Request Metrics ($88/mo).
If you need uptime alerts & monitoring, Pingdom is an option.
For deep custom reporting, SpeedCurve delivers—but expect a learning curve.

📖 Read the full breakdown here:

👉 GTMetrix Alternatives: The Best Tools for Website Performance

Website Image Optimization: Speed Up Your Site with Better Image Handling

Todd H. Gardner — Wed, 05 Feb 2025 17:45:05 +0000

Images make websites engaging, but they’re also one of the biggest performance killers. Large, unoptimized images slow down page loads, hurt SEO, and wreck Core Web Vitals. If your site feels sluggish, image bloat is probably to blame.

Optimizing images can dramatically improve load times while keeping your website visually sharp. Here’s a quick breakdown of how to make images load faster.

For a full deep dive, check out the complete guide:

➡ How to Optimize Website Images

📸 Use the Right Image Format

Not all image formats are efficient:

✔ JPG (JPEG) – Best for photos, small size with lossy compression.

✔ PNG – Best for graphics & transparency but large files.

✔ WebP – Smaller than JPG/PNG, great for most images.

✔ AVIF – Best compression, but not universally supported yet.

Use a CDN to automatically serve WebP/AVIF when supported.

⚡ Compress and Optimize

Uncompressed images waste bandwidth. Shrink files using:

✅ TinyPNG, ImageMin, or Squoosh for lossy compression.

✅ Strip metadata (EXIF, camera details) to remove extra bloat.

Even minor compression can cut image size by 50% or more.

⏳ Lazy-Load Below-the-Fold Images

Prevent unnecessary downloads using:

<img src="image.jpg" alt="Optimized Image" loading="lazy">

This improves Largest Contentful Paint (LCP) by focusing resources on critical images.

📱 Serve Responsive Images

Don’t make mobile users load huge desktop images. Use srcset and sizes:

<picture>
  <source 
    srcset="image-700.jpg 700w, image-1200.jpg 1200w" 
    sizes="(max-width: 1200px) 100vw, 1200px">
  <img src="image-1200.jpg" alt="Optimized image">
</picture>

This delivers the right size image for every screen.

🚀 Cache and Deliver Images Efficiently

✔ Use a CDN – Faster global delivery.

✔ Enable HTTP/2 or HTTP/3 – Loads images in parallel.

✔ Set caching headers – Prevents unnecessary re-downloads.

Cache-Control: public, max-age=31536000, immutable

📌 Final Thoughts

Optimizing images is an easy win for site speed and SEO.

Use efficient formats (WebP, AVIF)
Compress and lazy-load images
Serve responsive images for mobile
Host images with CDNs & caching

For detailed steps, check out the full guide:

➡ How to Optimize Website Images

How to Fix Long Animation Frames (LoAFs) and Speed Up Your Website

Todd H. Gardner — Mon, 21 Oct 2024 17:50:00 +0000

If your website feels sluggish or unresponsive during animations, you’re likely dealing with Long Animation Frames (LoAFs). LoAFs occur when a single animation frame takes longer than 50 milliseconds to render, causing stuttering, lag, or what developers often call “jank.”

The problem is, LoAFs aren’t immediately visible in Chrome DevTools by default. However, you can use the PerformanceObserver API to track and analyze them in real time, helping you identify what’s slowing down your animations.

One of the primary causes of LoAFs is heavy JavaScript execution. Long-running scripts block the main thread and prevent the browser from rendering frames efficiently. To resolve this, break up long tasks into smaller chunks and spread them across multiple frames using setTimeout or other techniques to give the browser time to process animations smoothly.

Another common culprit is forced synchronous layouts, which happen when you modify the DOM and immediately read layout properties like offsetWidth or scrollHeight. To avoid this, batch your DOM reads and writes to minimize layout recalculations, or use transform for animations to avoid triggering expensive reflows.

For modern web apps like Single Page Applications (SPAs), optimizing component re-renders and deferring non-essential JavaScript using code-splitting can also help reduce LoAFs and improve the user experience.

For a more detailed breakdown of how to diagnose and fix Long Animation Frames, check out the full post on LoAFs and how to optimize them here.

Our Super Friendly AI Sloth that Analyzes Your Observability Data

Todd H. Gardner — Mon, 15 May 2023 00:00:00 +0000

Seems like everyone is building a ChatGPT thing right now, doesn’t it? Well we are too! Inspired by so many others, we decided to see what AI could do with our simplified analytics and observability data.

Turns out, it can do quite a lot.

I’m thrilled to share that we’ve shipped our first AI insights chatbot, Professor Sloth. With this ChatGPT-powered AI Assistant, Request Metrics is taking data analysis to the next level by helping you spot anomalies, suggesting courses of action, and guiding you towards valuable insights.

But this wasn’t without it’s challenges…

Prompt Engineering Challenges

Integrating OpenAI’s ChatGPT into Request Metrics proved to be an interesting challenge, particularly when it came to the emerging problem of prompt engineering. To get correct and interesting results, we had to talk to this supremely powerful AI like it was a first-grade math student. Phrases like “go slow”, “check your work”, and “let’s take this step by step” litter our prompts.

Without these statements, we found that ChatGPT would often outright lie to us, reporting median values that weren’t in the dataset, or reporting trends that were not statistically relevant. Much like guiding a young learner, it was essential to provide clear instructions and set expectations to ensure that ChatGPT could understand and analyze the data effectively.

With a little care and patience, this approach allowed us to harness the power of AI while maintaining a high level of accuracy and relevance in the insights generated by Professor Sloth.

Professor Sloth and Data Analysis

Incorporating an AI Assistant like Professor Sloth into your data analysis workflow offers numerous advantages. Here are some benefits we’ve observed while using Professor Sloth:

Anomaly Detection

Professor Sloth can quickly spot anomalies in your data, helping you identify potential issues and areas for improvement. This can save you time and effort by automating the initial data exploration process. Here’s an example where the professor found an API Endpoint anomaly, and pointed out that they are all SVG file requests.

Actionable Recommendations

Our ChatGPT-powered AI Sloth suggests courses of action based on the data it analyzes. This helps you make informed decisions on where to invest your resources and how to improve your website’s performance. Here’s an example where it found the largest web analytics sources of traffic, and recommended additional focus.

Guided Analysis

Professor Sloth recommends additional data analysis steps to help you dive deeper into specific areas of interest. This can be particularly useful when you’re unsure where to start or need help identifying new avenues for exploration.

Here, Professor Sloth suggested some geographic filters to get more relevant data, focusing on US and German traffic.

Ongoing Training for Professor Sloth

Currently, Professor Sloth is available in a handful of locations throughout the Request Metrics UI. However, we have big plans for our AI Assistant. In the coming weeks, we’ll be expanding its presence within the platform and teaching it about more types of data.

As the AI APIs continue to evolve, we hope to expand Professor Sloth’s chat capabilities, allowing you to ask further questions about your data and receive even more personalized insights. With this ChatGPT-powered feature, we aim to make data analysis more accessible, efficient, and enjoyable for all users.

Conclusion

Professor Sloth shows off the power and potential of AI integration in data analysis. By overcoming the challenges of prompt engineering and leveraging the capabilities of OpenAI’s ChatGPT, we’ve created a valuable tool that can revolutionize the way you approach your website’s data.

With Professor Sloth, you’ll gain access to anomaly detection, actionable recommendations, and guided analysis, all powered by cutting-edge AI technology. As we continue to expand and evolve this feature, we’re confident that Professor Sloth will become an indispensable asset in your quest for data-driven insights and website optimization.

Ready to try it out? Check out our live sandbox and see what Professor Sloth has to say about the data. Or sign-up for Request Metrics free and get AI-powered insights on your own analytics and observability data!

Expanding Our Vision: Unifying Client-Side Observability Data

Todd H. Gardner — Thu, 11 May 2023 00:00:00 +0000

In 2021, we started Request Metrics as a simple and developer-friendly service to measure and improve web performance. We built an incredible platform that distilled complex data down into simple reports and recommendations. Lots of teams around the world found valuable insights in Request Metrics that they couldn’t get anywhere else.

But web performance data can be very unpredictable—the web slows down in all sorts of ways. When one of our customer’s pages slowed down, or their Core Web Vitals slipped, we ran into 2 big limitations:

First, does this delay matter to my user? Did it cost me a sale? Do I need to fix it right now? We couldn’t answer these questions because we didn’t have enough context about what the user was trying to do.

Second, what is causing this thing to be slow? We can’t always recreate the problem in our local environments, and we didn’t have deep enough data to debug individual sessions.

To address these problems, we needed to think bigger!

A Challenge Beyond Web Performance

The limitations we faced aren’t limited to web performance. When there’s a JavaScript error, how do we know if it has user impact? When an API is failing, does it halt the checkout flow? When a user is interacting, which components do they depend on?

Today, this data is scattered across various kinds of tools, such as product analytics, error reporting, API observability, performance, and security monitoring. There is so much power to be unlocked by bringing this data together, and that’s exactly what Request Metrics is going to do.

The Client-Side Observability Platform

Our goal for Request Metrics is to bring these disparate pools of data together—to unify client-side data and reveal the correlations between user intent, product analytics, and system monitoring.

Imagine getting an alert with this context:

3 API endpoints are returning higher 500 responses than normal, and form submissions for impacted sessions are down by 75%.

We are going to combine operational problems with user impact so that we can focus on the problems that really impact our users, and cut out the noisy background radiation of the web.

Accelerating and Expanding Observability

Many monitoring products need to understand your entire infrastructure—every service, database, and backend resource you depend on. To get that, you have to deploy agents, make code changes, or use specific platforms. It’s a huge upfront cost and many small teams can’t justify it. We’re approaching the problem differently.

What if we approached observability from what the real users see, instead of our infrastructure? And what if we made the setup so easy that any engineer could do it in 1 minute. What if you could copy-paste a single bit of JavaScript into your page and get visibility into everything the user touches? That’s what we’re building: turnkey analytics and observability from the client-side.

Security and Privacy in Analytics

Many security-focused organizations are unable to use cloud services for potentially sensitive data, and have been left behind by modern analytics and monitoring vendors.

That’s why we’re making Request Metrics ready to be installed on-premise, or in your private cloud. A single install, package, and vendor to manage that can give you monitoring visibility across your teams.

Oh, and because we don’t drop a cookie or track anything identifiable about the end user (dropping IP and user agent on ingest), we’re fully GDPR compliant and ready to use anywhere you need visibility.

The Road Ahead

We have an ambitious vision, and we’re diligently working to make it a reality over the remainder of this year. Today we’ve already shipped Session Analytics, with the ability to dive into a full session timeline for users. We’re expanding our performance tools into full User Experience monitoring, allowing you to dig all the way into individual load timings and waterfalls. As well as API observability, tracking the traffic, responses, and performance of your first party and third-party API calls.

Soon, you’ll see security and website integrity reports added, so we can tell you when naughty JavaScript sneaks into your code or tries to steal data from your users. We’ll also be bringing a JavaScript error reporting component, and expanding analytics to include custom events and user journeys. There is so much great stuff coming!

Conclusion

Request Metrics is a new kind of dev tool: focused on the user experience of your site, doing more of the thinking for you, and exposing when weird things happen in your system. You shouldn’t have to feed your dev tools queries, it should just give you answers. We’re excited to make it happen and help you make better, faster software. Sign up for a free trial of Client-Side Observability.

Explaining Performance to Non-Technical Stakeholders

Todd H. Gardner — Tue, 13 Sep 2022 08:00:00 +0000

Whether you’re an e-commerce company, a SaaS provider, or a content publisher, understanding the performance of your website is important to everyone on the team—not just the developers. Performance is a huge part of the user experience and directly tied to how well your website achieves its goals. But web performance is often measured in very technical terms, like Largest Contentful Paint, that cause most business folk’s eyes to glaze over.

This language gap is a big part of the reason why many websites are so slow. Many only consider performance from their own perspective—“it’s fast for me”—and leave it at that. We simply lack the vocabulary to talk about the problem.

To effectively talk about web performance with everyone on the team, you have to break through the jargon and talk about what really matters: the experience of the real users and how that impacts the business. Here’s a few ways to do that:

Push what’s Important

Performance is rarely top of mind, and it’s unlikely anyone will go looking for it unless a user is complaining. Most users don’t complain—they just leave.

To keep your users, you need to know about performance before it gets bad. You need to know when it’s important.

At Request Metrics, its our job to figure out what’s important and push the relevant information to you. We examine all your web performance data and push a summary to your inbox with what you need to know.

Download the full report PDF.

And to make it sharable, we publish it as a PDF so that you can forward it on to your client, your boss, or the executives in charge.

BLUF: Bottom Line Up Front

This old military acronym is about getting right to the most important information first—lives could depend on it!

Your situation is (probably) not that dire, but the advice stands. If the most interesting performance anomalies are buried three clicks deep, it’s unlikely to be discovered.

At Request Metrics,we expose the interesting things in plain language at the top of all of our reports and dashboards.

Plain language descriptions of performance in Request Metrics.

This takes the burden off the developer to interpret the data for their team. We can plainly state what’s happening, backed up with data.

Describe Metrics as User Impact

Web performance metrics are highly technical and confusing—even to developers. If you don’t understand what Cumulative Layout Shift is measuring, its hard to care that the score isn’t good.

Instead, start the conversation with the user impact of the metric, like “the website has a lot of frustrating shifting of content for 75% of our users”

Performance can be a powerful way to make your websites better and more effective—but only if you know how to have the conversation. Remember to Push what’s important to your stakeholders, put the bottom line up front, and describe metrics in terms of user impact. If you have the real user data and reports from Request Metrics, that will help.

Have a look at the example performance report and see how it can help drive the performance conversation on your team.