Forem: Request Metrics

Why Your Perfect Lighthouse Score Doesn't Mean Your Site is Fast

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

Great Lighthouse scores, but users still complain your site is slow? You're not alone.

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

That means half the developers celebrating perfect synthetic scores are actually delivering poor performance to their real users.

The Problem with Synthetic Testing

Lighthouse and PageSpeed Insights run in perfect, controlled environments. They simulate an "85th percentile user" — but their simulation is usually wrong for your specific audience.

Real-world variables synthetic tests miss:

Network packet loss and latency spikes
Device thermal throttling during extended use
Background apps competing for resources
Browser extensions affecting performance
User behavior patterns (scrolling, multitasking)
Third-party vendor outages

Your developer-focused B2B app has completely different users than a consumer social platform, but Lighthouse treats them the same.

What Real User Monitoring Actually Shows You

Real User Monitoring (RUM) collects performance data from actual user sessions as they happen. Instead of guessing what your users experience, RUM shows you the reality.

RUM catches problems synthetic testing misses:

🔍 Dynamic content issues - Your personalization engine might be fast for new users but slow for power users with complex data

📱 Device-specific problems - That Android phone model struggling with your animations

💰 Business-critical scenarios - Your checkout flow performing poorly during Black Friday traffic spikes

🌍 Geographic variations - Users in different regions experiencing network infrastructure problems

The Complete Strategy

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

Development: Use Lighthouse to catch obvious issues before shipping
Production: Use RUM to see what actually needs fixing for real users
Investigation: When RUM spots problems, use synthetic testing to understand why
Validation: Confirm your fixes actually help real users with RUM

Why This Matters for Your Career

Understanding real user performance isn't just about better metrics — it's about:

Fixing problems that actually cost revenue
Prioritizing work based on real user impact
Making data-driven performance decisions
Building faster experiences users actually notice

Getting Started

The fastest way to see the gap between your synthetic scores and real user experience? Install Real User Monitoring and prepare to be surprised by what you discover.

Most developers find performance issues they never knew existed within their first week of real user monitoring.

Want the full deep-dive? I wrote a comprehensive guide covering everything from RUM implementation to business impact analysis: Why You Need Real User Monitoring to Really Understand Your Web Performance

What's been your experience with synthetic vs. real user performance? Have you found gaps between your Lighthouse scores and actual user complaints? Share your stories in the comments! 👇

HTTP Caching Deep Dive: Performance Optimization Patterns Every Developer Should Know

Todd H. Gardner — Fri, 28 Feb 2025 17:00:08 +0000

As web developers, we're often so focused on writing clean code that we overlook one of the most powerful performance tools at our disposal: HTTP caching. Let's explore some advanced caching patterns that can dramatically improve your application's performance without writing a single line of JavaScript.

The Caching Mindset Shift 🧠

Most performance optimization starts with the wrong question: "How can I make my site faster?" The better question is: "How can I avoid sending data altogether?" HTTP caching answers this beautifully.

# The magical one-liner that can cut load times in half
Cache-Control: public, max-age=31536000, immutable

This simple header can transform your application's performance profile by telling browsers, "Don't even ask for this file again for a year."

We recently wrote a comprehensive guide to HTTP caching headers that breaks down the complete specification into practical recipes, but let's focus on some developer-specific implementation patterns here.

Resource-Specific Caching Strategies

Not all resources are created equal. Strategic caching requires different approaches for different asset types:

Static Assets (CSS/JS/Images)

These should be cached aggressively with versioned filenames:

# Your browser's equivalent of "I'll remember this forever"
Cache-Control: public, max-age=31536000, immutable

The immutable directive is particularly powerful - it tells browsers not to revalidate the resource during page refresh, eliminating unnecessary network requests.

HTML Documents

These need more careful handling:

# Short cache time with validation
Cache-Control: public, max-age=300, must-revalidate

Cache Validation: The Unsung Hero

While most developers focus on cache duration, validation headers are equally important. They determine what happens when cache expires:

# Response includes:
ETag: "123abc987654"

# Later browser request includes:
If-None-Match: "123abc987654"

# Server responds with 304 Not Modified (no body!)

This validation dance is pure magic - your server sends only HTTP headers instead of full responses when content hasn't changed!

Cache-Busting: The Deployment Superpower

When you deploy changes, you need to invalidate caches. The cleanest approach is content-hashed filenames:

styles.d41d8cd98f.css

This pattern enables aggressive caching while ensuring users always get the latest version after deploys. Most build tools (Webpack, Rollup, Parcel) handle this automatically.

Common Pitfalls to Avoid

I've seen these mistakes cause serious performance issues:

Over-caching dynamic content - Accidentally caching personalized content
Under-caching static assets - Missing massive performance gains
The dreaded no-store directive - Forcing full downloads on every page load
Confusing no-cache with "don't cache" - It actually means "revalidate before using"

Real-World Impact

On a recent project, implementing proper HTTP caching reduced page load times by 67% and cut bandwidth usage in half. The best part? It took just 30 minutes to configure.

Remember: The fastest HTTP request is the one you never make. Proper caching ensures you only download what's necessary, when it's necessary.

Want to learn more about HTTP caching? Check out our comprehensive guide on Request Metrics.

What caching strategies have you implemented in your projects? Share your experiences in the comments!

GTMetrix Alternatives: Better Ways to Measure Web Performance

Todd H. Gardner — Wed, 26 Feb 2025 16:46:35 +0000

For years, GTMetrix was a go-to tool for checking website speed. But here’s the thing—paying for synthetic tests doesn’t make sense anymore.

You’ve probably seen it before: GTMetrix tells you your site is fast, but your users are still complaining about slow load times. That’s because synthetic tests don’t tell the whole story.

If you’re serious about web performance, you need more than just lab data. That’s why we put together a full breakdown of the best GTMetrix alternatives—so you can find a tool that actually helps real visitors experience a faster site.

Why Synthetic Tests Alone Aren’t Enough

Synthetic tests, like the ones GTMetrix runs, generate lab-based results in a controlled environment. That’s useful, but it doesn’t reflect how real users experience your site.

A real-world user might:

✅ Load your site on a slow mobile network

✅ Have third-party scripts blocking content

✅ Experience delayed interactions because of render-blocking resources

If you’re only looking at synthetic test scores, you might think your site is fine—when, in reality, your users are struggling.

The Better Approach: Synthetic + Real User Monitoring (RUM)

Modern performance tools combine synthetic tests with Real User Monitoring (RUM) and Google’s CrUX data to give you a complete picture of your site’s speed.

Here’s what each method measures:

🛠 Synthetic Testing – Lab-based speed tests in a controlled environment

👥 Real User Monitoring (RUM) – Performance data from actual visitors

📊 Chrome UX Report (CrUX) – Aggregated Core Web Vitals from real Chrome users

Best GTMetrix Alternatives Right Now

If you want free synthetic testing, you’re in luck—better tools exist:

1. PageSpeed Insights (Free & Simple)

✅ Free and easy to use

✅ Uses Google’s Core Web Vitals data

❌ No real user tracking

2. WebPageTest (Advanced & Free)

✅ Advanced synthetic testing

✅ Test from multiple locations & devices

❌ No real user data, can be slow to run

3. Request Metrics (RUM + Synthetic)

✅ Real User Monitoring + Synthetic Testing

✅ Live Core Web Vitals tracking

✅ Free plan available

💰 $88/month for full monitoring

🔗 Learn more: Request Metrics

4. Pingdom ($130/mo)

✅ Uptime monitoring + RUM

❌ Limited synthetic testing

5. Catchpoint (Enterprise)

✅ Enterprise-grade synthetic + RUM

✅ Deep historical tracking

❌ Expensive

Final Thoughts

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

If you want a quick performance check, use PageSpeed Insights or WebPageTest. But if you care about real user experience, Core Web Vitals, and SEO, you need RUM + synthetic data from tools like Request Metrics.

📖 Read the full breakdown here:

👉 GTMetrix Alternatives: The Best Tools for Website Performance

How to Optimize Website Images for Faster Load Times

Todd H. Gardner — Wed, 05 Feb 2025 16:24:40 +0000

Images make the web more engaging, but they’re also one of the biggest performance killers. A bloated, unoptimized image can slow down your site, tank your SEO, and drive users away. If you care about Core Web Vitals, conversion rates, or just having a fast website, you need to optimize your images properly.

Here’s how to do it right.

1. Pick the Right Image Format

Not all image formats are created equal. Using the wrong one can massively bloat your file sizes:

JPG – Best for photographs. Uses lossy compression for smaller files but loses some detail.
PNG – Best for graphics, icons, and images with transparency. Lossless, but can be large.
WebP – A modern replacement for JPG and PNG. Smaller file sizes with high quality.
AVIF – Even better compression than WebP, but not fully supported everywhere yet.

👉 Best practice: Use JPG/PNG for source files and serve WebP/AVIF using a CDN for modern browsers.

2. Compress Images Without Destroying Quality

Large images are slow images. Reduce their size using lossy or lossless compression:

Lossy compression (JPG, WebP, AVIF) removes detail to shrink file size.
Lossless compression (PNG, WebP) keeps quality but is less efficient.

✅ Use tools like TinyPNG or ImageMin to compress images before uploading them.

3. Lazy-Load Below-the-Fold Images

Why load images that aren’t visible yet? Lazy-loading defers their download until needed:

<img src="image.jpg" loading="lazy" alt="Lazy-loaded image">

This keeps the page fast and prevents Largest Contentful Paint (LCP) delays.

4. Serve Responsive Images

Different devices need different image sizes. Avoid serving a giant desktop image to mobile users:

<picture>
  <source srcset="image-700.jpg 700w, image-1200.jpg 1200w" sizes="100vw">
  <img src="image-1200.jpg" alt="Responsive image">
</picture>

The browser picks the best size for the user’s screen, reducing wasteful downloads.

5. Optimize for Mobile

Resize images to fit mobile screens instead of shrinking huge ones with CSS.
Adjust aspect ratios for better layout on small screens.
Use a mobile-friendly CDN for fast delivery.

Final Thoughts

Optimizing images isn’t just about making files smaller—it’s about making your website faster, smoother, and better for users.

🚀 Want to go deeper? Read the full guide to image optimization for the web here

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

Todd H. Gardner — Fri, 18 Oct 2024 15:30:00 +0000

If your website has been feeling sluggish or unresponsive, there's a good chance it's suffering from Long Animation Frames (LoAFs). LoAFs happen when the browser takes too long to process an animation frame, leading to visual stuttering, delayed interactions, or a general feeling of “jankiness.” In my latest posts, I dive into the details of what are Long Animation Frames, why they matter, and very importantly, how to fix LoAFs.

What are Long Animation Frames (LoAFs)?**

When your site processes user interactions, it draws each visual change in what’s called a frame. A smooth experience usually means rendering around 20 frames per second. To achieve this, the browser has about 50 milliseconds to handle everything—JavaScript execution, DOM updates, layout recalculations, and more. When these tasks take longer than 50ms, the browser considers it a Long Animation Frame.

The result? Your site feels sluggish and unresponsive to users. Every time the browser struggles to render a frame, animations stutter and the site feels “frozen.” LoAFs are particularly bad for mobile users, where less powerful hardware struggles even more with rendering.

Why Do LoAFs Matter for Your Site?

The real problem with LoAFs is how they affect user experience, accessibility, and even your search engine rankings. LoAFs contribute directly to poor Interaction to Next Paint (INP) scores, one of the critical metrics in Google’s Core Web Vitals. INP measures how long it takes for your site to respond to user inputs like clicking or typing. If your INP score is bad, it indicates long delays in interactions—which LoAFs are a direct contributor to.

Since Core Web Vitals play a role in your site’s SEO ranking, fixing LoAFs not only improves performance but also gives your site a better shot at ranking higher on Google.

How to Track and Fix LoAFs

In my post, I break down how to track and fix LoAFs, starting with some of the key tools available. Tools like Request Metrics, Chrome DevTools, and Google’s web-vitals.js library can all be used to track LoAFs in both lab environments and real user monitoring (RUM) scenarios.

One of the most effective ways to fix LoAFs is by focusing on JavaScript execution. Long-running JavaScript tasks block the browser’s main thread and cause delays in rendering frames. To fix this, you can break up long tasks into smaller chunks using techniques like setTimeout to distribute work across multiple frames.

Another major cause of LoAFs is forced synchronous layouts, where a script forces the browser to recalculate the layout after every DOM change. This creates additional work that slows down rendering. Fixing this involves batching DOM reads and writes together to avoid recalculating the layout multiple times in a single frame.

Lastly, for sites built using Single Page Applications (SPAs) like React or Vue, LoAFs can be particularly challenging. SPAs tend to rely heavily on JavaScript for UI updates and transitions, which can easily trigger long frames if not optimized properly.

Ready to Toast Your LoAFs?

If you want to dive deeper into the technical details and practical strategies for reducing LoAFs on your site, check out the full post:

How to Fix Long Animation Frames and Improve Your Website

You’ll learn all about the tools, tactics, and best practices for keeping your site running buttery smooth, with fewer LoAFs and faster interactions!

What is a 'Rage Click'?

Todd H. Gardner — Tue, 29 Aug 2023 00:00:00 +0000

You know that thing where you are so angry at a broken website that you furiously click that button until it does what you want? Yea, we all do that. It's called a "Rage Click".

It's also a fantastic way to detect user frustration.

What is a Rage Click?

A rage click is when a user repeatedly clicks on an element of a website or application out of frustration or annoyance, typically due to difficulty completing a task or finding information. It can indicate poor user experience design and lead to low engagement, negatively affecting a website's performance.

Rage clicks suggest that the user is encountering misleading elements or experiencing usability issues on the website. These frustrating experiences can include dead links, broken elements, slow web performance, or confusing design choices. By analyzing rage clicks, you can spot problem areas and improve customer experience, engagement, and even conversion rates.

Understanding these usability issues is important because they are a powerful signal of user frustration. They highlight areas where the website doesn't meet user expectations. It allows you to optimize the user experience by fixing broken links, improving load times, enhancing usability, and streamlining navigation. It gives you a road map to boost customer satisfaction, improve conversion rates, and ultimately drive better business results.

Why Do My Users Rage Click?

Users rage click on a website when they find confusing things that slow them down, get in the way, or cause frustration. Poor user interface, slow loading times, broken links or buttons, unresponsive websites, difficulty completing tasks, and lack of clarity are the primary reasons for rage clicking. A confusing or cluttered user interface can lead to user frustration, as it makes it difficult for them to navigate and find what they are looking for.

Slow web performance and loading times can trigger rage clicking, as users expect fast and seamless browsing experiences. Broken links or buttons that do not work as expected can be extremely frustrating, especially when users are trying to access important information or complete a task.

Unresponsive websites, where interactive elements or buttons do not respond promptly to user input, can also trigger rage clicking. Difficulty completing tasks, such as a complicated checkout process or unclear instructions, can further exacerbate user frustration and lead to rage clicks. This unresponsiveness is measured by one of Google's Core Web Vital Metrics, the Interaction to Next Paint, or INP.

Why Are Rage Clicks so Bad?

Rage clicks indicate a problem for both your website and your business. These events point towards a bad user experience and can lead to reduced user engagement, lower conversions, and ultimately hinder the overall success of a business.

When users experience frustration and resort to rage clicking, it indicates a breakdown in the user's journey. Instead of smoothly navigating through a website, users encounter obstacles such as broken links, unresponsive buttons, or confusing elements. This creates a negative user experience that increases the likelihood of high bounce rates, where users leave a website without taking any desired actions.

Tip: Define and track your important user journeys with funnels: a series of steps that you want your users to take. Funnels allow you to measure the effectiveness of your site, and understand which users fail to complete their journey--and why!

How Do I Track Rage Clicks?

Rage clicks are super frustrating for both the user, and for you, the developer. They indicate usability issues and can negatively impact the overall user experience. If left unaddressed, rage clicks can lead to lower engagement and reduced conversion rates.

There are two ways to track user rage clicks:

1. Session Replay Tools

Session replay tools like Fullstory or Hotjar can point out when rage clicks and dead clicks are happening in a recording of the user's session. These videos can be a great way to learn about individual user sessions, but it's tedious to watch a lot of these, and it's hard to keep sensitive user data from ending up in these videos.

You can also replay sessions with a log of user actions and events, like the Session Transcript in Request Metrics. Transcripts let you quickly glance through a user journey, and also report on interesting events, like all the sessions with rage clicks, whether they are increasing, and what pages and elements they tend to happen on.

Whether you use a video or a transcript to understand the user journey, knowing the context of a rage click or a dead click is helpful to improve the usability and enhancing user experience. With this valuable information, businesses can make informed decisions about optimizing their websites, reducing user frustration, and ultimately improving conversion rates.

2. JavaScript Events

You can track Rage Clicks with any user analytics tool as well by listening for a JavaScript event. Once you discover these "rage click events", you can send it on to Google Analytics, Request Metrics, or whatever analytics tool you're using.

Here's a quick example:


// number of clicks before RAGE is assumed
const LIMIT = 3;

// time in ms to wait for cooldown
const TIMEOUT = 750;

// storing our state in the DOM
const STATE = "__rageClick";

// Listen at the top for all clicks.
window.addEventListener("click", (evt) => {
  var el = evt.target;
  el[STATE] = el[STATE] || {
    count: 0,
    clear: null
  };

  // increment counter and reset our cooldown
  el[STATE].count++;
  clearTimeout(el[STATE].clear);

  // after cooldown, check if there was a rage
  el[STATE].clear = setTimeout(() => {
    if (el[STATE].count > LIMIT) {
      RM.send("Rage Click");
    }
    delete el[STATE];
  }, TIMEOUT);
});

To track rage clicks on a website, you need to implement certain JavaScript events. The first event is the "click" event, which is triggered whenever a user clicks on an element on the web page. This event will be used to detect and capture all the clicks made by the user.

Next, you need to create a variable to store all the click events as an array. This variable will be initialized when the page loads, and every click event will be pushed into this array. This allows you to keep track of all the clicks made by the user.

To identify rage clicks, you need to define thresholds. These thresholds can be based on the number of clicks made within a timeframe on a specific element. For example, if a user makes more than 3 clicks within 750 milliseconds on the same element, it can be considered a rage click.

To detect rage clicks within the defined thresholds, you can create functions that monitor the click events stored in the array. These functions can check if the number of clicks exceeds the defined threshold and if they occur within the specified timeframe.

Once a rage click is detected, you can send it off to your analytics tool to be recorded and reported. This allows you to analyze and track the occurrence of rage clicks, helping you identify areas of frustration on your website and make necessary improvements to enhance the user experience.

Other User Frustration Signals

There are lots of ways that users signal their frustration while interacting with your website. These signs indicate usability issues, poor web performance, or opportunities to improve your design. Here are some examples of user frustration signals:

Rage clicks, which is what we've been talking about, are repetitive and rapid clicks made by users out of frustration. They reflect a negative user experience and can be caused by confusing elements or poor design choices.
Dead clicks occur when users futilely attempt to interact with non-clickable elements or broken elements on a web page. Dead clicks are frustrating experiences that often result in users abandoning the site, leading to poor conversion rates and customer churn.
Excessive scrolling is when users find it difficult to navigate or locate the information they need, they tend to scroll more than necessary in an attempt to find what they are looking for. This especially happens when an "infinite list" UI pattern is implemented.
Intense mouse movement is another sign of user frustration. When users are unable to quickly and easily interact with elements on a website, they may begin to move their mouse rapidly across the screen in an attempt to find clickable or interactive elements.
Rapid page reloading is yet another behavior that indicates user frustration. If users repeatedly reload a page within a short period of time, it suggests that they are not satisfied with the content or functionality of the page. This can be a sign of usability issues such as slow loading times, broken elements, or confusing navigation.

By recognizing these signs of user frustration, website owners and designers can identify potential usability issues and take steps to improve the overall user experience. Addressing these issues can lead to higher conversion rates, improved customer satisfaction, and ultimately, increased success for the website or online business.

How Do I Fix Rage Clicks?

Okay okay okay. Rage clicks are bad. I get it. How do I prevent this from happening on my website?

That really depends what your site does, but implementing certain strategies can significantly enhance the overall user experience:

Optimize Website/App Design: Ensure an intuitive user interface design with clear navigation and easily discernible interactive elements. Use consistent and familiar design patterns to minimize confusion for users.
Improve Performance: Address slow loading times and broken elements that may lead to user frustration. Optimize code, compress images, and streamline server requests to improve website or app speed.
Provide Clear Instructions: Clearly communicate instructions and any necessary steps to complete tasks or find desired information. Avoid vague or ambiguous language that may confuse users.
Ensure Effective Search Functionality: Implement search with accurate results to help users quickly find what they are looking for. Include filters and sorting options to refine search results further.
Conduct User Testing: Regularly test your website or app with real users to identify any usability issues or points of frustration. Utilize session replay or transcript tools to gain insight into user behavior and areas for improvement.
Monitor User Experience: You can't fix what you don't know. Use monitoring tools like Request Metrics to understand your funnels, user activity, performance, errors, and other frustrations, so that you can find and fix problems quickly.

We spend tons of time helping folks like you understand how your web application is performing for your users, and how to make it better. With things like Error Tracking, Web Performance, and Session Transcripts, we can help you understand things and build better experiences for your users. I bet we can help you too.

Conclusion

Addressing rage clicks is important for improving website usability and the overall user experience. By optimizing your design, improving performance, providing clear instructions, ensuring effective search functionality, and monitoring your web application, you can maximize user engagement and improve your conversion rates.

However, identifying and understanding rage clicks can be challenging without the right tools. You'll need analytics tools that are powerful enough to capture real insights about your user's journey and frustrations, and simple enough that you'll actually understand and use them. That's exactly why we built Request Metrics--a powerful client-side monitoring tool that distills the data into simple and discoverable reports. We can help you build a better, faster, and more effective web application that your users love and drives higher conversions.

You and your business must understand rage clicks and address why they are happening to improve website usability and create a positive user experience. Using tools like Request Metrics will show you insights about user frustration and allow you to optimize your web applications effectively. By doing so, you can minimize user frustration, increase conversions, and have bragging rights for just how awesome your website is.

Originally published as "What is a Rage Click?" on the Request Metrics Blog.

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.