Performance Tools

Performance Health Score

A combined performance overview - response time, compression, HTTP version, keep-alive, and CDN usage.

Enter a domain for a combined performance overview - response time, compression, HTTP version, keep-alive, and CDN usage.

More Performance Tools

View all 10

CDN Detection Render-Blocking Resources Checker Page Size Checker Image Optimization Checker Keep-Alive Checker GZIP Compression Checker Cache Headers Checker Brotli Compression Checker

JustChecker tracks your website's performance signals continuously and alerts you if anything regresses.

What Is the Performance Health Score?

It combines several server-side performance signals - response time, compression, HTTP version, keep-alive and CDN usage - into one overview with recommendations.

When to Use It

As a first performance check before deeper testing.
To compare hosting setups.

How to Use It

Enter the domain.
Work through the recommendations, starting with the slowest or missing items.

Understanding the Result

A fast server response, compression, HTTP/2 and a CDN together give a strong foundation for good Core Web Vitals.

Limitations

This measures the server and delivery setup, not how the page renders in a browser. For images and render-blocking files use the Image Optimization Checker and Render-Blocking Resources Checker, and Google PageSpeed Insights for real Core Web Vitals.

Frequently Asked Questions

This score focuses specifically on performance-related signals (response time, compression, HTTP version, keep-alive, CDN usage) - for a broader picture, pair it with our SSL, DNS, and Security Headers tools, each of which checks a different aspect of your website's health.

Response time and compression configuration tend to have the most immediately noticeable impact, since they directly affect how quickly the first meaningful content reaches a visitor - though every factor contributes to the combined result.

Yes - using a CDN helps but doesn't automatically guarantee good scores on every other factor (compression, HTTP version, caching headers) if those aren't also properly configured, either at the origin or within the CDN's own settings.

Yes - since this reflects a live snapshot, re-running the check after implementing a fix (enabling compression, upgrading to HTTP/2) is the direct way to confirm the change actually took effect as expected.

It reflects strong server/infrastructure-level configuration, but perceived speed also depends on front-end factors this specific check doesn't evaluate - large unoptimized images, excessive JavaScript execution, and render-blocking resources, for example.