Brand360

Performance

10 performance checks

10 checksDownload .md version
P1

Response Time (TTFB)

What is it

Time to First Byte (TTFB) measures the time from sending the HTTP request to receiving the first byte of the server response. The ideal value is under 800 ms. TTFB is a fundamental metric that affects all subsequent metrics such as FCP and LCP. A slow server means the user is waiting before anything even starts rendering.

Why it matters

A slow TTFB slows down the entire page. If the server responds slowly, the user sees a white screen. Google uses loading speed as a ranking factor. According to web.dev, TTFB should be under 800 ms for a good rating. Every 100 ms of delay reduces conversions by approximately 1%.

Real-world example

Amazon found that every 100 ms of delay cost them 1% in revenue. Google typically has a TTFB under 200 ms thanks to distributed servers and edge caching. If your e-shop responds in 2500 ms, the page takes 4-5 seconds to load and most visitors will leave.

Verified sources

P2

HTML Size

What is it

Checks the size of the page's HTML document. The ideal size is under 100 KB. Large HTML documents slow down parsing and increase the time to first render. Excessively large HTML often results from inline styles, inline scripts, or duplicated content.

Why it matters

Large HTML slows down loading because the browser must download and parse the entire document before it can begin rendering. On mobile networks this is even more pronounced. Smaller HTML also reduces data consumption for users and speeds up DOM parsing.

Real-world example

The Google homepage has HTML under 50 KB, enabling lightning-fast loading. Shopify optimizes their templates' HTML to a minimum. If your blog generates 500 KB of HTML due to inline CSS and unnecessary attributes, loading on a 3G network can take up to 5 seconds.

Verified sources

P3

External Resources

What is it

Counts the number of external scripts and CSS files loaded on the page. The ideal count is fewer than 15. Each external resource requires a DNS lookup, TCP connection, and HTTP request, which adds latency. Render-blocking scripts and styles are particularly problematic.

Why it matters

Each external resource adds network latency. CSS and JavaScript are render-blocking — the browser cannot display content until all of them are loaded. Too many external resources dramatically slow down First Contentful Paint and increase the time the user sees a blank page.

Real-world example

A typical WordPress site loads 15-30 external resources due to plugins. The Google homepage uses only 3-4 external resources. If your site loads 25 external scripts from various CDNs, each adds 50-200 ms of latency and the total delay can reach 2 seconds.

Verified sources

P4

Inline CSS

What is it

Measures the size of inline CSS styles directly in the HTML document compared to external styles. A small amount of critical inline CSS (up to 15 KB) is beneficial for fast rendering of above-the-fold content. However, too much inline CSS increases HTML size and prevents style caching.

Why it matters

Inline CSS cannot be cached — it is downloaded with every page load. Large blocks of inline CSS increase the HTML document size and slow down parsing. The correct approach is to inline only critical CSS for above-the-fold content and load the rest asynchronously from an external file.

Real-world example

Google inlines critical CSS for above-the-fold content (roughly 10 KB) and loads the rest asynchronously. If your website has 200 KB of inline CSS in every HTML document, the user downloads unnecessary data with every request and the browser cannot cache CSS between pages.

Verified sources

P5

Inline JS

What is it

Measures the size of inline JavaScript code directly in the HTML document compared to external scripts. Small inline scripts (up to 5 KB) are acceptable for critical functionality. Large blocks of inline JS increase HTML size, slow down parsing, and prevent script caching and optimization.

Why it matters

Inline JavaScript blocks the HTML parser and cannot be cached by the browser. Large inline scripts slow down Time to Interactive and increase the size of every HTML document. External scripts can be cached, minified, and loaded asynchronously using the async or defer attributes.

Real-world example

Shopify moved most of their inline JS to external files with async/defer attributes, which improved TTI by 30%. If your e-shop has 150 KB of inline JavaScript (trackers, analytics scripts), every page will be 150 KB larger and impossible to optimize.

Verified sources

P6

Image Optimization

What is it

Checks whether images use modern formats (WebP, AVIF), lazy loading (loading='lazy'), and responsive sizes via the srcset attribute. Lazy loading defers loading of images outside the viewport, and srcset allows the browser to select the right image size for the given device.

Why it matters

Images are typically the largest part of a page (50-70% of data). Without lazy loading, all images are loaded at once, even those the user will never see. Without srcset, mobile devices download unnecessarily large desktop images. Modern formats like WebP are 25-35% smaller than JPEG.

Real-world example

Medium uses lazy loading and srcset for all images in articles — it only loads images visible in the viewport and sends smaller versions to mobile. If your blog has 20 images at 500 KB each without lazy loading, the user downloads 10 MB of data immediately on page load.

Verified sources

P7

Total Page Weight

What is it

Measures the total size of all page resources in KB (HTML, CSS, JS, images, fonts). The ideal value is under 2,000 KB. According to HTTP Archive, the median is around 1,700-1,900 KB. A large page slows down loading, especially on mobile networks and weaker devices.

Why it matters

Total page size directly affects loading time. On a 3G network, downloading a 5 MB page takes over 15 seconds. Google recommends keeping critical content under 170 KB of compressed data to achieve TTI under 10 seconds on mobile devices.

Real-world example

Google.com has a total size under 500 KB. The average e-commerce website is 3-5 MB due to large product images. Amazon optimizes images and uses lazy loading to keep the total size below 2 MB on initial load.

Verified sources

P8

Request Count

What is it

Counts the total number of HTTP requests needed to load the page. The ideal count is fewer than 50. Each request adds latency due to DNS, TCP, and TLS handshakes. Even with HTTP/2 multiplexing, a high number of requests has a negative impact on performance.

Why it matters

A high number of requests slows down page loading, especially on high-latency mobile networks. Render-blocking requests (CSS, synchronous JS) must complete before content can be displayed. Caching, bundling, and sprite techniques reduce the number of requests.

Real-world example

A typical WordPress site with 15 plugins generates 80-120 HTTP requests. Google.com needs fewer than 20 requests. If your website requires 95 requests (30 scripts, 25 images, 15 CSS, 25 other), on a mobile network it can take up to 8 seconds.

Verified sources

P9

CSS Coverage

What is it

Measures the percentage of unused CSS code on the page. The ideal value is less than 50% unused CSS. Unused CSS styles unnecessarily increase file sizes, slow down downloads, and block page rendering because the browser must process all CSS rules.

Why it matters

CSS is a render-blocking resource — the browser must process all CSS rules before rendering the page. If 70% of CSS is unused, the browser wastes time parsing it. Removing unused CSS improves FCP and LCP and reduces page size.

Real-world example

The Bootstrap framework often loads 90% unused CSS if only a few components are used. Tailwind CSS with its purge feature removes unused classes and reduces CSS from 3 MB to 10 KB. If your website uses 500 KB of CSS but actually needs only 50 KB, you are unnecessarily slowing down rendering.

Verified sources

P10

JS Coverage

What is it

Measures the percentage of unused JavaScript code on the page. The ideal value is less than 50% unused JS. Unused JavaScript unnecessarily increases file sizes, slows down downloads, parsing, and compilation, which directly affects Time to Interactive.

Why it matters

JavaScript is the most expensive resource to process — it must be downloaded, parsed, compiled, and executed. Unused JS wastes all of these resources. Lighthouse flags every JS file with more than 20 KiB of unused code. Tree shaking and code splitting are key optimizations.

Real-world example

Webpack bundle analyzer often reveals that 60% of JavaScript code is unused. Next.js uses automatic code splitting — each page loads only the JS it needs. If your website loads 2 MB of JavaScript but uses only 400 KB, mobile devices spend seconds parsing unnecessary code.

Verified sources

Try auditing your website

Test your website against all checks and find out what to improve.

Start analysis