The Ops Community ⚙️: Request Metrics

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.

Audit Google Ad Performance With Lighthouse

Todd H. Gardner — Mon, 01 Aug 2022 08:00:00 +0000

Implementing Google Ads can be complicated. If done incorrectly, it negatively impacts your website's performance. Fortunately, there is a new Google Lighthouse plugin tailored specifically to find problems with your Google ad implementation.

Google Publisher Ads Plugin

Publisher Ads Audits for Lighthouse is a plugin created to help surface issues with your Google ads setup. It's open source and hosted on Github. It's currently developed specifically for users of Google Ad Manager and uses a series of automated audits to spot problems.

Running the Plugin From Chrome

To get started simply open the Chrome Developer tools and navigate to the Lighthouse tab. You'll find a (beta) Community Plugin called Publisher Ads.

It can be run like any other Lighthouse audit - either on its own or in combination with the other audits available.

Running the Plugin on the Web

If you don't use Chrome, Google helpfully hosts a web page that can run the Publisher Ads audits as well. This is useful to get a second datapoint other than your own browser. You can find it here: https://developers.google.com/publisher-ads-audits/

Publisher Ads In Action

When we previously discussed Google ad performance impact, we looked at a few sites which saw a large slowdown when ads were enabled. One of those was CNN.com. We decided to see what the plugin could tell us about the ad setup on their site.

CNN.com Audit Results

Like most of the Lighthouse audits, the site is given an overall score, and then individual audit problems are surfaced below.

Duplicate Tag Loads

CNN is loading the exact same Google Publisher tag twice. This is needlessly wasteful of bandwidth and impacting load time.

Parallel Bid Requests

We also see that CNN is gathering bid requests in serial, and could potentially make both of those bid requests at the same time to speed things up.

Slow Requests Blocking Your Ads

Ads aren't always slow because of ad providers alone. Oftentimes other resources on your site will block the ad requests from doing their work. The Publisher Ads plugin will also show you which resources are blocking your ads from completing.

Many Helpful Suggestions

Publisher Ads contains over 20 audits in related to Google ads and common implementation mistakes. Not only will it show you which audits fail, but also which pass, and by how much.

Conclusion

The Publisher Ads Lighthouse audit is a great way to get started with optimizing your Google ads implementation. It suffers from the same issues all synthetic tests have, but it should certainly be a part of your ongoing Google ad performance monitoring.

Another part of your strategy should be monitoring your site's performance with Request Metrics. We'll tell you whether your changes are having a meaningful impact on your actual users, and not just in Google Lighthouse.

How To Read Flame Charts and Percentiles

Todd H. Gardner — Mon, 25 Jul 2022 08:00:00 +0000

Charting can be complicated and intimidating, especially when dealing with web performance data, flame charts, and percentiles. There is so much data crammed together! Why are the numbers all different?! Let’s break down these charts, what they are good for, and when to use them.

Flame Charts

A flame chart uses a stacked colored bar chart to show both the number of users and their performance for a given time. It is usually a histogram, showing how the data changes over time. Here’s an example of a flame chart from a Request Metrics page load performance report.

Each bar (or flame) shows the total number of visits to the page. The relative size of each color shows the performance experienced by users. Cooler colors usually mean “faster” performance, while warmer colors are slower.

Flame charts are useful to see big changes in your performance. For example, the flame chart below shows the last 90 days of load performance data for a page. The increasing size of the flames shows that the traffic is increasing each week. The flames are also getting warmer, with less blue and more red, telling us that the page is slowing down under the increased traffic.

Flame Charts Are Bad for Small Changes

Flame charts are a great tool for showing big trends, but it can be hard to spot subtle changes in them. It’s difficult for most people to spot small changes in a color distribution. Take this flame chart for instance. There was a performance improvement made around June 20th. Can you spot it? I can’t.

This is where percentiles become really useful.

Percentiles

Hang on, we’re going to channel some of that 7th grade math class you slept through. Let’s say you’ve gathered a bunch of time-to-load performance data. If you sort that data from fastest to slowest, it might look like like the table below.

Load Time
1s
1s
1.5s
1.6s
1.7s	Median
2.2s
3.1s
3.7s	75th percentile
4.1s
12s	95th percentile

The value that fits in the “middle” of the data, so that half of the data is faster and half is slower, is called the median , or 50th percentile. This value is useful because it says, “half of my users had performance better than this”.

The 75th percentile, or 75% of the data is faster, is very useful for web performance data because it shows you what most users will see as the worst-case.

The 95th percentile, where 95% of the data is faster, shows us what the slowest users experience.

Why not use the slowest data?

A lot of crazy stuff happens on the web. The slowest data in most real-world reporting is usually unrealistically slow. It’s often bad data being reported from bots, bugs, or suspended pages: generally stuff you don’t care about. Using the 95th percentile trims off this bad data and gives you the slowest realistic performance experience.

Let’s look back at our “small change” example. If we chart the data as percentiles rather than a flame chart, we can see smaller patterns. In this example, load time performance gets a touch faster on June 20th.

This pattern is visible on all three charted percentiles, so the page got a touch faster for everyone. Nice work team.

The danger of averages

When trying to interpret a pile of data, it is tempting to look at the averages, but this can be very misleading. Averages will smooth out interesting patterns and hide the true experiences of the fastest and slowest users.

The average load time for the data is about 3.2 seconds, a time that doesn’t really reflect the fastest users, slowest users, or even the majority of users. Producing a few percentiles is much more informative.

Check out more about the averages and performance statistics in chapter 2 of the Definitive Guide to Measuring Web Performance.

Why gather the data and do the math yourself though? This is what Request Metrics is made for! Let us report on your end user performance and give you exactly the reports you need to make your website fast. I bet you’ll love it.

Google Ads Are Slowing You Down

Todd H. Gardner — Mon, 18 Jul 2022 08:00:00 +0000

Google has a well earned reputation for speed. At least on their own sites. It’s an entirely different story when it comes to their ad network. Google ads are slowing down thousands of sites across the internet.

Google Ads in Action

Regardless of what you think of their content, CNN is one of the most popular sites on the internet - and they use Google Ads. There is a large Google-served banner advertisement at the top of the page. It often pops in seconds after the rest of the site has rendered. This ad dramatically slows page load and causes a large layout shift which irritates users and could hurt their search rankings.

CNN.com Banner Ad Example

Google Ads Are Everywhere

It’s easy to pick on cnn.com, but Google ads are ubiquitous. They’re served up everywhere, especially in the media industry, and they’re causing performance issues.

For this post we’re going to focus on these major news sites: nytimes.com, cnn.com, foxnews.com, wsj.com, and espn.com. Every one of them has at least one Google ad on the page.

The goal is to find out what impact, if any, do Google ads have on their web performance?

Measuring the Performance Impact of Google Ads

The best way to measure the performance impact of Google ads on a site like cnn.com would be to run A/B tests with Google ads on and off, over a diverse cross section of users. But we don’t work for CNN and don’t control their ads (the site would be faster if we did) so we have to use the tools available to us.

The Test Setup

In order to A/B test the web performance of sites with and without Google ads, we’re going to use Puppeteer. This is a tool from Google that allows us to automate Chrome with code.

To attempt some level of fairness, each site will be loaded 10 times with Google ads enabled, and 10 times with Google ads blocked. The browser’s cache will be disabled, and we’ll alternate between loading with ads, and loading without, in an attempt to smooth over any network hiccups.

Rather than blocking all ads on the page (some of these sites are using more than one provider), we’re only going to block those domains belonging to Google. Puppeteer allows us to inspect every outgoing request, and block it as we see fit.

The load times of each page will be pulled directly from the window.performance API in the browser. We’ll also grab the Cumulative Layout Shift to see if Google ads are having a negative effect on The Core Web Vitals as well.

Slow Going

After gathering data from all the sites - with ads and without - the results were clear. Google ads had a negative impact on the performance of every site tested. In most cases a sizably negative impact.

Load Performance Results

Site	No Ads	With Ads	Impact
espn.com	2.9s	3.5s	1.2x slower
nytimes.com	2.5s	3.5s	1.4x slower
cnn.com	7.0s	16.7s	2.4x slower
foxnews.com	4.6s	16.2s	3.5x slower
wsj.com	2.8s	14.8s	5.3x slower

Load Times With and Without Google Ads

ESPN had the lowest impact from Google ads - seeing only a 20% increase in load time when ads were enabled. On the other end of the spectrum, load times for the Wall Street Journal were a whopping 5.3x slower with ads vs. without.

CNN escaped with a medium impact score, but only because they notched the worst absolute load times both with and without ads.

Overall, it’s evident that running ads from Google on your site will slow things down.

Layouts are Shifting Too

Have you ever tried to click a link on a website as its loading, only to see the link shift down and another element on the page get clicked in its place? This is called a layout shift, and it happens when new content forces existing elements to move and make space.

Layout shifts are very common on sites with advertising. Ads are often large, and loaded after part of the page has already rendered. The CNN video above shows a classic example of a large and user-hostile layout shift as the banner ad comes in.

Google measures this behavior as a Core Web Vital called Cumulative Layout Shift (CLS). In addition to measuring load performance impact, we wanted to see whether ads contributed to greater layout shifts by measuring their CLS.

Cumulative Layout Shift Results

Site	No Ads	With Ads	Impact
nytimes.com	0.208	0.031	6.7x better*
espn.com	0.0	0.0	0.0
cnn.com	0.102	0.19	1.9x worse
wsj.com	0.009	0.087	9.6x worse
foxnews.com	0.021	1.06	50x worse

Cumulative Layout Shift With and Without Google Ads

The results here aren’t as clear cut. ESPN does a great job limiting layout shift in both cases. The New York Times actually has a better CLS score with ads enabled! (More on that below)

However, three of the five sites still have a much worse layout shift score with ads enabled than without. So in general, layout shifts are something you’ll want to monitor if you’re using Google ads.

The New York Times Has a Better CLS Score With Ads Enabled?

The New York times website is reserving space using CSS for the large banner ad at the top of their site. When the ad pops in, it’s not causing any re-flow or layout shift because the space already exists for it.

When ads are disabled, the placeholder collapses, causing a larger layout shift than if ads were enabled!

One could make an argument that no banner ad at all would be better, but then they probably wouldn’t have the cash to buy Wordle, so it’s pros and cons.

How to Improve Google Ad Performance

In almost all cases the revenue generated by Google ads outweighs their performance costs, so removing them is probably not an option. There are still some things that can be done to mitigate their performance hit though.

Load Scripts Statically

It’s not uncommon to see sites using dynamic script loading to inject the Google ad tags. You might see something like this on your site:

<script>
  var el = document.createElement('script');
  el.src = 'https://securepubads.g.doubleclick.net/tag/js/gpt.js';
  var node = document.getElementsByTagName('script')[0];
  node.parentNode.insertBefore(el, node);
</script>

Instead of using a dynamic script loader, which can be delayed by other events and elements on the page, it’s better to use statically defined async scripts, like the examples below.

Static Script Loading, Asynchronously

Google suggests their scripts should be loaded asynchronously, so as not to block page load.

<!-- Use of the async attribute on the script tag can help defer load -->
<!-- For Adsense -->
<script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>

<!--Or using the Google Publisher Tag-->
<script async src="https://securepubads.g.doubleclick.net/tag/js/gpt.js"></script>

Despite this advice, many sites are still loading ad scripts with slow dynamic loaders, or synchronously loading static script tags.

Lazy Load Ads Below The Fold

There’s no sense is waiting for an ad to load that the user can’t even see. When possible, load ads below the fold lazily - preventing load blocking. Google has a nice lazy load example if you’re using Google Publisher Tag. Google even hosts a demo so you can see it in action.

Reserve Size For Above-the-Fold Ads

Preventing layout shift is just as important as optimizing page load performance. The easiest way to prevent frustrating layout shifts for users is to reserve space for your ads, like the New York Times does. The simplest way to reserve space is using the min-width and min-height CSS properties to define a placeholder size.

<div id="banner-ad" style="min-width: 600px; min-height: 200px;"></div>

Multiple Content Sizes

Sometimes ads have multiple sizes, and in that case you’ll have a decision to make with regards to reserving space. Common strategies are:

Reserve space for the largest content size
Reserve space for the smallest content size
Reserve size for the most commonly served content size

Google has more information regarding layout shifts and ad best practices.

Conclusion

Ads may be necessary on a site, but it’s important to minimize performance impact as much as possible. If you’re using Google Ads, give Request Metrics a try and improve your site’s performance.

Request Metrics will monitor Cumulative Layout Shift, load performance, and dozens of other metrics, for every user on your site. You’ll get up-to-date metrics that show you exactly how your site is performing. You’ll also get 90 days of historical data to see if things are trending in the right direction.

Web Performance Profiling: Nike.com

Todd H. Gardner — Wed, 06 Jul 2022 00:00:00 +0000

Google has long used website performance as a ranking criteria for search results. Despite the importance of page experience for SEO, many sites still suffer unacceptable load times. Poor performance is often a confluence of factors: slow time to first byte, hundreds of resource requests, and way too much JavaScript.

Nike.com Is Slow

Let’s look at a popular online retailer: Nike.com. With outdoor exercise increasing in popularity post-COVID, Nike’s running shoe offerings are compelling (arguably too compelling) and we want to buy some.

But the experience on mobile when we navigate to a product details page for a VaporFly shoe is slow and janky.

There’s a few obvious problems:

The page takes a long time to load. Subjective to be sure, but it’s over 5 seconds.
There are multiple asynchronous parts rendering at different times causing contentful paint events. (The free shipping banner, the “Sign in to Buy” button etc.)
There are several layout shifts occurring making the page load look janky. Particularly jarring is the product image render ing below the title and then jumping above it.

We can see that the page “feels” slow, but can we quantify it? Can we determine which specific pieces are responsible for the slowness?

Performance Auditing with Chrome

Chrome has great performance diagnostic tools. We’ll start on the Network tab of the developer tools.

This gives us some quantitative metrics:

The initial document took 143ms to return from the server.
283 total requests to load the page.
5.7MB transferred over the wire.
12.9MB of uncompressed resources.
5.6 seconds to finish.

283 requests is unexpectedly high, and overboard for a product details page (or really, anything). That number of requests is going to put a floor on how fast a site can be, regardless of any other improvements.

Many of the requests are served over HTTP/2, which does help with multiplexing, but it would still be better for performance to make dramatically fewer calls.

We can investigate further by filtering the Network tab to specific resource types. This let’s us see the size and number of requests for each type (JS, CSS etc).

A few things stand out. First, 87 requests totaling 8.9MB of JavaScript! That is a lot of JavaScript! There are also 72 XHR/Fetch requests during page load which feels like too many. 46 image requests is also pushing it, but that’s not a huge surprise on an e-commerce site like this. The most concerning thing here is the number of JS requests, and the overall size of the script.

Diagnosing JavaScript Issues with Chrome Performance Audit

We can use the “Performance” audit feature in the developer tools to find out what’s going on with the JavaScript on this page.

Creating a performance profile gives us a snapshot of a specific page load. We get detailed flame graphs and timelines of what’s happening. If you want to play along, download the profile used in this tutorial, and load it in to Chrome to take a look.

There is a lot of information displayed in our Chrome performance profile. It can look daunting at first. Let’s break it down and go through each section individually.

Section 1: CPU, Network and Frames Per Second Timeline

The top section ( 1 ) is where frames per second, network activity and CPU utilization are graphed over time.

Those little red lines at the top are long running tasks. Below that, in green, is the number of frames per second (FPS) the browser is rendering at. Higher is better. The lower the FPS the more jerky animations will look to the user. Below the FPS graph there’s the CPU usage meter. Yellow represents CPU time spent executing JavaScript, while purple is CPU time spent rendering.

Overall this graph tells us something specific. The long running tasks occurring in JavaScript are eating CPU and killing frames per second. When each long running task finally completes, the browser spends time rendering. This is a common usage pattern in poorly optimized/structured single page applications (SPAs).

Section 2: Flame Graphs and Page Lifecycle

The middle section of the performance profile ( 2 ) shows detailed flame graphs representing animations, JavaScript function timings and page lifecycle events.

The red “L” is the OnLoad event firing. Largest Contentful Paint (LCP) and First Contentful Paint (FCP) are shown as well. We also get more detailed information on just how long some tasks were taking. These longer tasks are good places to start when investigating why the script execution is taking so long.

Section 3: Summary and Aggregate Lists

The bottom section of the profile ( 3 ) shows summary and list data.

This confirms what we suspect - scripting accounts for a majority ( 70% ) of the total time during page load. Rendering takes up the next largest chunk at 12% and is probably correlated to heavy JS usage. That is, the work JavaScript is doing ultimately results in a change to the DOM, causing rendering.

Analysis of Scripting in the Performance Profile

A good place to start when investigating script issues is the “Bottom Up” tab. This gives us a more granular view of the pie chart from the Summary tab. We can see similar time taken percentages here, but now we can expand the arrows and dive deeper.

When we click in to each of these activities we get a much more detailed picture of where the time is going. Drilling in to the top-level “JavaScript” section, we see a list of the functions Chrome is spending the most time in.

From the file names, it’s clear that a large portion of our time is spent inside React. Given the number of renders and the high CPU/low FPS, it’s likely the application is in significant need of optimization!

We can see that setState is prominently represented in the list, and repeated calls to setState will often cause layout thrashing and other poor performance issues. In terms of code improvement, drilling in to these React functions would be a good place to start!

So JavaScript is Why Nike.com is so Slow?

As with most sites, there is no single smoking gun causing all of the performance problems. In this case, 87 JS file requests and almost 9MB of uncompressed JavaScript are certainly a big factor.

Unoptimized Single Page Application

We know from the graphs that script execution is pegging the CPU and frames per second is suffering. We also know that there are too many renders occurring throughout the page lifecycle. Coupled with the amount of time spent in React, we can conclude that the React application is a large part of the problem! Spending time performance tuning the React application would help address the layout shifts and numerous contentful paints.

Too Many Scripts

There’s another JavaScript related performance problem too. Let’s look at another view of the “Bottom Up” tab on the performance profile, this time grouped by script URL:

No wonder there are 87 requests and 8.9MB of script! There are numerous third party analytics and marketing products represented here, along with evidence of the internal corporate structure of Nike’s software teams. In short, this list is too long. Each of these scripts has a cost in terms of performance, and also maintenance and user experience/quality.

If Nike wanted to improve their site’s performance they would do the following:

Optimize their React app. Ensure judicious use of setState. The amount of jank/layout shift on page load, coupled with the pegged CPU, strongly suggests that there are ample opportunities to batch state updates or do less work.
Remove some of their analytics and tracking third parties. There’s too many cooks in the kitchen here and each one could be contributing to poor page experience.
Consolidate some of their first-party scripts. There’s dozens of scripts loaded from all over nike.com. It’s Conway’s Law in action.

Making these changes would be a big start towards improving performance on Nike.com!