Changelog

The console tab now has a custom design rather than showing the text-based diff by default.

Console messages will also include a call stack and code snippet where available.

Request errors also show an HTML snippet, if the request was triggered by the page HTML.

DebugBear now tests your websites with version 6 of Lighthouse. We've also upgraded Chrome from version 78 to 83.

New metrics and scoring

Lighthouse 6.0 introduces several new metrics and changes how the overall performance score is calculated

• Total Blocking Time – How often do JavaScript or rendering tasks make the page unresponsive?
• Largest Contentful Paint – When is the largest content element displayed on the screen?
• Cumulative Layout Shift – How much does page content move around after being rendered?

The composition of the Performance score has changed as follows:

Existing metrics

• First Contentful Paint – 20% ➔ 15%
• Speed Index – 26.7% ➔ 15%
• Time to Interactive – 33.3% ➔ 15%

New metrics

• Largest Contentful Paint – 0% ➔ 25%
• Total Blocking Time – 0% ➔ 25%
• Cumulative Layout Shift – 0% ➔ 5%

Deprecated metrics

• First Meaningful Paint – 6.7% ➔ 0%
• First CPU Idle – 13.3% ➔ 0%

You can find the charts for the new metrics in the Performance tab.

Read more about these metric changes in the Lighthouse 6.0 announcement post.

Better timing budgets

Lighthouse performance budgets now support more timing metrics. If you've set up a performance budget on DebugBear those metrics will also show up in the Lighthouse report.

Stack packs

These were introduced in Lightouse 5.6.0, but DebugBear was previously running version 5.5.0. The Lighthouse report now includes recommendations tailored to your tech stack:

DebugBear automatically generates notifications if it looks like there's been a regression on your site. That means you don't need to do any work to get set up, but you might get some notifications that aren't relevant to you.

From now on you can configure when a notification is sent. It's been possible to mute specific notifications for a while, but I've now added some documentation for it.

One common issue has been notifications for performance issues that can't be reproduced later on. Maybe the server was busy, or something weird happened with DNS. To avoid this problem in the future, some performance alerts are now only sent if the performance problem occurs more than once in a row.

DebugBear now has a Validation tab which shows errors and warnings generated by the W3C HTML validator.

Most of these errors aren't very helpful. The HTML might not be valid, but as long as all browsers handle it fine that's not a problem. And sometimes the validator doesn't know about a recently added feature and will complain about it.

So DebugBear doesn't list common validation errors by default, and currently no email or Slack alerts are sent if there's a regression.

However, there are many potential problems the validator can identify:

• duplicate attributes (e.g. two style attributes on the same element)
• Stray start and end tags
• Invalid inline CSS, like style="background: [object Object]"

Until yesterday, DebugBear had a Login Steps feature that allowed you to fill out a login form before testing your page. There were a few problems with this though:

• What if your site's login flow is split over two separate pages?
• What if you have more than two form fields that need to be filled out?
• What if you want to fill out a search from rather than do a login?

User flows are the solution to these problems. Rather than shoehorning all this functionality into a login form, you can now set up flexible steps that run before the actual page analysis.

We've published a new version of the Node API. Here's an example of what you can do with it:

const { DebugBear } = require("debugbear")
const debugbear = new DebugBear(process.env.DEBUGBEAR_API_KEY)

const analysis = await debugbear.pages.analyze(pageId, {
  // Commit Hash is required to generate a build
  commitHash: "abc123",
  customHeaders: {
    "X-Enable-Experiment": "true"
  },
})
const result = await analysis.waitForResult()
console.log(result.build.status) // "success"

Check out the migration guide if you're moving from version 1 of the API.

Browsers make OCSP requests to check if a certificate is revoked. Chrome only does this for Extended Validation (EV) certificates.

These requests are now included in the request chart, so it should be easier to understand if you SSL connection takes a long time: