Page summary

https://query.wikidata.org/querybuilder/

Tested 2026-05-26 05:27:15 using Chrome 148.0.7778.96 (runtime settings)

SummaryWaterfall MetricsVideoFilmstrip CoachPageXrayCPU
| Summary | | Download Video | Download Timeline Log | Download HAR | Download Console Logs | 

Summary

LCP1.428 s
CLS0.000
Coach96
Loading & responsiveness (median)
TTFB
639 ms
First Paint
1.428 s
Fully Loaded
1.424 s
Page weight & requests
Total transfer size
211.6 KB
Requests
10
CPU
CPU long tasks
1
CPU longest task duration
142 ms
CPU last long task at
1.222 s
Visual progress
First Visual Change
1.433 s
Speed Index
1.435 s
Visual Complete 85%
1.433 s
Visual Complete 99%
1.500 s
Last Visual Change
1.500 s
Screenshot of run 2

Timings Summary

Metricminmedianmeanmax
Visual Metrics
FirstVisualChange1.400 s1.433 s1.513 s1.900 s
LastVisualChange1.466 s1.500 s1.640 s2.200 s
SpeedIndex1.402 s1.435 s1.517 s1.908 s
LargestContentfulPaint1.400 s1.433 s1.513 s1.900 s
LastMeaningfulPaint1.400 s1.433 s1.513 s1.900 s
VisualReadiness66 ms100 ms127 ms300 ms
VisualComplete851.400 s1.433 s1.513 s1.900 s
VisualComplete951.400 s1.433 s1.513 s1.900 s
VisualComplete991.466 s1.500 s1.640 s2.200 s
Google Web Vitals
Time To First Byte (TTFB)637 ms639 ms640 ms643 ms
Largest Contentful Paint (LCP)1.404 s1.428 s1.516 s1.900 s
Cumulative Layout Shift (CLS)0000
More metrics
firstPaint1.404 s1.428 s1.516 s1.900 s
loadEventEnd1.102 s1.107 s1.158 s1.366 s
CPU
Total Blocking Time0 ms0 ms0 ms0 ms
Max Potential FID0 ms0 ms0 ms0 ms
CPU long tasks 1111
CPU last long task happens at1.217 s1.222 s1.324 s1.735 s
Waterfall | Download HAR | 

Waterfall

Run 2 SpeedIndex median

First paintFCPLCPDOMContentLoadedDOM interactiveLoadRender-blockingRedirectError

Video

Run 2 · median
Download video

Filmstrip

5 frames

Use --filmstrip.showAll to show all filmstrips.

0 s
1.2 sDOM Content Loaded Time 1.107 sPage Load Time 1.107 s
1.3 sCPU Long Task duration 135 ms
1.5 sFully Loaded 1.424 sFirst Contentful Paint 1.432 sLCP <P> 1.432 sFirst Visual Change 1.433 sVisual Complete 85% 1.433 sVisual Complete 95% 1.433 s
1.6 sLast Visual Change 1.533 sVisual Complete 99% 1.533 s
Performance advice | Best practice advice | Privacy advice | Page info | Technologies | 

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

96
1 error1 warning2 info
infoAdd decoding="async" to non-critical imagesdecodingAsync

The page has 3 images (out of 3) without a decoding hint. Add decoding="async" to non-critical images so the browser can decode them off the main thread.

Setting decoding="async" on an <img> tells the browser it can decode the image off the main thread, which keeps the page responsive to user interactions while images are being processed. The default ("auto") leaves the choice to the browser. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img#decoding

Offenders
error(50)Have a fast first contentful paintfirstContentfulPaint

First contentful paint can be improved (1.900 s). It is in the Google Web Vitals needs improvement range, slower than 1.8 seconds.

The First Contentful Paint (FCP) metric measures the time from when the page starts loading to when any part of the page content is rendered on the screen. For this metric, "content" refers to text, images (including background images), <svg> elements, or non-white <canvas> elements.

warn(80)Avoid CPU Long TaskslongTasks

The page has 1 CPU long task with the total of 124 ms. The total blocking time is 0 ms and 1 long task before first contentful paint with total time of 124 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
infoLong cache headers is goodcacheHeadersLong

The page has 8 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

Best practice advice

90
2 info
infoMeta descriptionmetaDescription

The page is missing a meta description.

Use a page description to make the page more relevant to search engines.

infoAvoid unnecessary headersunnecessaryHeaders

Privacy advice

74
6 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(0)Set a referrer-policy header to make sure you do not leak user information.referrerPolicyHeader

Set a referrer-policy header to make sure you do not leak user information.

Referrer Policy is a new header that allows a site to control how much information the browser includes with navigations away from a document and should be set by all sites. https://scotthelme.co.uk/a-new-security-header-referrer-policy/.

Offenders
warn(0)Set X-Content-Type-Options: nosniff to stop the browser from MIME-sniffing the response.xContentTypeOptionsHeader

Set X-Content-Type-Options: nosniff on the document response to prevent MIME-sniffing.

X-Content-Type-Options: nosniff prevents browsers from interpreting files as a different MIME type than what is declared in the Content-Type header. This blocks a class of cross-site scripting and content-type confusion attacks and should be set on every response. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options

Offenders

Page info

Page info

TitleWikidata Query Builder
Width1904
Height1287
DOM elements959
Avg DOM depth12
Max DOM depth25
Iframes0
Script tags1
Local storage0 b
Session storage0 b
Network Information API3g

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

3 technologies
Visual Metrics | Google Web Vitals | Largest Contentful Paint | Cumulative Layout Shift | Browser metrics | Long Aninimation Frames | Visual Elements | Server timings | 

Data from run 2

Visual Metrics

Visual progress
Visual progress at 0 s0.0s
Visual progress at 1.2 s1.2s
Visual progress at 1.3 s1.3s
Visual progress at 1.5 s1.5s
Visual progress at 1.6 s1.6s
FCP1.43s
LCP1.43s
VC851.43s
Long tasks
0.0s0.3s0.6s1.0s1.3s1.6s

Google Web Vitals

from run 2

Largest Contentful Paint

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

1.432 sLCP render time

Phase breakdown

  • TTFB637 ms
  • Resource load delay0 ms
  • Resource load duration0 ms
  • Element render delay795 ms

Element

Element type
<p>
Size (w × h)
81796
Load time
0 ms
Recalculate-style elements before LCP
432 (21.338 ms)

DOM path

body > div#app > div#app > div > main > p
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
First Contentful Paint info
Elements that needed recalculate style before FCP432
Time spent in recalculate style before FCP21.338 ms
Extra timings

Long Animation Frames

A long animation frame (LOAF) is a frame that took ≥ 50 ms from input to the next paint. The breakdown shows where that time went. Read more about the Long Animation Frames API.

Showing the top 10 longest animation frames.

Long animation frame #1
224.4 ms
  • Blocking87 ms
  • Work136.1 ms
  • Render1.3 ms
  • Pre-layout1 ms
  • Style & layout0.3 ms

Scripts that ran during this frame

Forced style and layout
40 ms
Invoker
Response.json.then
Invoker type
resolve-promise
Window attribution
self
Source char position
122456
Long animation frame #2
156.1 ms
  • Blocking0 ms
  • Work153.8 ms
  • Render2.3 ms
  • Pre-layout0 ms
  • Style & layout2.3 ms

No script attribution available for this frame.

Server timings

2 entries
NameDurationDescription
cache0 mspass
host0 mscp3070

Custom metrics collected through JavaScript

There are no custom configured scripts.

Extra metrics collected using scripting

There are no custom extra metrics from scripting.

Visual Elements2
Heading
Position (x, y)264, 56
Size (w × h)1 × 1
HTML snippet
<h1 class="visually-hidden"></h1>
LargestContentfulPaint
Display time1.433 s
Position (x, y)264, 145
Size (w × h)676 × 130
HTML snippet
<p class="querybuilder__description"></p>
Summary | Largest responses | Per content type | Per domain | Expires & last-modified | After onLoad | Render-blocking | 

PageXray

How the page is built.

HTTP versionHTTP/2.0
Total requests10
Total domains2
Transfer size211.6 KB
Content size776.2 KB
Missing compression0
Cookies40 third-party

Response codes

200
990.0%
204
110.0%

Requests and sizes per content type

7 types
ContentHeader SizeTransfer SizeContent SizeRequests
html0 b1.9 KB2.2 KB1
css0 b23.8 KB218.3 KB1
javascript0 b169.5 KB524.2 KB1
favicon0 b5.6 KB14.7 KB1
json0 b2.9 KB7.4 KB1
plain0 b819 B0 b1
svg0 b7.1 KB9.4 KB4
Total0 b211.6 KB776.2 KB10

Data per domain

2 domains
DomainTotal download timeTransfer SizeContent SizeRequests
query.wikidata.org3.760 s210.8 KB776.2 KB9
www.wikidata.org185 ms819 B0 b1

Expires & last-modified statistics

typeminmedianmax
Expires0 seconds1 hour1 hour
Last modified5 weeks45 weeks45 weeks

Requests loaded after onLoad event

6 requests

Includes requests done after load event end.

ContentTransfer SizeRequests
html0 b0
css0 b0
javascript0 b0
image0 b0
font0 b0
favicon5.6 KB1
plain819 B1
svg7.1 KB4
Total13.5 KB6

Requests loaded after onContentLoad

6 requests

Includes requests done after DOM content loaded.

ContentTransfer SizeRequests
html0 b0
css0 b0
javascript0 b0
image0 b0
font0 b0
favicon5.6 KB1
plain819 B1
svg7.1 KB4
Total13.5 KB6

Render blocking requests

2 assets

Render blocking information directly from Chrome.

BlockingIn body parser blockingPotentially blocking
100

Render blocking assets

2 assets
Long tasks | Per script blocking | Where time went | Forced reflows | Forced layout/script | Animations | 

CPU

Download the Chrome trace and drag-and-drop it into Performance in DevTools.

Long tasks

Tasks ≥ 50 ms blocking the main thread, collected via the Long Task API.

TBT0 ms
Max FID0 ms
Total long tasks1
Total time135 ms
Last task at1.222 s
Before FP135 ms1 task
Before FCP135 ms1 task
Before LCP135 ms1 task
After load135 ms1 task

Blocking time per script

How much each script blocked the main thread, derived from the Long Animation Frame API. The script that started each long frame is credited with the frame's blocking time — the closest answer to "which script should I fix to improve TBT" the platform exposes.

Top scripts blocking the main thread

1 of 1 script

Where the time went

Calculated from the Chrome trace.

Categories

269 ms total
scriptEvaluation117 ms43.5%
other73 ms27.1%
styleLayout47 ms17.5%
parseHTML14 ms5.2%
garbageCollection8 ms3.0%
paintCompositeRender7 ms2.6%
scriptParseCompile3 ms1.1%

Forced reflows

A forced reflow happens when JavaScript reads a layout-triggering property (offsetTop, getBoundingClientRect, …) inside a handler, forcing the browser to synchronously recompute layout. The scripts below caused most of the page's reflows — fix them in priority order.

Scripts causing reflows

2 reflows ≥ 2 ms across 1 script
Anonymous / inline
38 ms · 2 reflows · worst 23 ms

Forced layout per script

Each long animation frame reports how much time each script spent forcing synchronous style and layout — i.e. JavaScript reading layout-triggering properties mid-execution. Same actionable answer as forced reflows above but measured directly by the browser instead of inferred from the trace.

Scripts forcing layout

1 of 1 script

Non-composited animations

Animations that fell back from the compositor to the main thread, blocking each frame instead of running on the GPU. Each chip below is a CSS property the page tried to animate that Chrome couldn't hand to the compositor — swap it for a transform or opacity equivalent where you can.

Properties to fix

6 properties · 11 animations
  • border-bottom-color
  • border-left-color
  • border-right-color
  • border-top-color
  • color
  • box-shadow