Consider code splitting or tree shaking to reduce unused code.
Why this matters
This bundle has high unused code — code-split or tree-shake to ship only what executes.
Source: web.dev / Lighthouse coverage
B
HTTP/3 (QUIC)
HTTP/3 not advertised
REVIEW
HTTP/3 not advertised
Info::
i
HTTP/3 (QUIC) is not advertised
HTTP/3 isn't advertised via Alt-Svc and the worker didn't negotiate h3. HTTP/3 reduces handshake latency (1-RTT instead of 2-3 RTTs) and is more resilient on lossy connections. Most modern CDNs (Cloudflare, Fastly, AWS CloudFront, Google Cloud CDN) support HTTP/3 with a single config switch -- consider enabling for mobile-heavy workloads.
C
Compression Algorithm
Action
Main response served uncompressed
REVIEW
Main response served uncompressed
Info::
i
Main HTML response has no Content-Encoding (uncompressed)
The main HTML document is served without compression. The Text Compression section above lists the broader picture; for the main response specifically, even gzip would shave ~70-80% off most text payloads.
B
Main HTML Cache-Control
No Cache-Control header on main HTML response
REVIEW
No Cache-Control header on main HTML response
Info::
i
Main HTML response has no Cache-Control header
Without an explicit Cache-Control, browsers fall back to heuristic caching (~10% of Last-Modified age). Set `Cache-Control: no-cache` or `max-age=300` for HTML to control freshness explicitly -- prevents stale auth state and SPA shell drift.
B
Server-Timing Observability
No Server-Timing header found
REVIEW
No Server-Timing header found
Info::
i
No Server-Timing header found
Server-Timing exposes backend timing breakdowns to browser DevTools (e.g., `db: 45ms; render: 120ms; cache: 2ms`). Useful for diagnosing slow pages without backend log access. Most modern frameworks (Next.js, Cloudflare Workers, Fastly) emit it automatically; absence on a managed platform usually means telemetry headers are stripped at the edge.
A+
Text Compression
All text resources are compressed
PASS
All text resources are compressed
Info::
✓
All text resources are compressed
All text resources are properly compressed.
A+
JS Execution Cost
337ms total JS execution
PASS
337ms total JS execution
Info::
i
https://www.pinogalvagno.com/: 205ms CPU time
Info::
i
Unattributable: 77ms CPU time
Info::
i
https://www.pinogalvagno.com/themes/pg/assets/js/v...: 55ms CPU time
6 font(s) use font-display: swap (FOUT risk but functional)
Web fonts
6
114 KB total
Render-blocking
0
of 6
Dominant font-display
swap
Most common across fonts
Font loading timeline
TransferFOIT (block)FOUT (swap)
pxiEyp8kv8JHgFVrJJfecnF...woff2swap
Size8 KB
Load time25 ms
Start808 ms
RiskFOUT — text flashes from fallback to web font
pxiByp8kv8JHgFVrLGT9Z1x...woff2swap
Size8 KB
Load time22 ms
Start875 ms
RiskFOUT — text flashes from fallback to web font
Flaticon.woffwoffswap
Size7 KB
Load time44 ms
Start875 ms
RiskFOUT — text flashes from fallback to web font
Convert to woff2 for ~30% smaller file size
fontawesome-webfont.woff2woff2swap
Size76 KB
Load time46 ms
Start875 ms
RiskFOUT — text flashes from fallback to web font
pxiByp8kv8JHgFVrLCz7Z1x...woff2swap
Size8 KB
Load time34 ms
Start876 ms
RiskFOUT — text flashes from fallback to web font
pxiByp8kv8JHgFVrLEj6Z1x...woff2swap
Size8 KB
Load time32 ms
Start876 ms
RiskFOUT — text flashes from fallback to web font
Optimization checklist
Preload critical fonts (priority=high)
Use woff2 format for all fonts
Set font-display to swap, optional, or fallback
Subset large fonts (≤100 KB each)
Fixing the unchecked items could save ~2 KB and ~4 ms
A+
Resource Caching
All resources properly cached
PASS
All resources properly cached
Info::
✓
No caching issues found
All static resources have appropriate caching headers.
A+
Critical Rendering Path
No render-blocking resources
PASS
No render-blocking resources
Info::
✓
No render-blocking resources detected
A+
Resource Hints
No optimization needed
PASS
No optimization needed
Info::
✓
No resource hint issues
A+
LCP Image Preload
LCP preload audit not available
PASS
LCP preload audit not available
Info::
✓
LCP image preload audit not available for this scan
A+
Server Response Intelligence
1 server-response signal(s) detected
PASS
1 server-response signal(s) detected
Info::
i
No `ETag` or `Last-Modified` -- conditional GET not supported
Without either header, browsers can't issue conditional GETs and refresh always re-downloads the full response body even when nothing changed. Add `ETag: "<hash>"` (or `Last-Modified: <date>`) on cacheable responses; the server returns 304 Not Modified when the client's cached copy is still valid, saving bandwidth.
Whether the site is served from green-energy infrastructure
PASS
Green Hosting
This site is hosted on green energy infrastructure
Provider: Seeweb
Network Waterfall
57 requests over 1327ms
INFO
HTML JavaScript CSS Images Fonts XHR/Fetch Other
Third-Party Script Cost
Per-script blocking time, transfer cost, and cache headers
INFO
77%of JavaScript execution is third-party
First-party Third-party260ms · 39KB · €3/mo
Script
Category
Execution
Transfer
Unused
Monthly Cost
Verdict
www.pinogalvagno.com
www.pinogalvagno.com
Other
205ms
6 KB
—
€2/mo
Costly
www.pinogalvagno.com
www.pinogalvagno.com
Other
55ms
33 KB
—
€1/mo
Optional
www.pinogalvagno.com
Other
Costly
Execution205ms
Transfer6 KB
Monthly Cost€2/mo
www.pinogalvagno.com
Other
Optional
Execution55ms
Transfer33 KB
Monthly Cost€1/mo
These scripts may cost more than they're worth
www.pinogalvagno.com adds 205ms and costs ~€2/month
77% of JavaScript execution time is spent on third-party scripts. Consider auditing which scripts are essential.
Why this matters
When third-party JS execution time exceeds your own, performance gains from frontend work are capped by code you don't own.
Learn more ▾▴
Every millisecond of third-party JS competes with your own for main-thread time. If their share is bigger than yours, optimization on your code base barely moves the needle. Audit, defer, or remove third-parties before further frontend optimization. Use Lighthouse's third-party audit to identify the worst offenders.
Source: web.dev
www.pinogalvagno.com takes 205ms of CPU time. Consider loading it asynchronously or replacing it with a lighter alternative.
Why this matters
This script has high main-thread execution time — optimize hot paths or defer.