Cumulative Layout Shift (CLS) is where the layout of a web page unexpectedly shifts after the initial content loads and new content pops in. At its best, it’s a little inconvenient. At its worst, it’s an accidental click of a “BUY NOW” button that suddenly appeared under your mouse cursor after an ad loaded, resulting in an unwanted purchase.

It’s the little things that can make a big difference. While we announced significant product updates like Autofix and Metrics (to name a few) during Launch Week, we couldn’t cover everything. Over the past few months, we shipped updates to the core platform, improvements to the developer workflow, and a series of quality-of-life features. The sum of these small improvements add up to big updates across Sentry that help make your production issues even more debuggable.

When cloud service providers first started popping up, many developers were “wowed” by being able to spin up and scale all kinds of infrastructure to deploy their web applications on demand. However, big-box cloud service providers are often complex to use, scaling out is expensive and default monitoring solutions are not very insightful. Besides, we are spoiled developers, and we expect things to be easy.

Recently, I improved all my homepage Core Web Vitals by focusing on improving just one metric: the Time to First Byte (TTFB). All it took was two small changes to how data is fetched to reduce the p75 TTFB from 3.46s to just 704ms. In this post I’ll explain how I found the issues, what I did to fix them, and the important decisions I made along the way. (And don’t worry, I’ll break down “p75” and “TTFB”, too!)

On March 12 Google began promoting INP (Interaction to Next Paint) into a Core Web Vital metric in an effort to push performance beyond page loads. This means your website or application’s SEO ranking may be impacted if users do not have smooth interactions on the site or app. While this change is a net positive for users, finding the root cause of these reported slow interactions can be tricky for developers.

“A picture is worth a thousand words”. So if a picture takes more than 4 seconds to load, does it mean that your website’s content fails to communicate a thousand words? In this blog post, we’ll learn how to identify unoptimized images, how to fix them, and how to validate the fix — so your website can speak volumes with highly-optimized images.

Over the past year, we released a couple of new offerings, like Session Replay and Cron Monitoring. But in addition to building new products, we’re constantly looking for ways to improve our core platform to help you debug software issues faster. As you hopefully saw during Sentry’s Launch Week, we shipped five quality-of-life improvements addressing the following problems: Here’s the latest.

While there are several solutions that try to help you improve your testing practices and tooling, we believe that high-quality software is not just limited to how well it’s tested. That’s why we’re expanding beyond code coverage and building the foundation for the first of its kind pre-release platform with Bundle Analysis, Test Analytics, and AI-Powered Code Review.

We’ve been exploring new approaches to make Sentry issues more actionable. Read on to learn how we’re using machine learning to improve issue creation (i.e. grouping) and alerts, with as little configuration as possible, so you can focus on fixing the most important issues.

Sentry knows a lot about the inner workings of an application’s codebase. So we got to thinking, how can we use this rich dataset to make debugging with Sentry even faster? Many generative AI (GenAI) tools (e.g. GitHub Copilot) improve developer productivity in their dev environment, though few have the contextual data Sentry has to help fix errors in production.