Run 2 summary

https://xeltacut.xelta.ai

Tested 2026-08-08 06:35:04 using Chrome 150.0.7871.46 (runtime settings)

SummaryWaterfallMetricsRenderingCoachPageXrayThird party

Summary

Google Web Vitals

527 msTTFB
3.280 sLargest Contentful Paint
0.000Cumulative Layout Shift
49 msTotal Blocking Time

Loading

736 msFirst Paint
3.751 sFully Loaded
97 msMax Potential FID

Page weight & requests

1.8 MBTotal transfer size
6.2 MBTotal content size
29Requests

CPU

2Long tasks
1.106 sLast long task at

Visual progress

745 msFirst Visual Change
3.281 sSpeed Index
3.423 sVisual Complete 85%
3.559 sVisual Complete 99%
3.559 sLast Visual Change
Screenshot
Run 2 · after page complete

Waterfall

First paintFCPLCPDOMContentLoadedDOM interactiveLoadRender-blockingRedirectError

Rendering

Run 2
0.000 s
0s1s2s3s

The red band on the timeline marks when the main thread was busy with long tasks: moments when the page could not paint or respond, however the video looks.

Download video

Filmstrip

26 frames

Use --filmstrip.showAll to show all filmstrips.

Frame at 0 ms
0 ms
0 %
Frame at 700 ms
700 ms
0 %
Frame at 800 ms
800 ms
3 %
Frame at 900 ms
900 ms
3 %
Frame at 1.000 s
1.000 s
3 %
Frame at 1.100 s
1.100 s
3 %
Frame at 1.200 s
1.200 s
3 %
Frame at 1.300 s
1.300 s
3 %
Frame at 1.900 s
1.900 s
3 %
Frame at 2.000 s
2.000 s
3 %
Frame at 2.100 s
2.100 s
3 %
Frame at 2.200 s
2.200 s
3 %
Frame at 2.300 s
2.300 s
3 %
Frame at 2.400 s
2.400 s
3 %
Frame at 2.500 s
2.500 s
3 %
Frame at 2.600 s
2.600 s
3 %
Frame at 2.700 s
2.700 s
3 %
Frame at 2.800 s
2.800 s
3 %
Frame at 2.900 s
2.900 s
3 %
Frame at 3.000 s
3.000 s
3 %
Frame at 3.100 s
3.100 s
3 %
Frame at 3.200 s
3.200 s
3 %
Frame at 3.300 s
3.300 s
3 %
Frame at 3.400 s
3.400 s
69 %
Frame at 3.500 s
3.500 s
96 %
Frame at 3.600 s
3.600 s
100 %

Click a frame to seek the video to that moment. The dot marks frames where the page changed visually.

Why was rendering delayed?

Rendering was not meaningfully delayed. First paint landed at 736 ms on a 527 ms first byte; the 1 render-blocking request was done by 663 ms. The largest paint followed at 3.280 s.

Want to see how much CSS style-recalculation work delayed FCP and LCP, plus CPU long tasks? Run with --cpu.

Render blocking requests

1 request · 20.0 KB

Blocking requests delay both paints: the browser renders nothing until they arrive, so they push First Contentful Paint and everything after it, including the largest paint (LCP). Requests that block the parser inside the body stall everything after them in the document. Load JavaScript with defer or async, and keep non-critical CSS off the critical path with media attributes. Bars show when each request loaded on a clock that runs to the last paint (the dashed line is FCP, the clock ends at LCP); the gap after the bars is style and layout work. Web fonts are context, not blockers: text renders invisible or in a fallback face while they load, so a font finishing after a paint is the classic reason text changed late.

RequestWhen it loadedTransferDownload
document
xeltacut.xelta.ai · TTFB 527 ms
284 ms
847 B283 ms
css · xeltacut.xelta.ai
122 ms
20.0 KB122 ms
web font · xeltacut.xelta.ai
143 ms
48.0 KB143 ms
01.640 s2.460 sFCP 736 msLCP 3.280 s

Coach

The coach helps you find performance problems on your web page using web performance best practice rules. And gives you advice on privacy and best practices. Tested using Coach-core version 9.2.1.

Performance advice

86
2 errors7 warnings1 info
warn(0)Avoid redirecting the main documentdocumentRedirect

The main document gets redirected 1 time(s). Remove those redirect and make the page faster!

You should never ever redirect the main document, because it will make the page load slower for the user. Well, you should redirect the user if the user tries to use HTTP and there's an HTTPS version of the page. The coach checks for that. :)

Offenders
warn(0)Total JavaScript size shouldn't be too bigjavascriptSize
warn(20)Avoid extra requests by setting cache headerscacheHeaders

The page has 8 requests that are missing a cache time. Configure a cache time so the browser doesn't need to download them every time. It will save 15.4 kB the next access.

The easiest way to make your page fast is to avoid doing requests to the server. Setting a cache header on your server response will tell the browser that it doesn't need to download the asset again during the configured cache time! Always try to set a cache time if the content doesn't change for every request.

Offenders
warn(60)Avoid CPU Long TaskslongTasks

The page has 2 CPU long tasks with the total of 149 ms. The total blocking time is 49 ms . However the CPU Long Task is depending on the computer/phones actual CPU speed, so you should measure this on the same type of the device that your user is using. Use Geckoprofiler for Firefox or Chromes tracelog to debug your long tasks.

Long CPU tasks locks the thread. To the user this is commonly visible as a "locked up" page where the browser is unable to respond to user input; this is a major source of bad user experience on the web today. However the CPU Long Task is depending on the computer/phones actual CPU speed, so you should measure this on the same type of the device that your user is using. To debug you should use the Chrome timeline log and drag/drop it into devtools or use Firefox Geckoprofiler.

Offenders
  • self
  • self
error(80)Have a fast largest contentful paintlargestContentfulPaint

Largest contentful paint can be improved 3.280 s. It is in the Google Web Vitals needs improvement range, slower than 2.5 seconds.

Largest contentful paint is one of Google Web Vitals and reports the render time of the largest image or text block visible within the viewport, relative to when the page first started loading. To be fast according to Google, it needs to render before 2.5 seconds and results over 4 seconds is poor performance.

Offenders
  • <h1 class="text-3xl font-bold tracking-tight"></h1>
warn(90)Avoid doing redirectsassetsRedirects

The page has 1 redirect. 1 of the redirects are from the base domain, please fix them!

A redirect is one extra step for the user to download the asset. Avoid that if you want to be fast. Redirects are even more of a showstopper on mobile.

Offenders
warn(90)Always compress text contentcompressAssets

The page has 1 request that are served uncompressed. You could save a lot of bytes by sending them compressed instead.

In the early days of the Internet there were browsers that didn't support compressing (gzipping) text content. They do now. Make sure you compress HTML, JSON, JavaScript, CSS and SVG. It will save bytes for the user; making the page load faster and use less bandwith.

Offenders
URLTransferContent
https://xeltacut.xelta.ai/projects8.5 KB35.8 KB
infoLong cache headers is goodcacheHeadersLong

The page has 6 requests that have a shorter cache time than one year (but still a cache time).

Setting a cache header is good. Setting a long cache header (a year) is even better because the asset will stay in the browser cache across visits. For content-hashed URLs (e.g. app.4af2.css) you can safely use Cache-Control: max-age=31536000, immutable. For unversioned URLs that may change, use a revalidating strategy instead.

Offenders
error(94)Avoid using incorrect mime typesmimeTypes

The page has 6 misconfigured mime types.

It's not a great idea to let browsers guess content types (content sniffing), in some cases it can actually be a security risk.

Offenders
warn(95)Inline CSS for faster first renderinlineCss

The page has both inline CSS and CSS requests even though it uses a HTTP/2-ish connection. If you have many users on slow connections, it can be better to only inline the CSS. Run your own tests and check the waterfall graph to see what happens.

In the early days of the Internet, inlining CSS was one of the ugliest things you can do. That has changed if you want your page to start rendering fast for your user. Always inline the critical CSS when you use HTTP/1 and HTTP/2 (avoid doing CSS requests that block rendering) and lazy load and cache the rest of the CSS. It is a little more complicated when using HTTP/2. Does your server support HTTP push? Then maybe that can help. Do you have a lot of users on a slow connection and are serving large chunks of HTML? Then it could be better to use the inline technique, becasue some servers always prioritize HTML content over CSS so the user needs to download the HTML first, before the CSS is downloaded.

Best practice advice

99
2 info
infoAvoid unnecessary headersunnecessaryHeaders

There are 29 responses that sets a server header.

Do not send headers that you don't need. We look for p3p, cache-control and max-age, pragma, server and x-frame-options headers. Have a look at Andrew Betts - Headers for Hackers talk as a guide https://www.youtube.com/watch?v=k92ZbrY815c or read https://www.fastly.com/blog/headers-we-dont-want.

Offenders
infoDo not send too long headerslongHeaders

https://xeltacut.xelta.ai/?_rsc=vf1hk has a header report-to that is 634 characters long.

Do not send response headers that are too long.

Offenders

Privacy advice

81
5 warnings2 info
warn(0)Declare a referrer policy on the documentreferrerPolicy

No <meta name="referrer"> tag was found on the page. Set a Referrer-Policy response header (preferred) or add a meta tag, for example <meta name="referrer" content="strict-origin-when-cross-origin">.

Without an explicit referrer policy the browser falls back to the user-agent default and may leak the full URL of the previous page (including query strings) to every cross-origin request. Set a Referrer-Policy response header (preferred) or a <meta name="referrer"> tag in the document. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy

warn(0)Use a strict Content-Security-Policy header to mitigate cross-site scripting (XSS) attacks.contentSecurityPolicyHeader

Set a Content-Security-Policy header to mitigate cross-site scripting attacks. You can start with a Content-Security-Policy-Report-Only header, which only reports violations rather than blocking them.

A Content-Security-Policy response header tells the browser which sources of script, style, and other content are allowed. The most effective form is a strict CSP using nonces or hashes together with strict-dynamic; the worst is a missing header, with unsafe-inline and unsafe-eval close behind. https://web.dev/articles/strict-csp

Offenders
infoSet a Cross-Origin-Embedder-Policy header so cross-origin subresources opt in to being embedded.crossOriginEmbedderPolicyHeader

Set a Cross-Origin-Embedder-Policy header (typically require-corp or credentialless) on the document response to control cross-origin embedding.

Cross-Origin-Embedder-Policy (COEP) makes the page refuse to load cross-origin subresources unless they explicitly opt in via CORP or CORS. Together with Cross-Origin-Opener-Policy it puts the page in a cross-origin isolated context, which mitigates cross-window side-channel attacks (Spectre) and unlocks high-resolution timers and SharedArrayBuffer. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Embedder-Policy

Offenders
warn(0)Set a Cross-Origin-Opener-Policy header to isolate the page from cross-origin windows.crossOriginOpenerPolicyHeader

Set a Cross-Origin-Opener-Policy header (typically same-origin) on the document response to isolate the page from cross-origin windows.

Cross-Origin-Opener-Policy (COOP) lets a page sever its window-group ties to cross-origin documents that opened it or that it opens. Together with Cross-Origin-Embedder-Policy it puts the page in a cross-origin isolated context, which mitigates cross-window side-channel attacks (Spectre) and unlocks high-resolution timers and SharedArrayBuffer. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy

Offenders
infoSet a Cross-Origin-Resource-Policy header to limit who may embed the page.crossOriginResourcePolicyHeader

Set a Cross-Origin-Resource-Policy header (same-origin, same-site or cross-origin) on the document response to limit who may embed it.

Cross-Origin-Resource-Policy (CORP) is a per-response opt-in that tells the browser which origins are allowed to embed the resource. It blocks cross-origin or cross-site no-cors embedding (img, script, iframe, etc.) and is one of the building blocks of cross-origin isolation. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Resource-Policy

Offenders
warn(0)Set a Permissions-Policy header to control which browser features the page can use.permissionsPolicyHeader

Set a Permissions-Policy header to control which browser features the page can use.

The Permissions-Policy response header (the successor to Feature-Policy) lets a site explicitly opt in or out of powerful browser features such as camera, microphone, geolocation, payment and clipboard. Setting a strict policy reduces the attack surface and limits what embedded third parties can do. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy

Offenders
warn(97)Do not share user data with third parties.thirdPartyPrivacy

The page has 3% requests that are 3rd party (1 requests with a size of 11.6 kB). The page do 1 utility request and uses 1 utility tool.

Using third party requests shares user information with that third party. Please avoid that! The project https://github.com/patrickhulce/third-party-web is used to categorize first/third party requests.

Offenders

Page info

A snapshot of what the browser actually built for this page: the document, how big and deep the DOM tree is and what it kept in storage. Big, deep trees are slower to style and lay out, so the counts Chrome warns about carry a flag.

Page info

Document

What the page says it is and how large it rendered.

TitleXeltaCutThe document title, shown in the browser tab and used by search results.
Layout viewport1350 × 726 pxThe width the page laid out at, and the full height of the rendered document.

DOM structure

How much markup the browser has to build, style and lay out.

DOM elements117Total HTML elements. Fewer means less for the browser to style, lay out and paint.
Avg DOM depth4How deeply elements are nested on average.
Max DOM depth9The deepest nesting on the page. Deep branches cost more style recalculation.
Iframes0No embedded documents on this page.
Script tags26Number of script elements. More scripts usually means more main-thread work.

Storage and connection

What the page stored on the client, and the network it was tested on.

Local storage44 BData the page saved in localStorage, kept across visits.
Session storage116 BData kept in sessionStorage for this tab session only.
Connection type4GWhat the Network Information API reported for the test connection.

Technologies used to build the page

Data collected using Coach-core version 9.2.1. With updated code from Webappanalyzer 2026-05-04. Use --browsertime.firefox.includeResponseBodies html or --browsertime.chrome.includeResponseBodies html to help Wappalyzer find more information about technologies used.

Detected technologies

4 technologies

Third-party tools

1 tool

Data collected using Third Party Web version 0.29.2.

Utility
  • Cloudflare

Visual Metrics

Visual milestones

all times from navigation start
Speed Index3.28 show quickly the page looked done
First Visual Change0.74 sfirst paint reaches the screen
Last Visual Change3.56 sscreen stops changing · 2.81 s after first
nothing painted yet
0.74 sFirst Visual Change
Visual Complete 85% · Visual Complete 95%3.42 s
Visual Complete 99% · Last Visual Change3.56 s
Visual Readiness2.81 s· first to last change
01.0 s2.0 s3.0 s
Content milestones
Perception index
Visual progress
Visual progress at 0 s0.0s
Visual progress at 1 s1.0s
Visual progress at 1.3 s1.3s
Visual progress at 2.2 s2.2s
Visual progress at 2.5 s2.5s
Visual progress at 2.9 s2.9s
Visual progress at 3.2 s3.2s
Visual progress at 3.6 s3.6s
FCP0.74s
LCP3.28s
VC853.42s
Long tasks
0.0s0.7s1.4s2.2s2.9s3.6s

Google Web Vitals

527 msTTFB
Good
3.280 sLCP
Needs improvement

Largest Contentful Paint

When the page main content is rendered, collected via the Largest Contentful Paint API. Read more about Largest Contentful Paint.

3.280 sLCP render time

Phase breakdown

  • TTFB527 ms
  • Resource load delay0 ms
  • Resource load duration0 ms
  • Element render delay2.753 s

Element

Element type
<h1>
Size (w × h)
6696
Load time
0 ms

DOM path

body > div:eq(1) > div > div:eq(0) > div > h1
LCP

The LCP element is highlighted in the screenshot. If nothing is highlighted the element was removed before the screenshot or the LCP API couldn't find it.

Cumulative Layout Shift

How much the page's content shifts as it loads, collected via the Cumulative Layout Shift API.

0.000cumulative layout shift score

No layout shifts were detected on this page.

Browser Metrics

Navigation Timing
Extra timings

Server timings

Timing data the server chose to expose through Server-Timing response headers on the main document — typically backend time, cache status or experiment flags.

Server timings

4 entries
NameDurationDescription
cfCacheStatus0 msDYNAMIC
cfEdge7 ms
cfOrigin0 ms
cfWorker196 ms

Custom metrics collected through JavaScript

There are no custom configured scripts.

Extra metrics collected using scripting

There are no custom extra metrics from scripting.

Chrome internal metrics (CDP)33
Audio handlers0
Audio worklet processors0
Documents1
Frames1
JS event listeners361
Layout objects106
Media key sessions0
Media keys0
Nodes221
Resources27
Context lifecycle state observers25
V8 per context datas2
Worker global scopes0
Uacss resources0
Rtc peer connections0
Resource fetchers1
Ad subframes0
Detached script states0
Array buffer contents7
Layout count4
Recalc style count140
Layout duration11
Recalc style duration32
Dev tools command duration9
Script duration1825
V8 compile duration2
Task duration2420
Task other duration542
Thread time2
Process time4
JS heap used size8511108
JS heap total size90701824
First meaningful paint3279

PageXray

How the page is built.

HTTP versionHTTP/2.0
Total requests29
Total domains3
Transfer size1.8 MB
Content size6.2 MB
Missing compression1

Main document

status 200 · 1 redirect

https://xeltacut.xelta.ai/projects

HeaderValue
alt-svch3=":443"; ma=86400
cache-controls-maxage=31536000
cf-cache-statusDYNAMIC
cf-raya27c7fb9bdf5e59b-DEL
content-typetext/html; charset=utf-8
dateSat, 08 Aug 2026 06:35:04 GMT
expect-ctmax-age=86400, enforce
location/projects
nel{"report_to":"cf-nel","success_fraction":0.0,"max_age":604800}
referrer-policysame-origin strict-origin-when-cross-origin
report-to{"group":"cf-nel","max_age":604800,"endpoints":[{"url":"https://a.nel.cloudflare.com/report/v4?s=O8PM9s9DB3W7IVzSh9QyCkRbNgph1%2BmRzMa%2BWw5M8VUa55uf2AnY1Q%2Fga%2FfgTpvcJJcjDvc04voaP31JyIULNZrJsuLtZ2Pv9R7mCBmmGX1otpKXHsxAGiSzBaSEna6XREX2"}]}
servercloudflare
server-timingcfCacheStatus;desc="DYNAMIC" cfEdge;dur=8,cfOrigin;dur=0,cfWorker;dur=204
speculation-rules"/cdn-cgi/speculation"
strict-transport-securitymax-age=31536000; includeSubDomains; preload
varyrsc, next-router-state-tree, next-router-prefetch, next-router-segment-prefetch, Accept-Encoding
x-content-type-optionsnosniff
x-edge-served-byAP
x-frame-optionsSAMEORIGIN
x-nextjs-cacheHIT
x-nextjs-prerender1, 1
x-nextjs-stale-time300
x-xss-protection1; mode=block

Response codes

200
2793.1%
204
13.4%
307
13.4%

Requests and sizes per content type

9 types

Transfer size1.8 MB

  • other67.9%
  • javascript27.1%
  • font2.6%
  • css1.1%
  • html0.47%
  • image0.40%
  • favicon0.27%
  • json0.05%
  • plain0.03%

Content size6.2 MB

  • other68.6%
  • javascript28.0%
  • css1.8%
  • font0.75%
  • html0.57%
  • favicon0.15%
  • image0.08%
  • json0.01%

Requests28

  • javascript46.4%
  • other21.4%
  • image10.7%
  • html3.6%
  • css3.6%
  • font3.6%
  • favicon3.6%
  • json3.6%
  • plain3.6%
ContentHeader SizeTransfer SizeContent SizeRequests
html0 b8.5 KB35.8 KB1
css0 b20.0 KB116.7 KB1
javascript0 b491.9 KB1.7 MB13
image0 b7.3 KB5.1 KB3
font0 b48.0 KB47.3 KB1
favicon0 b4.9 KB9.6 KB1
other0 b1.2 MB4.2 MB6
json0 b1020 B896 B1
plain0 b595 B0 b1
Total0 b1.8 MB6.2 MB28

Data per domain

3 domains
DomainTotal download timeTransfer SizeContent SizeRequests
xeltacut.xelta.ai6.044 s1.7 MB6.1 MB27
cdn.databuddy.cc228 ms13.1 KB36.6 KB1
static.cloudflareinsights.com69 ms11.3 KB30.9 KB1

Expires & last-modified statistics

typeminmedianmax
Expires0 seconds4 weeks1 year
Last modified2 weeks2 weeks7 weeks

Requests loaded after onLoad event

10 requests

Includes requests done after load event end.

ContentTransfer SizeRequests
html0 b0
css0 b0
javascript0 b0
image7.3 KB3
font0 b0
favicon4.9 KB1
plain595 B1
other1.2 MB5
Total1.2 MB10

Requests loaded after onContentLoad

10 requests

Includes requests done after DOM content loaded.

ContentTransfer SizeRequests
html0 b0
css0 b0
javascript0 b0
image7.3 KB3
font0 b0
favicon4.9 KB1
plain595 B1
other1.2 MB5
Total1.2 MB10

Third party

Third party requests categorised by Third party web version 0.29.2.

Third-party requests1
Tools1
Categories1

Categories

1 category

Requests by category1

  • utility1 req · 1 tool100.0%

Third party requests and tools

1 category

Unmatched third party domains

1 domain

Domains that didn't match any tool in Third party web. If you are sure they are third party domains, please do a PR to that project. You can also fine tune the list using --firstParty.

  • cdn.databuddy.cc

First party vs third party

27 first · 2 third party

Transfer size1.8 MB

  • First party1.7 MB98.7%
  • Third party24.4 KB1.3%

Content size6.2 MB

  • First party6.1 MB98.9%
  • Third party67.4 KB1.1%

Requests29

  • First party2793.1%
  • Third party26.9%

First party requests and sizes per content type

27 requests

Calculated using .*xelta.* (use --firstParty to configure).

ContentHeader SizeTransfer SizeContent SizeRequests
html0 b8.5 KB35.8 KB1
css0 b20.0 KB116.7 KB1
javascript0 b467.4 KB1.7 MB11
image0 b7.3 KB5.1 KB3
font0 b48.0 KB47.3 KB1
favicon0 b4.9 KB9.6 KB1
other0 b1.2 MB4.2 MB6
json0 b1020 B896 B1
plain0 b595 B0 b1
TotalN/A1.7 MB6.1 MB27

Third party requests and sizes per content type

2 requests
ContentHeader SizeTransfer SizeContent SizeRequests
html0 b0 b0 b0
css0 b0 b0 b0
javascript0 b24.4 KB67.4 KB2
image0 b0 b0 b0
font0 b0 b0 b0
favicon0 b0 b0 b0
TotalN/A24.4 KB67.4 KB2