Performance Audit Sample
This sample report shows a CodeAva performance audit for a blog. Two critical issues dominate the load budget — render-blocking scripts adding 1.8 s to parse time and 4.2 MB of unoptimised images. Four warnings cover CDN absence, missing cache headers, a large DOM, and absent lazy loading. Four checks pass, confirming good compression, HTTPS/HTTP2, and fast TTFB.
61
/ 100
Overall Score
2
Critical issues
4
Warnings
4
Passed checks
10
Total checks
Render-blocking JavaScript (3 scripts)
critical3 third-party and first-party JavaScript files are loaded synchronously in the <head> without defer or async attributes. Each blocks HTML parsing and delays page render for all users.
Blocking scripts:
<script src="/vendor/analytics.js"> — 42 KB
<script src="/vendor/chat-widget.js"> — 88 KB
<script src="/app/main.js"> — 124 KB
Total blocking: ~254 KB, estimated delay: 1.8 s on 4G
Fix: Add defer attribute to all three scriptsUnoptimised images (total: 4.2 MB)
criticalImages on the homepage and article listings are served in JPEG/PNG format without compression or modern format conversion. Combined payload is 4.2 MB, the single largest contributor to page weight.
Largest offenders:
/images/hero.jpg — 1.4 MB (could be ~80 KB as WebP)
/images/featured-post.png — 980 KB (could be ~55 KB as WebP)
/images/author-grid.jpg — 620 KB (could be ~40 KB as WebP)
Recommended: Convert to WebP, serve via responsive <picture>No CDN detected
warningStatic assets (images, CSS, JS) are served directly from the origin server with no CDN in front. Users outside the origin region experience significantly higher latency for every asset request.
Response headers show no CDN provider (no cf-ray, x-cache, x-amz-cf-id, etc.)
Origin server location: Frankfurt, DE
Impact for US East users: +140–200 ms per assetMissing Cache-Control headers on static assets
warningCSS and JS bundles are served without Cache-Control headers. Browsers cannot cache these files between visits, forcing a full re-download on every page load.
Affected:
/app/main.css — Cache-Control: not set
/app/main.js — Cache-Control: not set
/vendor/*.js — Cache-Control: not set
Recommended: Cache-Control: public, max-age=31536000, immutableDOM size too large (1,847 nodes)
warningThe homepage DOM contains 1,847 nodes. Large DOMs increase memory usage, slow style recalculations, and degrade layout and interaction performance.
Current: 1,847 nodes
Google threshold: > 1,500 nodes is a warning
Largest subtree: article listing section (912 nodes)
Fix: Paginate or virtualise the article listing instead of rendering all itemsImages not lazily loaded
warningAll images are loaded eagerly on page load, including those far below the fold. This adds unnecessary network requests on initial load, particularly on mobile connections.
Images without loading="lazy":
14 of 17 <img> elements below the fold
Fix: <img src="..." loading="lazy" alt="...">Recommended fixes
Add loading="lazy" to below-fold images
A single attribute on 14 img elements defers loading until images approach the viewport. Zero infrastructure changes required.
Add defer to all three blocking scripts
Adding the defer attribute to the three blocking scripts removes ~1.8 s of render delay. No functional changes required — defer executes after HTML parsing.
Set Cache-Control on CSS and JS bundles
Add Cache-Control: public, max-age=31536000, immutable to all versioned static assets. Eliminates repeated downloads for returning visitors.
Convert hero images to WebP
Batch-convert the three largest images to WebP and serve via <picture> with a JPEG fallback. Saves approximately 2.4 MB — the biggest single win available.
Paginate or virtualise the article listing
Reduce the DOM to under 1,000 nodes by loading articles in batches of 10 with a Load More button, or use a virtual list for infinite scroll.
Run this audit on your own project
This is a sample report. Get your own scored results by pasting a URL or code snippet.