Page summary

https://www.wikidata.org/wiki/Q64

Tested 2026-08-24 22:20:33 using Chrome 151.0.7922.75 (runtime settings)

SummaryWaterfallMetricsRenderingCoachPageXrayCPU

This page is visually stable, but slow to paint, janky to interact with, loose on best practices and weak on user privacy.

77 / 100
Coach overall
78 / 100
Performance
78 / 100
Best practice
76 / 100
Privacy

How it loaded →

0 → 6.466 s · median run
Frame at 0 ms
start
Frame at 1300 ms
1.300 s
Frame at 2300 ms
2.300 s
Frame at 2900 ms
2.900 s
Frame at 3300 ms
3.300 s
Frame at 6500 ms
Complete6.500 s
1.300 s
First Visual Change
1.677 s
Speed Index
1.300 s
Visual Complete 85%
6.466 s
Last Visual Change
TTFB404 msLCP6.460 sTBT4.070 sCLS0.08

What to act on · top recommendations

Have a fast largest contentful paint

0 / 100

Largest contentful paint is poor 7.156 s. It is in the Google Web Vitals poor range, slower than 4 seconds.

Avoid CPU Long Tasks

0 / 100

The page has 11 CPU long tasks with the total of 5.105 s. The total blocking time is 4.137 s and 1 long task before first contentful paint with total time of 468 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.

Serve images in modern formats (AVIF, WebP)

0 / 100

The page ships 40 images (out of 40) in JPEG/PNG/GIF without a modern alternative. Wrap them in a <picture> with a <source type="image/avif"> or "image/webp" before the legacy <img>, or serve modern formats from your image pipeline directly. AVIF and WebP usually deliver 25–50% smaller files at the same quality.

Google Web Vitals

min · median · mean · max of 5 runs
MetricMinMedianMeanMaxRuns agree?
Time To First Byte (TTFB)403 ms404 ms408 ms422 msstable ±2%
Largest Contentful Paint (LCP)6.352 s6.460 s6.567 s7.156 svaries ±6%
Cumulative Layout Shift (CLS)0.08410.08410.08410.0841identical

Visual Metrics

min · median · mean · max of 5 runs
MetricMinMedianMeanMaxRuns agree?
First visual change1.300 s1.300 s1.307 s1.333 sstable ±1%
Last visual change6.333 s6.466 s6.566 s7.166 svaries ±6%
Speed index1.667 s1.677 s1.690 s1.726 sstable ±2%
Largest image1.300 s1.300 s1.307 s1.333 sstable ±1%
Heading1.300 s1.300 s1.307 s1.333 sstable ±1%
Largest contentful paint6.333 s6.466 s6.566 s7.166 svaries ±6%
Last meaningful paint6.333 s6.466 s6.566 s7.166 svaries ±6%
Visual readiness5.033 s5.133 s5.260 s5.866 svaries ±8%
Visual complete 851.300 s1.300 s1.307 s1.333 sstable ±1%
Visual complete 956.333 s6.466 s6.566 s7.166 svaries ±6%
Visual complete 996.333 s6.466 s6.566 s7.166 svaries ±6%

CPU

min · median · mean · max of 5 runs
MetricMinMedianMeanMaxRuns agree?
Total Blocking Time4.001 s4.070 s4.070 s4.137 sstable ±2%
Max Potential FID2.888 s2.922 s2.948 s3.052 sstable ±3%
CPU long tasks 11111112stable ±5%
CPU last long task happens at7.855 s8.250 s8.307 s8.761 svaries ±5%

More metrics

min · median · mean · max of 5 runs
MetricMinMedianMeanMaxRuns agree?
First paint1.276 s1.292 s1.300 s1.332 sstable ±2%
Load event end2.149 s2.168 s2.164 s2.174 sstable ±1%

User Timing

min · median · mean · max of 5 runs
MetricMinMedianMeanMaxRuns agree?
mwStartup1.280 s1.299 s1.295 s1.306 sstable ±1%
wbInitStart3.201 s3.215 s3.225 s3.267 sstable ±1%
wbInitEnd6.505 s6.612 s6.728 s7.318 svaries ±6%

Waterfall

Run 2 SpeedIndex median

First paintFCPLCPDOMContentLoadedDOM interactiveLoadRender-blockingRedirectError

Rendering

Run 2 · median
0.000 s
0s2s4s6s

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

13 frames

Use --filmstrip.showAll to show all filmstrips.

Frame at 0 ms
0 ms
0 %
Frame at 800 ms
800 ms
0 %
Frame at 1.300 s
1.300 s
92 %
Frame at 1.400 s
1.400 s
92 %
Frame at 2.200 s
2.200 s
92 %
Frame at 2.300 s
2.300 s
92 %
Frame at 2.700 s
2.700 s
92 %
Frame at 2.900 s
2.900 s
93 %
Frame at 3.100 s
3.100 s
93 %
Frame at 3.200 s
3.200 s
93 %
Frame at 3.300 s
3.300 s
93 %
Frame at 3.500 s
3.500 s
93 %
Frame at 6.500 s
6.500 s
100 %

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

Visual instability

15.65 % of pixels ever changed · 0 % changed 5+ times
Heatmap of how often each pixel changed while the page loaded

The whole recording in one image: every pixel is tinted by how often it changed. Amber changed once, deep red changed ten or more times. The scale is fixed, so heatmaps from different runs compare directly.

Flat amber is a page that painted once and stayed put. Red speckle in the shape of the text means the same pixels repainted over and over, usually invisible rendering noise that inflates Last Visual Change and Speed Index. A solid red block is a genuinely restless area, like an ad or a carousel.

Frames

How smoothly Chrome delivered frames to the screen during the test. Dropped counts only frames Chrome flags as affecting smoothness. On mostly-static pages the longest gap includes idle time where there was simply nothing to draw.

Frames shown10
Partial1
Dropped2
Effective FPS4.9
Longest gap1.253 sat 1.306 s

Why was rendering delayed?

Rendering was not meaningfully delayed. First paint landed at 1.288 s on a 404 ms first byte; the 2 render-blocking requests were done by 751 ms and the remaining ~537 ms is style and layout work (227 ms of it measured style recalculation). The largest paint followed at 6.460 s.

Style recalculation

measured by Chrome during this run

Style the browser had to recalculate before it could paint: many elements or a lot of time spent here points at expensive CSS on the critical rendering path. The recalculation count and the largest single one tell the two problems apart: one massive style change touching most of the page (few recalculations, the largest close to the total) needs different medicine than thousands of tiny ones (many recalculations, each tiny).

One large recalculation dominates. Restyling 21 506 elements cost 227 ms before the page painted (17.6 % of the time to First Contentful Paint), and a single recalculation of 21 338 elements accounts for 215 ms of it. Look for one class or inline-style change on a large container near the top of the DOM that restyles the whole subtree at once. The changes driving it are listed under Style invalidations below.

Before first & largest contentful paint

Recalculations21
Elements21506
Total time227.22 ms
Largest recalculation21338 elements · 215.438 ms

The recalculation work before first paint is 17.6 % of the time to First Contentful Paint.

Forced reflows before the page painted

measured by Chrome during this run

JavaScript read a layout value (offsetTop, getBoundingClientRect, …) while the page was mid-change, so the browser had to re-layout synchronously, work that blocks rendering. Reflows before First Contentful Paint delayed the first pixels; reflows before Largest Contentful Paint delayed the main content.

Forced reflows before FCP0
Time spent in forced reflows before FCP0 ms
Forced reflows before LCP50
Time spent in forced reflows before LCP344.1 ms

That is 5.3 % of the time to Largest Contentful Paint. The number of reflows matters more than the milliseconds: layout thrashing multiplies on slower devices.

See every forced reflow for the whole page load on the CPU tab

Render blocking requests

3 requests · 59.4 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.

RequestWhen it loadedTransferDownload
document
www.wikidata.org · TTFB 404 ms
692 ms
139.8 KB691 ms
ext.kartographer.style + 13 more modulesblocking
css · load.php styles batch · www.wikidata.org
328 ms
33.7 KB328 ms
site.stylesblocking
css · load.php styles batch · www.wikidata.org
305 ms
2.5 KB305 ms
startuppotentially blocking
javascript · load.php startup · www.wikidata.org
335 ms
23.1 KB335 ms
03.230 s4.845 sFCP 1.288 sLCP 6.460 s

Slowest CSS selectorsProfile run

How long Chrome spent testing each CSS selector against the page while recalculating styles. A selector with many match attempts and zero matches is evaluated against the document over and over for rules that never apply.

Selector matching cost 224 ms. The wasted-work list below (selectors tried thousands of times that never match) is the place to start.

Matching time224 ms
Match attempts4 645 653
Matches189 612

Selectors by matching time

top 25
SelectorTimeAttemptsMatches
.wikibase-statementgrouplistview :target8.13 ms50 6900
body.mw-mmv-lightbox-open > :not(.mw-notification-area-overlay)5.69 ms27 2440
.wikibase-entityview > *3.84 ms50 6906
.skin-theme-clientpref-night .ns-100 .mw-parser-output :not(.notheme):not(a)2.59 ms50 6900
.ve-not-available a:has(+ .mw-editsection-divider + a.mw-editsection-visualeditor:last-of-type)::after2.41 ms6 0110
a:where(:not([role="button"])):visited2.18 ms11 9865 920
.wikibase-sitelinklistview .wikibase-sitelinklistview-listview > *2.09 ms50 6901 002
.mw-parser-output a2.02 ms6 0115 880
a:where(:not([role="button"])):visited:hover2.01 ms11 9860
#mw-content-text a[href]1.99 ms5 9935 862

Wasted selector work: attempts that never match

top 25
SelectorAttemptsTime
.wikibase-sitelinklistview .wikibase-sitelinkview .wikibase-removetoolbar-container *50 6901.80 ms
.cdx-message__content > :last-child50 6901.56 ms
.skin-theme-clientpref-night .ns-100 .mw-parser-output :not(.notheme):not(a)50 6902.59 ms
.cdx-message__content > *50 6901.74 ms
.wikibase-statementgrouplistview :target50 6908.13 ms
.cdx-message__content > :first-child50 6901.48 ms
.mw-body blockquote > :first-child50 6901.71 ms
.mw-body blockquote > :last-child50 6901.51 ms
.center *50 6901.77 ms
.vector-search-box .vector-typeahead-search-container .vector-typeahead-search-scope-select .cdx-select-vue div33 8791.11 ms

Style invalidationsProfile run

Why the browser had to recalculate style and layout: every DOM/style change invalidates some set of nodes, and the same class or attribute churning over and over is the pattern to hunt. Counts, not milliseconds: the time is in the style recalculation numbers above.

Chase what keeps changing after the page is up. 8 027 style recalculations and 3 914 layout invalidations fired after first paint, on a page the user was already looking at. The biggest driver is attribute style (185×). Start with the script under "Scripts causing invalidations" that keeps triggering it.

Style recalculations8 1588 027 after first paint
Layout invalidations31 9993 914 after first paint

Changes that keep invalidating

top 15
  • attribute: style185×
  • attribute: class74×
  • pseudo: disabled36×
  • pseudo: enabled36×
  • attribute: disabled33×
  • attribute: title15×
  • class: leaflet-grab12×
  • attribute: href
  • pseudo: link
  • pseudo: visited
  • class: mw-kartographer-interactive
  • class: leaflet-container
  • class: leaflet-touch
  • class: leaflet-fade-anim
  • pseudo: -webkit-any-link

Invalidation reasons

split at first paint

After first paint

Invalidations on a page the user was already looking at, the actionable half.

ReasonStyle recalculationsLayout
A stylesheet rule changed4 983
Related style rule2 291
An animation updated stylesAnimate transform and opacity so the compositor can run it off the main thread.363
A node was inserted into the page197
A :has() selector was re-evaluated:has() re-checks a whole subtree on any change inside it. Scope it tightly, or toggle a class in JavaScript instead.167
JavaScript changed an inline styleSet a class instead of writing element.style, so the browser can batch the work.26
An element entered layout2 319
An element left layout857
A style change forced layout704
An SVG element changed14
An element's size changed10
Unknown10

Before first paint: building the page

The page being constructed and styled for the first render. Expected work, shown for scale.

ReasonStyle recalculationsLayout
A stylesheet rule changed1
Related style rule40
A node was inserted into the page44
JavaScript changed an inline styleSet a class instead of writing element.style, so the browser can batch the work.40
UseFallback6
An element entered layout28 053
An element left layout2
A style change forced layout1
An SVG element changed11
An element's size changed9
Unknown7
Scrollbar changed2

Scripts causing invalidations

top 8

303 animations run on the main thread instead of on the browser's fast path that animates without blocking other page work (the compositor); they can make the rendering you see above janky. See them on the CPU tab.

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

78
1 error10 warnings3 info
error(0)Have a fast largest contentful paintlargestContentfulPaint

Largest contentful paint is poor 7.156 s. It is in the Google Web Vitals poor range, slower than 4 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
  • <div class="wikibase-descriptionview-container"></div>
warn(0)Avoid CPU Long TaskslongTasks

The page has 11 CPU long tasks with the total of 5.105 s. The total blocking time is 4.137 s and 1 long task before first contentful paint with total time of 468 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
  • self
  • self
  • self
  • self
  • self
  • self
  • self
  • self
  • self
warn(0)Serve images in modern formats (AVIF, WebP)modernImageFormats

The page ships 40 images (out of 40) in JPEG/PNG/GIF without a modern alternative. Wrap them in a <picture> with a <source type="image/avif"> or "image/webp" before the legacy <img>, or serve modern formats from your image pipeline directly. AVIF and WebP usually deliver 25–50% smaller files at the same quality.

AVIF and WebP routinely deliver 25–50% smaller files than JPEG and PNG at the same perceived quality, and every browser version still under support understands at least one of them. Ship modern formats either through a <picture> element with <source type="image/avif"> / "image/webp" entries in front of the legacy <img>, or directly from a content-negotiating image pipeline that returns AVIF / WebP when the client accepts it. https://web.dev/articles/serve-images-webp

Offenders
warn(0)Total JavaScript size shouldn't be too bigjavascriptSize

The total JavaScript transfer size is 860 kB and the uncompressed size is 3.7 MB. This is totally crazy! There is really room for improvement here.

A lot of JavaScript often means you are downloading more than you need. How complex is the page and what can the user do on the page? Do you use multiple JavaScript frameworks?

Offenders
URLTransferContent
https://www.wikidata.org/w/load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector-202223.1 KB69.6 KB
https://www.wikidata.org/w/load.php...ta.org/w/load.php5.5 KB13.3 KB
https://www.wikidata.org/w/load.php...ta.org/w/load.php18.1 KB61.8 KB
https://www.wikidata.org/w/load.php...ta.org/w/load.php753.7 KB3.2 MB
https://www.wikidata.org/w/load.php...ta.org/w/load.php4.8 KB28.7 KB
https://auth.wikimedia.org/metawiki/wiki/Special:CentralAutoLogin/checkLoggedIn...gin/checkLoggedIn1.5 KB254 B
https://www.wikidata.org/w/load.php...ta.org/w/load.php30.8 KB115.2 KB
https://www.wikidata.org/w/load.php...ta.org/w/load.php2.4 KB6.0 KB
warn(10)Avoid extra requests by setting cache headerscacheHeaders

The page has 9 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 297.5 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
infoAdd decoding="async" to non-critical imagesdecodingAsync

The page has 33 images (out of 44) 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
warn(31)Lazy-load below-the-fold imageslazyLoadingImages

The page has 29 below-the-fold images without loading="lazy". Add loading="lazy" so the browser defers downloading and decoding them until the user scrolls them into view.

Adding loading="lazy" to an <img> tells the browser not to download or decode it until it is close to the viewport. For images that the user may never see (deep in the page, behind a tab, in a footer carousel), this saves bandwidth and main-thread time during initial render. The LCP image and any image in the initial viewport should NOT be lazy-loaded — that delays the first paint. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img#loading

Offenders
warn(50)Don't use private headers on static contentprivateAssets

The page has 6 requests with private headers. The main page has a private header. It could be right in some cases where the user can be logged in and served specific content. But if your asset is static it should never be private. Make sure that the assets really should be private and only used by one user. Otherwise, make it cacheable for everyone.

If you set private headers on content, that means that the content are specific for that user. Static content should be able to be cached and used by everyone. Avoid setting the cache header to private.

Offenders
infoLong cache headers is goodcacheHeadersLong

The page has 31 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
warn(90)Don't scale images in the browseravoidScalingImages

The page has 1 image that are scaled more than 100 pixels. It would be better if those images are sent so the browser don't need to scale them.

It's easy to scale images in the browser and make sure they look good in different devices, however that is bad for performance! Scaling images in the browser takes extra CPU time and will hurt performance on mobile. And the user will download extra kilobytes (sometimes megabytes) of data that could be avoided. Don't do that, make sure you create multiple version of the same image server-side and serve the appropriate one.

Offenders
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
infoMake each CSS response smalloptimalCssSize

https://www.wikidata.org/w/load.php?lang=en&modules=ext.kartographer.style%7Cext.uls.pt%7Cext.visualEditor.desktopArticleTarget.noscript%7Cext.wikidata-org.badges%7Cext.wikimediamessages.styles%7Cjquery.makeCollapsible.styles%7Cjquery.wikibase.toolbar.styles%7Cmediawiki.skins.legacy%7Cskins.vector.icons%2Cstyles%7Cskins.vector.search.codex.styles%7Cwikibase.alltargets%2Cdesktop%7Cwikibase.vector.scopedTypeaheadSearchStyles&only=styles&skin=vector-2022 size is 34.5 kB (34521) and that is bigger than the limit of 25 kB. Try to keep each CSS response under 25 kB.

Render-blocking CSS holds up the first paint until it has fully downloaded, parsed and applied, so smaller CSS files mean a faster start. Split your CSS into a small critical bundle inlined or eagerly loaded, with the rest lazy-loaded.

Offenders
URLTransferContent
https://www.wikidata.org/w/load.php...ta.org/w/load.php33.7 KB259.6 KB
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.

warn(99)Avoid slowing down the critical rendering pathavoidRenderBlocking

The page has 2 blocking requests and 0 in body parser blocking (0 JavaScript and 2 CSS). There are 1 potentially render blocking requests. You need to verify if it is render blocking: https://www.wikidata.org/w/load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector-2022

The critical rendering path is what the browser needs to do to start rendering the page. Every file requested inside of the head element will postpone the rendering of the page, because the browser need to do the request. Avoid loading JavaScript synchronously inside of the head (you should not need JavaScript to render the page), request files from the same domain as the main document (to avoid DNS lookups) and inline CSS for really fast rendering and a short rendering path.

Offenders

Best practice advice

78
2 warnings3 info
infoGive every image a textual alternativeimageAltText

The page has 11 images without an alt attribute. Add alt="..." with a description, or alt="" if the image is purely decorative.

Every <img> needs an alt attribute. Use alt="meaningful description" for content images so assistive technologies can announce them, or alt="" (or role="presentation" / aria-hidden="true") for purely decorative images so they are skipped. A missing alt attribute leaves screen reader users with no information at all. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img#alt

Offenders
infoAvoid unnecessary headersunnecessaryHeaders

There are 15 responses that sets both a max-age and expires header. There are 46 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
warn(50)Set a sensible viewport meta tagviewport

The viewport meta tag does not contain width=device-width, the browser may use a desktop-width fallback.

The viewport meta tag tells the browser how to lay out the page on small screens. Without it (or without width=device-width) the page is rendered at a desktop fallback width and scaled down, which makes text unreadable on mobile. Disabling zoom (user-scalable=no, maximum-scale<=1) is also an accessibility regression. https://developer.mozilla.org/en-US/docs/Web/HTML/Viewport_meta_tag

warn(50)Avoid too many third party requeststhirdParty

The page do more requests to third party domains (24 requests and 465.4 kB) then first party (22 requests and 1.3 MB). The regex .*wikidata.* was used to calculate first/third party requests.

Do not load most of your content from third party URLs.

infoDo not send too long headerslongHeaders

https://www.wikidata.org/wiki/Q64 has a header content-security-policy that is 4555 characters long. https://www.wikidata.org/wiki/Q64 has a header link that is 604 characters long. https://www.wikidata...ta.org/w/load.php has a header sourcemap that is 3104 characters long.

Do not send response headers that are too long.

Offenders

Privacy advice

76
5 warnings2 info
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)Avoid third party cookies that is used to track the user.thirdPartyCookies

The page sets 23 third party cookies.

Third party cookies are used to track the user. They are automatically blocked in Safari and Firefox.

Offenders
  • upload.wikimedia.org
  • upload.wikimedia.org
  • upload.wikimedia.org
  • maps.wikimedia.org
  • maps.wikimedia.org
  • maps.wikimedia.org
  • maps.wikimedia.org
  • maps.wikimedia.org
  • maps.wikimedia.org
  • maps.wikimedia.org
  • maps.wikimedia.org
  • maps.wikimedia.org
  • maps.wikimedia.org
  • maps.wikimedia.org
  • maps.wikimedia.org
  • maps.wikimedia.org
  • maps.wikimedia.org
  • maps.wikimedia.org
  • maps.wikimedia.org
  • maps.wikimedia.org
  • maps.wikimedia.org
  • maps.wikimedia.org
  • maps.wikimedia.org
warn(30)Use a strict Content-Security-Policy header to mitigate cross-site scripting (XSS) attacks.contentSecurityPolicyHeader

The policy allows 'unsafe-inline', which lets the browser execute inline scripts and styles directly from the page. Move to nonces or hashes plus 'strict-dynamic' so that inline injection cannot run. The policy allows 'unsafe-eval', which lets the page call eval() and Function(). Almost no application needs this; remove it.

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

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.

TitleBerlin - WikidataThe document title, shown in the browser tab and used by search results.
GeneratorMediaWiki 1.47.0-wmf.16The tool or CMS that generated the HTML, from the page generator meta tag.
Layout viewport1904 × 103304 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 elements34,118Very large, slows layout and styleTotal HTML elements. Fewer means less for the browser to style, lay out and paint.
Avg DOM depth22How deeply elements are nested on average.
Max DOM depth32Deep treeThe deepest nesting on the page. Deep branches cost more style recalculation.
Iframes0No embedded documents on this page.
Script tags4Number 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 storage1.8 MBData the page saved in localStorage, kept across visits.
Session storage0 bData kept in sessionStorage for this tab session only.
Connection type4GWhat the Network Information API reported for the test connection.

Resource hints

3 hints
dns-prefetch
  • https://meta.wikimedia.org/
  • https://www.wikidata.org/wiki/auth.wikimedia.org
preconnect
  • https://upload.wikimedia.org/

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
  • MediaWikiConfidence100
    Wikis
  • PHPConfidence100
    Programming languages
  • HSTSConfidence100
    Security

Data from run 2

Visual Metrics

Visual milestones

all times from navigation start
Speed Index1.68 show quickly the page looked done
First Visual Change1.30 sfirst paint reaches the screen
Last Visual Change6.47 sscreen stops changing · 5.17 s after first
nothing painted yet
≥85%
1.30 sFirst Visual Change · Visual Complete 85%
Visual Complete 95% · Visual Complete 99% · Last Visual Change6.47 s
Visual Readiness5.17 s· first to last change
02.0 s4.0 s6.0 s
Visual progress
Visual progress at 0 s0.0s
Visual progress at 1.3 s1.3s
Visual progress at 1.4 s1.4s
Visual progress at 2.3 s2.3s
Visual progress at 2.9 s2.9s
Visual progress at 3.2 s3.2s
Visual progress at 3.3 s3.3s
Visual progress at 6.5 s6.5s
FCP1.29s
LCP6.46s
VC851.30s
Long tasks
0.0s1.3s2.6s3.9s5.2s6.5s

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.

6.460 sLCP render time

Phase breakdown

  • TTFB404 ms
  • Resource load delay0 ms
  • Resource load duration0 ms
  • Element render delay6.056 s

Element

Element type
<div>
Size (w × h)
13104
Load time
0 ms
Style recalculation before LCP
21 recalculations touching 21506 elements (227.22 ms) — the largest touched 21338 elements (215.438 ms)

DOM path

body > div:eq(2) > div > div:eq(2) > main#content > div#bodyContent > div#mw-content-text > div:eq(0) > div#wb-item-Q64 > div:eq(0) > div:eq(0) > div:eq(2) > table > tbody > tr:eq(3) > td:eq(1) > div > div
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.084cumulative layout shift score

One shift is 100% of your 0.084 CLS. div:eq(2) moved at 6.416 s. Reserve space for whatever renders into that spot, a fixed height or an aspect-ratio box, so later content stops pushing the page around.

Elements that shifted

Worst first, showing shifts of 0.01 and up. Each percentage is that shift's exact share of the score.

  • 0.084
    100% of CLSshifted at 6.416 s
    <div class="wikibase-entitytermsview-entitytermsforlanguagelistview ">
    body > div:eq(2) > div > div:eq(2) > main#content > div#bodyContent > div#mw-content-text > div:eq(0) > div#wb-item-Q64 > div:eq(0) > div:eq(0) > div:eq(2)
    <div class="wikibase-statementgroupview listview-item" id="P31" data-property-id="P31">
    body > div:eq(2) > div > div:eq(2) > main#content > div#bodyContent > div#mw-content-text > div:eq(0) > div#wb-item-Q64 > div:eq(0) > div:eq(2) > div > div#P31
    <h2 class="wb-section-heading section-heading wikibase-statements" dir="auto" id="claims">
    body > div:eq(2) > div > div:eq(2) > main#content > div#bodyContent > div#mw-content-text > div:eq(0) > div#wb-item-Q64 > div:eq(0) > h2#claims
    <div id="q64$a908cf20-43b8-da2f-cfe0-550bb15fcc7f" class="wikibase-statementview wikibase-statement-q64$a908cf20-43b8-da2f-cfe0-550bb15fcc7f wb-normal listview-item">
    body > div:eq(2) > div > div:eq(2) > main#content > div#bodyContent > div#mw-content-text > div:eq(0) > div#wb-item-Q64 > div:eq(0) > div:eq(2) > div > div#P31 > div:eq(1) > div > div#q64$a908cf20-43b8-da2f-cfe0-550bb15fcc7f
    <div id="Q64$f1994725-4d8f-e8aa-7afe-c721b3356a1e" class="wikibase-statementview wikibase-statement-Q64$f1994725-4d8f-e8aa-7afe-c721b3356a1e wb-deprecated listview-item">
    body > div:eq(2) > div > div:eq(2) > main#content > div#bodyContent > div#mw-content-text > div:eq(0) > div#wb-item-Q64 > div:eq(0) > div:eq(2) > div > div#P31 > div:eq(1) > div > div#Q64$f1994725-4d8f-e8aa-7afe-c721b3356a1e
Layout shift

Elements that shifted by more than 0.01 are highlighted in the screenshot. If an element shifted outside the viewport, it won't appear here. Check the video or filmstrip to see the shift.

Browser Metrics

Navigation Timing
Extra timings
User Timing marks
mwStartup1.289 s
wbInitStart3.232 s
wbInitEnd6.612 s

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

3 entries
NameDurationDescription
cache0 mshit-front
host0 mscp3070
co_id0 ms4066635101

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 Elements3
LargestImagewikidatawiki.svg
Display time1.300 s
Position (x, y)246, 8
Size (w × h)50 × 50
HTML snippet
<img class="mw-logo-icon" src="/static/images/icons/wikidatawiki.svg" alt="" aria-hidden="true" height="50" width="50">
LargestImage preview
Heading
Display time1.300 s
Position (x, y)206, 90
Size (w × h)1200 × 40
HTML snippet
<h1 id="firstHeading" class="firstHeading mw-first-heading"></h1>
LargestContentfulPaint
Display time6.466 s
Position (x, y)632, 491
Size (w × h)348 × 44
HTML snippet
<div class="wikibase-descriptionview-container"></div>

PageXray

How the page is built.

HTTP versionHTTP/2.0
Total requests46
Total domains4
Transfer size1.7 MB
Content size7.2 MB
Missing compression0
Cookies2923 third-party

Main document

status 200 · 0 redirects

https://www.wikidata.org/wiki/Q64

HeaderValue
accept-ch
accept-rangesbytes
age47303
cache-controlprivate, s-maxage=0, max-age=0, must-revalidate, no-transform
content-encodinggzip
content-languageen
content-length136262
content-security-policyscript-src 'unsafe-eval' blob: 'self' meta.wikimedia.org *.wikimedia.org *.wikipedia.org *.wikinews.org *.wiktionary.org *.wikibooks.org *.wikiversity.org *.wikisource.org wikisource.org *.wikiquote.org *.wikidata.org *.wikifunctions.org *.wikivoyage.org *.mediawiki.org mediawiki.org wikimedia.org *.wmflabs.org *.wmcloud.org *.toolforge.org wss://*.toolforge.org *.jsdelivr.net unpkg.com cdnjs.cloudflare.com raw.githubusercontent.com *.github.com code.jquery.com cdn.mathjax.org use.typekit.net fonts.cdnfonts.com use.fontawesome.com i.ytimg.com rsms.me doi.org localhost https://localhost:* http://localhost:* wss://localhost:* ws://localhost:* *.google.com *.gstatic.com *.googleapis.com *.translate.yandex.net yastatic.net ya.ru radically.github.io cdn.sammdot.ca cdn.fontshare.com viaf.org publicai-proxy.alaexis.workers.dev iiif.archive.org api.flickr.com live.staticflickr.com api.anthropic.com api.openai.com api.publicai.co catalogo.pusc.it parsifal.urbe.it opac.sbn.it overpass-api.de api.openrouteservice.org archive.org *.openstreetmap.org *.waymarkedtrails.org *.thunderforest.com registry.ipe.wiki analytics.ipe.wiki qlever.dev app.goacoustic.com wikipedia-archive.ourworldindata.org api.inaturalist.org inaturalist-open-data.s3.amazonaws.com validator.w3.org db.onlinewebfonts.com fontlibrary.org 'unsafe-inline' auth.wikimedia.org; default-src 'self' data: blob: upload.wikimedia.org https://commons.wikimedia.org meta.wikimedia.org *.wikimedia.org *.wikipedia.org *.wikinews.org *.wiktionary.org *.wikibooks.org *.wikiversity.org *.wikisource.org wikisource.org *.wikiquote.org *.wikidata.org *.wikifunctions.org *.wikivoyage.org *.mediawiki.org mediawiki.org wikimedia.org *.wmflabs.org *.wmcloud.org *.toolforge.org wss://*.toolforge.org *.jsdelivr.net unpkg.com cdnjs.cloudflare.com raw.githubusercontent.com *.github.com code.jquery.com cdn.mathjax.org use.typekit.net fonts.cdnfonts.com use.fontawesome.com i.ytimg.com rsms.me doi.org localhost https://localhost:* http://localhost:* wss://localhost:* ws://localhost:* *.google.com *.gstatic.com *.googleapis.com *.translate.yandex.net yastatic.net ya.ru radically.github.io cdn.sammdot.ca cdn.fontshare.com viaf.org publicai-proxy.alaexis.workers.dev iiif.archive.org api.flickr.com live.staticflickr.com api.anthropic.com api.openai.com api.publicai.co catalogo.pusc.it parsifal.urbe.it opac.sbn.it overpass-api.de api.openrouteservice.org archive.org *.openstreetmap.org *.waymarkedtrails.org *.thunderforest.com registry.ipe.wiki analytics.ipe.wiki qlever.dev app.goacoustic.com wikipedia-archive.ourworldindata.org api.inaturalist.org inaturalist-open-data.s3.amazonaws.com validator.w3.org db.onlinewebfonts.com fontlibrary.org https://maps.wikimedia.org en.wikipedia.org en.wikibooks.org en.wikinews.org en.wikiquote.org en.wikisource.org en.wikiversity.org en.wikivoyage.org en.wiktionary.org www.mediawiki.org commons.wikimedia.org foundation.wikimedia.org incubator.wikimedia.org species.wikimedia.org wikimania.wikimedia.org www.wikifunctions.org auth.wikimedia.org; style-src 'self' data: blob: upload.wikimedia.org https://commons.wikimedia.org meta.wikimedia.org *.wikimedia.org *.wikipedia.org *.wikinews.org *.wiktionary.org *.wikibooks.org *.wikiversity.org *.wikisource.org wikisource.org *.wikiquote.org *.wikidata.org *.wikifunctions.org *.wikivoyage.org *.mediawiki.org mediawiki.org wikimedia.org *.wmflabs.org *.wmcloud.org *.toolforge.org wss://*.toolforge.org *.jsdelivr.net unpkg.com cdnjs.cloudflare.com raw.githubusercontent.com *.github.com code.jquery.com cdn.mathjax.org use.typekit.net fonts.cdnfonts.com use.fontawesome.com i.ytimg.com rsms.me doi.org localhost https://localhost:* http://localhost:* wss://localhost:* ws://localhost:* *.google.com *.gstatic.com *.googleapis.com *.translate.yandex.net yastatic.net ya.ru radically.github.io cdn.sammdot.ca cdn.fontshare.com viaf.org publicai-proxy.alaexis.workers.dev iiif.archive.org api.flickr.com live.staticflickr.com api.anthropic.com api.openai.com api.publicai.co catalogo.pusc.it parsifal.urbe.it opac.sbn.it overpass-api.de api.openrouteservice.org archive.org *.openstreetmap.org *.waymarkedtrails.org *.thunderforest.com registry.ipe.wiki analytics.ipe.wiki qlever.dev app.goacoustic.com wikipedia-archive.ourworldindata.org api.inaturalist.org inaturalist-open-data.s3.amazonaws.com validator.w3.org db.onlinewebfonts.com fontlibrary.org https://maps.wikimedia.org 'unsafe-inline'; object-src 'none'; report-uri /w/api.php?action=cspreport&format=json; report-to csp-report-to-endpoint
content-typetext/html; charset=UTF-8
dateMon, 24 Aug 2026 09:12:50 GMT
link<https://www.wikidata.org/wiki/Special:EntityData/Q64.json>; rel="alternate"; type="application/json",<https://www.wikidata.org/wiki/Special:EntityData/Q64.rdf>; rel="alternate"; type="application/rdf+xml",<https://www.wikidata.org/wiki/Special:EntityData/Q64.n3>; rel="alternate"; type="text/n3",<https://www.wikidata.org/wiki/Special:EntityData/Q64.ttl>; rel="alternate"; type="text/turtle",<https://www.wikidata.org/wiki/Special:EntityData/Q64.nt>; rel="alternate"; type="application/n-triples",<https://www.wikidata.org/wiki/Special:EntityData/Q64.jsonld>; rel="alternate"; type="application/ld+json"
nel{ "report_to": "wm_nel", "max_age": 604800, "failure_fraction": 0.05, "success_fraction": 0.0}
report-to{ "group": "wm_nel", "max_age": 604800, "endpoints": [{ "url": "https://intake-logging.wikimedia.org/v1/events?stream=w3c.reportingapi.network_error&schema_uri=/w3c/reportingapi/network_error/1.0.0" }] }
reporting-endpointscsp-report-to-endpoint='/w/api.php?action=cspreport&format=json';
servermw-web.eqiad.main-6798c57d8-g8pp6
server-timingcache;desc="hit-front", host;desc="cp3070",co_id;desc="4066635101"
strict-transport-securitymax-age=106384710; includeSubDomains; preload
varyAccept-Encoding,X-Subdomain,Cookie,Authorization,User-Agent
x-analytics
x-cachecp3070 miss, cp3070 hit/50
x-cache-statushit-front
x-client-ip138.201.135.103
x-content-type-optionsnosniff
x-request-idafd4bb29-0f16-4ec0-92c0-735522ebdd52

Response codes

200
4597.8%
302
12.2%

Requests and sizes per content type

7 types

Transfer size1.7 MB

  • javascript48.4%
  • image26.0%
  • json14.7%
  • html8.1%
  • css2.1%
  • svg0.71%
  • favicon0.09%

Content size7.2 MB

  • javascript48.5%
  • html24.0%
  • json18.1%
  • image5.7%
  • css3.6%
  • svg0.12%
  • favicon0.01%

Requests45

  • image48.9%
  • javascript17.8%
  • svg17.8%
  • json6.7%
  • css4.4%
  • html2.2%
  • favicon2.2%
ContentHeader SizeTransfer SizeContent SizeRequests
html0 b139.8 KB1.7 MB1
css0 b36.2 KB264.2 KB2
javascript0 b839.9 KB3.5 MB8
image0 b450.8 KB421.6 KB22
favicon0 b1.6 KB907 B1
svg0 b12.4 KB8.8 KB8
json0 b254.7 KB1.3 MB3
Total0 b1.7 MB7.2 MB45

Data per domain

4 domains
DomainTotal download timeTransfer SizeContent SizeRequests
www.wikidata.org8.138 s1.3 MB6.8 MB22
upload.wikimedia.org1.045 s32.3 KB27.2 KB3
auth.wikimedia.org186 ms1.5 KB254 B1
maps.wikimedia.org9.476 s420.7 KB395.1 KB20

Expires & last-modified statistics

typeminmedianmax
Expires0 seconds15 minutes1 year
Last modified2 hours57 years57 years

Requests loaded after onLoad event

31 requests

Includes requests done after load event end.

ContentTransfer SizeRequests
html0 b0
css0 b0
javascript39.4 KB4
image420.7 KB20
font0 b0
favicon1.6 KB1
json254.7 KB3
svg5.2 KB2
Total721.6 KB31

Requests loaded after onContentLoad

34 requests

Includes requests done after DOM content loaded.

ContentTransfer SizeRequests
html0 b0
css0 b0
javascript816.7 KB7
image420.7 KB20
font0 b0
favicon1.6 KB1
json254.7 KB3
svg5.2 KB2
Total1.5 MB34

CoverageProfile run

JavaScript and CSS coverage from the extra profile run made by --enableProfileRun, not from the timed iterations. For JS, Chrome tracks which blocks of each script actually ran: a byte is unused when the innermost block of code around it never ran. For CSS, Chrome records every selector that no element on the page matched during the iteration. Enable with --chrome.coverage on every run, or --enableProfileRun to keep the main run's timing metrics untouched. Unused bytes still cost network, parse and compile time for no benefit. Expand the section below for the full picture.

How is "unused" calculated?

sitespeed.io drives Chrome's V8 profiler and CSS rule tracker via the DevTools Protocol, the same machinery the DevTools Coverage panel uses. The two columns are populated by two different mechanisms.

JavaScript

Browsertime calls Profiler.startPreciseCoverage with detailed (block-level) mode at the start of the iteration and Profiler.takePreciseCoverage at the end. V8 returns nested ranges per function: an outer range covering the function body and inner ranges for sub-blocks (if/else, switch arms, ternaries). Each range has an execution count. A byte is "used" if the innermost range that covers it has count > 0, "unused" if it has count = 0, so we catch both functions that never ran AND dead branches inside functions that did.

CSS

Browsertime calls CSS.startRuleUsageTracking at the start of the iteration and CSS.stopRuleUsageTracking at the end. Chrome returns a flat list of rule-text ranges with a used flag: a rule is "used" if at least one element on the page matched it during the iteration. Both inline <style> blocks and external stylesheets are included.

What "this iteration" means

Coverage reflects only what executed during this run. Code behind a button click stays unused unless the iteration clicked the button. The collection window opens before navigation and closes when measure.stop() is reached, so the only way to count interactions is to drive them between measure.start() and measure.stop() inside a navigation script (pass a .js file as the input instead of a plain URL). Clicks, form fills and waits placed there all count toward "used". --preScript runs before the URL is loaded so it can't interact with the page being measured, and --postScript runs after coverage has already been collected, so neither helps here. Detailed coverage also tells V8 to skip some optimisations, which drifts timing metrics like LCP and TBT; that's why --enableProfileRun is the safer option for production measurement (it collects coverage in a separate iteration that doesn't count towards the medians).

JS total3.5 MB
JS unused1.7 MB
JS unused %47.9%
CSS total852.9 KB
CSS unused752.0 KB
CSS unused %88.2%

Where the bytes go

12 files · tile size is total bytes, tint is unused share

4.3 MB of script and style shipped, and 2.4 MB of it never ran on this page. The biggest win is load.php[scripts:dataValues]: 3.2 MB delivered, 1.6 MB unused, and inside it jquery.ui alone ships 251.5 KB of dead code.

load.php[scripts:dataValues]3.2 MB · 49% unused
inline588.7 KB · 93% unused
load.php[styles:ext.kartographer.style]259.6 KB · 78% unused
load.php[scripts:wikibase.tainted-ref]115.2 KB · 43% unused
load.php[startup]69.6 KB · 9% unused
load.php[scripts:ext.visualEditor.core.utils.parsing]61.8 KB · 77% unused
load.php[scripts:oojs-ui.styles.icons-alerts]28.7 KB · 0% unused
load.php[scripts:ext.gadget.AuthorityControl]13.1 KB · 17% unused
load.php[scripts:wikibase.lexeme]6.0 KB · 68% unused
3 more files12.6 KB · 34% unused
Unused shareunder 40%40 to 70%over 70%Click a bundle marked ⤢ to see its modules.

Where the unused bytes live

first-party regex .*wikidata.*
JS unused
First 1.7 MBThird 0 b
CSS unused
First 752.0 KBThird 0 b

JavaScript files

showing 9 of 9 URLs (from 11 scripts), sorted by unused bytes
URLTotalUsedUnusedUnused %
load.php[scripts:dataValues]3.2 MB1.6 MB1.6 MB
49.0%
169 modules in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
jquery.ui1053o344.6 KB93.0 KB251.5 KB
73.0%
mapboxfcfui310.3 KB129.1 KB181.3 KB
58.4%
oojs-ui-corenwn0a186.8 KB55.7 KB131.1 KB
70.2%
wikibase.view.ControllerViewFactoryfo3f9214.3 KB84.9 KB129.5 KB
60.4%
vue1r4hj156.2 KB31.4 KB124.8 KB
79.9%
ext.campaignEvents.postEditcsvs0136.9 KB50.2 KB86.7 KB
63.3%
oojs-ui-widgets1d6rj92.1 KB37.4 KB54.7 KB
59.4%
jquery16rou137.4 KB85.5 KB51.9 KB
37.8%
ext.wikimediaEvents1in0971.2 KB22.1 KB49.1 KB
68.9%
skins.vector.js1pw2261.7 KB25.8 KB35.9 KB
58.1%
oojs-ui-windows1721q53.4 KB18.4 KB35.1 KB
65.6%
oojs-ui-toolbars11yx957.0 KB33.2 KB23.9 KB
41.8%
wikibase.ui.entityViewInitba5ja42.9 KB20.3 KB22.6 KB
52.6%
ext.uls.interface1qeqr47.6 KB25.7 KB21.9 KB
46.0%
ext.centralNotice.display1jgtq30.5 KB9.1 KB21.4 KB
70.2%
mediawiki.apiz5im027.1 KB6.4 KB20.6 KB
76.2%
jquery.ulss9tv124.8 KB6.1 KB18.6 KB
75.3%
jquery.valueview.ExpertExtender176yx23.4 KB7.9 KB15.5 KB
66.2%
jquery.ui.suggestertmbty16.3 KB2.2 KB14.0 KB
86.2%
wikibase.entityChangers.EntityChangersFactorypvc1w14.8 KB1.8 KB13.0 KB
87.9%
ext.testKitcheneiy2929.2 KB16.8 KB12.3 KB
42.2%
wikibase.datamodel16sdh28.7 KB16.8 KB11.9 KB
41.4%
oojs1797x15.0 KB4.6 KB10.3 KB
69.1%
jquery.i18n324o533.6 KB24.0 KB9.6 KB
28.5%
mediawiki.util15zox16.4 KB6.9 KB9.5 KB
58.1%
ext.kartographer.lib.topojson19qrz9.9 KB529 B9.4 KB
94.8%
ext.navigationTiming18ja510.8 KB1.4 KB9.3 KB
86.6%
mediawiki.page.ready1gv6n16.8 KB7.6 KB9.2 KB
54.9%
jquery.wikibase.entityselectordxkyd12.1 KB3.2 KB8.9 KB
73.5%
jquery.valueview165qm11.6 KB2.8 KB8.8 KB
76.2%
wikibase.quality.constraints.gadgetkjt5j29.0 KB20.3 KB8.7 KB
30.1%
wikibase.api.RepoApimh5fd10.9 KB2.7 KB8.2 KB
75.0%
jquery.wikibase.wbtooltip1bniz10.2 KB2.2 KB8.0 KB
78.7%
mediawiki.jqueryMsgi77gl29.8 KB21.9 KB7.9 KB
26.5%
mmv.bootstrap1wfvb26.9 KB19.3 KB7.6 KB
28.3%
ext.kartographer.boxeh1d118.2 KB11.1 KB7.1 KB
39.1%
dataValues.values1og1q14.2 KB7.6 KB6.7 KB
46.9%
mediawiki.page.watch.ajax1ju3r8.9 KB2.5 KB6.3 KB
71.6%
ext.centralNotice.kvStore1ggbc6.8 KB1.1 KB5.7 KB
83.6%
jquery.valueview.experts.QuantityInput1470e8.1 KB2.5 KB5.7 KB
69.6%
ext.eventLogging.metricsPlatformadrwj14.6 KB9.0 KB5.6 KB
38.5%
jquery.textSelection16q5k5.8 KB287 B5.6 KB
95.2%
mediawiki.language11hcb8.7 KB3.2 KB5.4 KB
62.8%
wikibase.serialization1caej21.6 KB16.5 KB5.1 KB
23.7%
jquery.inputautoexpand1jumw4.9 KB647 B4.2 KB
87.0%
mediawiki.Title11zzw10.2 KB6.1 KB4.1 KB
40.1%
skins.vector.clientPreferences7se0x13.7 KB9.6 KB4.1 KB
29.6%
ext.wikimediaEvents.testKitchen165zf4.6 KB785 B3.9 KB
83.4%
ext.centralauth.ForeignApi1myki4.6 KB776 B3.8 KB
83.5%
propertySuggester.suggestionsfymow4.8 KB1.1 KB3.8 KB
77.6%
ext.uls.compactlinks108cu31.1 KB27.5 KB3.7 KB
11.8%
wikibase.quality.constraints.suggestions1ig8d4.6 KB978 B3.7 KB
79.4%
mediawiki.basea5d6126.3 KB22.9 KB3.4 KB
12.9%
ext.eventLogging1hv3q28.2 KB24.8 KB3.4 KB
12.0%
jquery.makeCollapsibleo4kyt9.2 KB6.3 KB2.9 KB
31.3%
jquery.uls.data15mhg43.2 KB40.3 KB2.9 KB
6.6%
jquery.valueview.experts.GlobeCoordinateInput1il0x4.3 KB1.5 KB2.8 KB
65.2%
ext.urlShortener.toolbar1dk5r3.8 KB1.1 KB2.7 KB
70.9%
jquery.valueview.experts.TimeInput1cvtv4.2 KB1.5 KB2.7 KB
64.0%
ext.wikimediaEvents.wikibase13rz83.2 KB555 B2.6 KB
82.9%
mediawiki.user1lcpm4.2 KB1.7 KB2.5 KB
58.8%
ext.checkUser.clientHints7tpv03.0 KB635 B2.4 KB
79.3%
dataValues.TimeValue1ozuq3.3 KB1.0 KB2.3 KB
69.2%
ext.centralNotice.impressionDiet2jcqc2.7 KB446 B2.3 KB
83.9%
ext.kartographer.datawqqvr5.1 KB2.9 KB2.2 KB
43.6%
jquery.valueview.experts.MonolingualText17vtx3.2 KB1.2 KB2.0 KB
63.9%
jquery.animateWithEvent19xfs5.2 KB3.3 KB2.0 KB
37.7%
jquery.ui.commonssuggester6f0do2.9 KB967 B2.0 KB
67.6%
jquery.valueview.experts.StringValue1nyin2.4 KB450 B1.9 KB
81.4%
mediawiki.String1xixe2.4 KB543 B1.9 KB
78.0%
jquery.valueview.Expert193sm2.7 KB924 B1.8 KB
66.1%
wikibase.api.ValueCaller16kg52.4 KB696 B1.8 KB
72.0%
jquery.ui.languagesuggesterx1gx82.0 KB348 B1.7 KB
83.0%
mediawiki.routerx9r1o2.4 KB907 B1.5 KB
63.4%
util.highlightSubstring1l81f1.7 KB190 B1.5 KB
88.9%
jquery.valueview.ExpertStore1r2ca3.2 KB1.7 KB1.5 KB
46.6%
jquery.client1n4yo3.3 KB1.9 KB1.5 KB
43.8%
ext.uls.commonz8as45.4 KB4.0 KB1.4 KB
26.2%
ext.uls.webfonts198622.0 KB663 B1.4 KB
67.8%
jquery.event.special.eachchangezg0vc2.2 KB909 B1.4 KB
60.4%
mediawiki.ForeignApi.corepb72f2.2 KB863 B1.3 KB
61.1%
mediawiki.libs.pluralruleparser1utt83.6 KB2.3 KB1.3 KB
35.5%
ext.centralNotice.startUp1ipzh2.7 KB1.5 KB1.2 KB
45.1%
wikibase.experts.Entity1slsw1.4 KB355 B1.1 KB
75.5%
mediawiki.visibleTimeoutehbob1.5 KB434 B1.1 KB
71.5%
mediawiki.cookie36uhl3.2 KB2.3 KB892 B
27.5%
mediawiki.storagednxpi2.9 KB2.1 KB890 B
29.6%
ext.kartographer.framekiak22.5 KB1.7 KB790 B
30.9%
wikibase.Site8zw24985 B203 B782 B
79.4%
ext.centralNotice.geoIP1g16w1.5 KB850 B698 B
45.1%
wikibase.templates1vf6t13.4 KB12.7 KB656 B
4.8%
util.Notifier1fivo845 B211 B634 B
75.0%
wikibase.sitesahhat859 B246 B613 B
71.4%
jquery.spinnerm5xio827 B234 B593 B
71.7%
util.MessageProviders1xrdd1.3 KB747 B583 B
43.8%
valueParsers.ValueParserStorez7y3x1.7 KB1.2 KB557 B
31.7%
wikibase.utilities.ClaimGuidGeneratorhlrfl1.3 KB838 B516 B
38.1%
wikibase.WikibaseContentLanguages7avpz14.8 KB14.3 KB474 B
3.1%
ext.uls.preferences17lrh1.1 KB645 B445 B
40.8%
jquery.valueview.experts.TabularData1em9i744 B322 B422 B
56.7%
jquery.valueview.experts.GeoShape1vc4y728 B310 B418 B
57.4%
jquery.valueview.experts.CommonsMediaType1fls6744 B342 B402 B
54.0%
wikibase.EntityInitializer1eqcc2.0 KB1.7 KB395 B
18.9%
ext.citoid.wikibase.inita7d0a744 B407 B337 B
45.3%
ext.centralauth.centralautologinh0k411.3 KB962 B325 B
25.3%
wikibase.formatters.ApiValueFormatter1b9oi978 B654 B324 B
33.1%
wikibase.getLanguageNameByCodewa0k821.3 KB21.0 KB269 B
1.2%
wikibase.buildErrorOutput10dj8435 B170 B265 B
60.9%
dataValues1mjgq804 B540 B264 B
32.8%
valueParsers.parsers1gjgl722 B485 B237 B
32.8%
wikibase.wikiprojects.tracking10sfv763 B542 B221 B
29.0%
util.Extendable665wq481 B262 B219 B
45.5%
ext.uls.i18n16evk560 B366 B194 B
34.6%
jquery.valueview.experts.EmptyValueo0zdw639 B460 B179 B
28.0%
wikibase.experts.Sensesilys467 B293 B174 B
37.3%
jquery.valueview.experts.UnDeserializableValue2zsiq592 B421 B171 B
28.9%
wikibase.entityPage.entityLoaded1p2xj1.0 KB875 B168 B
16.1%
dataValues.DataValue1act7525 B400 B125 B
23.8%
ext.echo.centralauth19vyg340 B220 B120 B
35.3%
util.inherit6f6z21.1 KB1.0 KB96 B
8.3%
wikibase.databox.fromWikidatalwf59709 B640 B69 B
9.7%
ext.EntitySchema.experts.EntitySchema1qkyp373 B315 B58 B
15.5%
wikibase.experts.Form1xfpk348 B290 B58 B
16.7%
wikibase.experts.Itemqmyio372 B314 B58 B
15.6%
wikibase.experts.Lexeme1y38w348 B290 B58 B
16.7%
wikibase.experts.Propertyfdz4j388 B330 B58 B
14.9%
ext.uls.mediawiki19g5h409 B354 B55 B
13.4%
util.MessageProviderij0f8297 B265 B32 B
10.8%
valueFormatters7ucu2323 B294 B29 B
9.0%
mediawiki.experiments1jfeg780 B756 B24 B
3.1%
jquery.util.getDirectionality1g7bq275 B264 B11 B
4.0%
ext.kartographer.utilgl5qq255 B247 B8 B
3.1%
mediawiki.cldr13x6e350 B342 B8 B
2.3%
ext.centralNotice.choiceData1hcs61.7 KB1.7 KB4 B
0.2%
util.ContentLanguagesreqx9291 B287 B4 B
1.4%
wikibase.fallbackchains2wgmv22.4 KB22.4 KB4 B
0.0%
oojs-ui6ckcr59 B59 B0 b
0.0%
site4jtht1.1 KB1.1 KB0 b
0.0%
valueParsers8e1y8136 B136 B0 b
0.0%
wikibaseftdcd146 B146 B0 b
0.0%
ext.kartographer1h6se471 B471 B0 b
0.0%
ext.kartographer.site1rxn973 B73 B0 b
0.0%
ext.kartographer.site-loader1pfm980 B80 B0 b
0.0%
ext.uls.languagenames93w0c11.0 KB11.0 KB0 b
0.0%
ext.uls.messages1t2l58.1 KB8.1 KB0 b
0.0%
jquery.spinner.stylesii5wt2.2 KB2.2 KB0 b
0.0%
jquery.uls.gridwogvi2.7 KB2.7 KB0 b
0.0%
mediawiki.ForeignApirqcii72 B72 B0 b
0.0%
mediawiki.pulsatingdot10nnx694 B694 B0 b
0.0%
mediawiki.editfont.styles1pbic1003 B1003 B0 b
0.0%
mmv.codexf380r70.8 KB70.8 KB0 b
0.0%
mw.config.values.wbDataTypes1tj6b970 B970 B0 b
0.0%
mw.config.values.wbEnableMulLanguageCode17dop172 B172 B0 b
0.0%
mw.config.values.wbRefTabsEnabled1o968159 B159 B0 b
0.0%
mw.config.values.wbRepo18lj4211 B211 B0 b
0.0%
mw.config.values.wbSiteDetails1yqun183.6 KB183.6 KB0 b
0.0%
oojs-ui-core.iconsxli3i13.3 KB13.3 KB0 b
0.0%
oojs-ui-core.stylesmddn781.4 KB81.4 KB0 b
0.0%
oojs-ui-toolbars.icons3rsm42.1 KB2.1 KB0 b
0.0%
oojs-ui-widgets.icons9h6o76.3 KB6.3 KB0 b
0.0%
oojs-ui-windows.icons1xjsx1.2 KB1.2 KB0 b
0.0%
oojs-ui.styles.icons-media10eh437.6 KB37.6 KB0 b
0.0%
oojs-ui.styles.indicators16qqm3.1 KB3.1 KB0 b
0.0%
skins.vector.icons.js1d9fa13.2 KB13.2 KB0 b
0.0%
wikibase.getUserLanguageso7i2c5.2 KB5.2 KB0 b
0.0%
wikibase.experts.__namespace1cluh150 B150 B0 b
0.0%
wikibase.experts.modulesyf15k1.0 KB1.0 KB0 b
0.0%
wikibase.view.ReadModeViewFactory1ra9i461 B461 B0 b
0.0%
wikibase.view.__namespace1unrp169 B169 B0 b
0.0%
load.php[scripts:wikibase.tainted-ref]115.2 KB65.3 KB49.8 KB
43.3%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
wikibase.tainted-refbpzt1115.2 KB65.3 KB49.8 KB
43.3%
load.php[scripts:ext.visualEditor.core.utils.parsing]61.8 KB14.4 KB47.4 KB
76.7%
8 modules in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
ext.visualEditor.desktopArticleTarget.init3dxy231.3 KB8.9 KB22.4 KB
71.6%
ext.visualEditor.targetLoaderde2wa23.0 KB2.3 KB20.7 KB
89.8%
ext.visualEditor.core.utils.parsingipi2f3.3 KB800 B2.5 KB
76.5%
ext.visualEditor.tempWikitextEditorWidgetthrfd1.5 KB770 B790 B
50.6%
ext.visualEditor.progressBarWidgetjvj711.3 KB726 B627 B
46.3%
ext.visualEditor.vepoyn0303 B124 B179 B
59.1%
ext.visualEditor.supportCheck1ll9l721 B611 B110 B
15.3%
ext.visualEditor.track14ulv295 B192 B103 B
34.9%
load.php[startup]69.6 KB63.6 KB6.0 KB
8.6%
load.php[scripts:wikibase.lexeme]6.0 KB1.9 KB4.1 KB
68.4%
3 modules in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
wikibase.lexeme.getDeserializer1qf2g3.4 KB1.0 KB2.3 KB
69.1%
wikibase.lexeme.datamodeln64r62.5 KB727 B1.7 KB
71.1%
wikibase.lexeme7x6z5135 B135 B0 b
0.0%
load.php[scripts:ext.gadget.AuthorityControl]13.1 KB10.9 KB2.2 KB
16.8%
5 modules in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
ext.gadget.AuthorityControlbcdf47.1 KB5.8 KB1.4 KB
19.1%
ext.gadget.SiteIdToInterwiki1y3xp1.5 KB804 B743 B
48.0%
ext.gadget.ProtectionIndicators1ky2e3.1 KB3.0 KB62 B
2.0%
ext.gadget.formWizard1t6qd282 B235 B47 B
16.7%
ext.gadget.imagelinks1ois21.1 KB1.1 KB0 b
0.0%
(inline) 3 scripts7.8 KB7.6 KB188 B
2.4%
https://www.wikidata.org/wiki/Special:CentralAutoLogin/start?useformat=desktop&type=script&usesul3=1254 B155 B99 B
39.0%
load.php[scripts:oojs-ui.styles.icons-alerts]28.7 KB28.7 KB43 B
0.1%
3 modules in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
wikibase.quality.constraints.ui1np7g5.4 KB5.3 KB43 B
0.8%
oojs-ui.styles.icons-alertsd21al21.3 KB21.3 KB0 b
0.0%
wikibase.quality.constraints.iconuyzgm2.1 KB2.1 KB0 b
0.0%

CSS files

showing 3 of 3 URLs (from 7 stylesheets), sorted by unused bytes
URLTotalUsedUnusedUnused %
(inline stylesheet) 5 stylesheets588.7 KB43.0 KB545.7 KB
92.7%
load.php[styles:ext.kartographer.style]259.6 KB57.3 KB202.4 KB
77.9%
load.php[styles:site.styles]4.5 KB565 B4.0 KB
87.9%

What to do about unused bytes

one iteration is a sample, not a verdict

A high unused-% on one run means this iteration loaded code that didn't get exercised, typical on first-load journeys before any user interaction. Drive the real flow by passing a navigation script as the input instead of a plain URL, with clicks and form fills placed between measure.start() and measure.stop(); anything in that window counts toward "used". The advice below is for code that's still unused after a representative run.

JavaScript

  • Route-split and lazy-load below-the-fold features with dynamic import(). Bundlers turn the import boundary into a separate chunk.
  • Audit big bundles for dead exports, legacy polyfills, and feature flags that no longer ship; most modern bundlers tree-shake but only when imports are precise.
  • Question third-party scripts. Tag managers, analytics SDKs and A/B test loaders often ship far more than the page uses and dominate the third-party column above.
  • Move non-critical scripts to defer or async so the parser doesn't block on code the page doesn't need yet.

CSS

  • Strip selectors no shipped HTML matches: PurgeCSS, build-time scoping in your component framework, or your CSS-in-JS extractor.
  • Drop legacy browser fallbacks if your target floor has moved (vendor prefixes, IE hacks, old flexbox syntax).
  • Split route- or component-specific CSS so the home page doesn't carry the checkout's styles.
  • Inline the critical-path CSS (above-the-fold) and lazy-load the rest with media= tricks or rel="preload" swaps.

CPU

load.php[scripts:dataValues] is responsible for 90% of blocking time
3709 ms of 4133 ms total. Defer it, replace it with a lighter alternative, or move its work off the main thread to recover most of your TBT.

Long tasks

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

TBT4.022 s
Max potential input delay2.955 s
Total long tasks11
Total time5.000 s
Last task at8.250 s
Before first paint478 ms1 task
Before FCP478 ms1 task
Before LCP4.425 s9 tasks
After load4.522 s10 tasks

Long Animation Frames

A long animation frame (LOAF) is a frame that took ≥ 50 ms from input to the next paint. The part beyond the threshold is blocking time, the number that hurts Interaction to Next Paint and Total Blocking Time. Break long tasks up (scheduler.yield(), smaller chunks) or move the work off the main thread. Read more about the Long Animation Frames API.

Long animation frames11showing the 10 with the most blocking time
Blocking time4.579 sacross all long frames — what hurts INP and TBT
Forced style & layout1.052 sscripts reading layout mid-frame
Blocking before LCP4.075 sdelaying the largest paint — fix these first
Blocking after load4.183 safter the load event — didn't delay page load
Input waiting1 framea real interaction was delayed (INP)

What to fix first

ScriptFramesTime runningBlocking (share by run time)Forced style & layoutTriggered by
load.php[scripts:dataValues]53.823 s3.709 s797.6 mstimer or animation callback, event handler
load.php[startup]4509 ms423.8 ms254.9 mstimer or animation callback

A frame's blocking time is split between its scripts by their share of the frame's work, capped at each script's own run time — blocking from work no script owns (HTML parsing, browser internals) stays unattributed. The per-script blocking view below uses the same attribution.

Long animation frame #1 · 2.994 sat 3.427 s · before LCP
input was waitingblocking 2.932 s
  • Scripts & other work2.968 s
  • Animation callbacks25.7 ms
  • Style & layout0.1 ms
  • Render0 ms
1 script ran during this frame · forced style & layout 649.3 ms
Ran for
2.956 s
Forced style and layout
649.3 ms
Started by
TimerHandler:setTimeout
How it started
timer or animation callback
Position in source
character 46103 into the file (locate it via DevTools → Performance → the Long Animation Frames track)
Long animation frame #2 · 554.7 msat 7.742 s · after load
blocking 504.2 ms
  • Scripts & other work508 ms
  • Animation callbacks31.7 ms
  • Style & layout15 ms
  • Render0 ms
1 script ran during this frame · forced style & layout 61.3 ms
Ran for
507.5 ms
Forced style and layout
61.3 ms
Started by
TimerHandler:setTimeout
How it started
timer or animation callback
Position in source
character 46103 into the file (locate it via DevTools → Performance → the Long Animation Frames track)
Long animation frame #3 · 790.3 msat 415.5 ms · before LCP
blocking 396.5 ms
  • Scripts & other work790 ms
  • Animation callbacks0.2 ms
  • Style & layout0.1 ms
  • Render0 ms

The browser did not report which script was responsible for this frame — typically its own style/layout work, or a cross-origin script it will not name.

Long animation frame #4 · 369 msat 2.160 s · before LCP
blocking 315.5 ms
  • Scripts & other work58.6 ms
  • Animation callbacks301.8 ms
  • Style & layout8.6 ms
  • Render0 ms
2 scripts ran during this frame · forced style & layout 254.9 ms
Ran for
55.1 ms
Started by
IdleRequestCallback
How it started
timer or animation callback
Source function
doPropagation
Position in source
character 4301 into the file (locate it via DevTools → Performance → the Long Animation Frames track)
Ran for
301.7 ms
Forced style and layout
254.9 ms
Started by
FrameRequestCallback
How it started
timer or animation callback
Source function
flushCssBuffer
Position in source
character 3227 into the file (locate it via DevTools → Performance → the Long Animation Frames track)
Long animation frame #5 · 250.4 msat 2.548 s · before LCP
blocking 160.7 ms
  • Scripts & other work55.5 ms
  • Animation callbacks190.9 ms
  • Style & layout4 ms
  • Render0 ms
5 scripts ran during this frame · forced style & layout 87 ms
Ran for
15.9 ms
Started by
IdleRequestCallback
How it started
timer or animation callback
Source function
doPropagation
Position in source
character 4301 into the file (locate it via DevTools → Performance → the Long Animation Frames track)
Ran for
5.9 ms
Forced style and layout
2.3 ms
Started by
TimerHandler:setTimeout
How it started
timer or animation callback
Position in source
character 46103 into the file (locate it via DevTools → Performance → the Long Animation Frames track)
Ran for
14 ms
Started by
TimerHandler:setTimeout
How it started
timer or animation callback
Position in source
character 46103 into the file (locate it via DevTools → Performance → the Long Animation Frames track)
Ran for
26.8 ms
Started by
FrameRequestCallback
How it started
timer or animation callback
Source function
flushCssBuffer
Position in source
character 3227 into the file (locate it via DevTools → Performance → the Long Animation Frames track)
Ran for
156.5 ms
Forced style and layout
84.7 ms
Started by
FrameRequestCallback
How it started
timer or animation callback
Position in source
character 1434851 into the file (locate it via DevTools → Performance → the Long Animation Frames track)
Long animation frame #6 · 207.5 msat 6.450 s · before LCP
blocking 157.1 ms
  • Scripts & other work170.4 ms
  • Animation callbacks0 ms
  • Style & layout37.1 ms
  • Render0 ms
1 script ran during this frame
Ran for
169.9 ms
Started by
TimerHandler:setTimeout
How it started
timer or animation callback
Position in source
character 46103 into the file (locate it via DevTools → Performance → the Long Animation Frames track)
Long animation frame #7 · 127.1 msat 3.111 s · before LCP
blocking 75.4 ms
  • Scripts & other work99.6 ms
  • Animation callbacks21.9 ms
  • Style & layout5.6 ms
  • Render0 ms
1 script ran during this frame
Ran for
97.8 ms
Started by
IdleRequestCallback
How it started
timer or animation callback
Source function
doPropagation
Position in source
character 4301 into the file (locate it via DevTools → Performance → the Long Animation Frames track)
Long animation frame #8 · 171.6 msat 2.929 s · before LCP
blocking 25.3 ms
  • Scripts & other work99.4 ms
  • Animation callbacks11.8 ms
  • Style & layout60.4 ms
  • Render0 ms
1 script ran during this frame
Ran for
11.7 ms
Started by
FrameRequestCallback
How it started
timer or animation callback
Source function
flushCssBuffer
Position in source
character 3227 into the file (locate it via DevTools → Performance → the Long Animation Frames track)
Long animation frame #9 · 65.6 msat 2.859 s · before LCP
blocking 13 ms
  • Scripts & other work4.2 ms
  • Animation callbacks7.5 ms
  • Style & layout53.9 ms
  • Render0 ms

The browser did not report which script was responsible for this frame — typically its own style/layout work, or a cross-origin script it will not name.

1 more long frame carried no blocking time (nothing ran past the 50 ms threshold) — long, but harmless to INP and TBT.

Blocking time per script (browser-reported)

How much each script blocked the main thread, derived from the Long Animation Frame API. Each frame's blocking time is split between its scripts by their share of the frame's work, capped at each script's own run time — blocking from work no script owns (HTML parsing, browser internals) is not attributed (older data credits the script that started the frame). The closest answer to "which script should I fix to improve TBT" the platform exposes.

Top scripts blocking the main thread

2 of 2 scripts
load.php[scripts:dataValues]
3709 ms · 6 frames · worst 2919 ms
load.php[startup]
424 ms · 6 frames · worst 267 ms

Blocking time per script (trace)

Total Blocking Time attributed per script from the Chrome trace: every main-thread task longer than 50 ms blocks input for the remainder, and each blocking task is credited to the script whose own code ran the longest during that task.

TBTNaN s
Blocking tasks8
TBT before LCP429 ms1 task

What kind of work blocked

mostly style & layout · 794 ms total
Style & layout727.1 ms91.6%
Paint & composite61.5 ms7.7%
Parsing HTML & CSS5.5 ms0.7%
Style & layout (92%): usually a large DOM, expensive CSS selectors or JavaScript forcing synchronous layout. See Forced reflows · Forced layout per script · Slowest CSS selectors (Rendering tab) · Style invalidations (Rendering tab)

Top scripts blocking the main thread

2 of 2 scripts
Browser's own work (no script responsible)
473 ms · 2 tasks

Where the time went

All main-thread work during the full page load, not just the share that blocked input. Calculated from the Chrome trace.

Categories

1.715 s total
Style & layout980 ms57.1%
Running JavaScript328 ms19.1%
Paint & composite129 ms7.5%
Other browser work (scheduling)127 ms7.4%
Parsing HTML & CSS123 ms7.2%
Garbage collection20 ms1.2%
Parsing & compiling JavaScript8 ms0.5%
What do these categories mean?
Parsing HTML & CSSparseHTML
Reading the HTML and CSS and building the page structure. Grows with document size — a big server-rendered page costs more here.
Style & layoutstyleLayout
Working out which CSS rules apply and where every element goes on the page. Grows with DOM size and selector complexity.
Parsing & compiling JavaScriptscriptParseCompile
Parsing and compiling JavaScript before it can run — the cost of shipping bytes of JS, even unused ones.
Running JavaScriptscriptEvaluation
Running JavaScript: event handlers, timers, promise callbacks and script execution.
Paint & compositepaintCompositeRender
Painting pixels and assembling layers into the frames you see on screen.
Garbage collectiongarbageCollection
Reclaiming memory JavaScript no longer uses. A lot of it means allocation-heavy code.
Other browser work (scheduling)other
Chrome’s own task management: per-task overhead and thousands of sub-millisecond scheduler ticks — not page work you can attribute or optimize away. On this page 125 ms of it is this per-task bookkeeping (RunTask self time in the trace).

CPU time per script

Scripts by main-thread time

2 of 2 scripts

CPU time per moduleProfile run

Main-thread CPU time attributed to the individual modules inside concatenated JavaScript bundles (MediaWiki ResourceLoader), so a heavy bundle can be traced to the modules that actually cost the time.

The data comes from the extra profile run, not from the timed iterations.

load.php[scripts:dataValues]

434 ms across 6 modules
ModuleVersionSelf time
ext.kartographer.framekiak258.3 ms
jquery16rou56.7 ms
mediawiki.storagednxpi0.7 ms
ext.kartographer.boxeh1d10.3 ms
skins.vector.js1pw220.2 ms
ext.testKitcheneiy290.1 ms
(rest of the bundle, not tied to one module)317.8 ms
ModuleVersionSelf time
ext.visualEditor.supportCheck1ll9l0.1 ms
(rest of the bundle, not tied to one module)1.4 ms

Slowest JS functions

The functions where main-thread JavaScript time was actually spent, sampled by Chrome's JavaScript profiler. Self time is spent in the function itself; total time includes the functions it called. For loader/dispatcher functions whose total dwarfs their self time, the runs line shows the top functions and modules (up to five, ≥ 1 ms) the total was actually spent running.

Functions by self time

15 of 50 functions
FunctionWhereSelf timeTotal time
computeStyleTestsload.php[scripts:dataValues]258.2 ms258.7 ms
getStyleload.php[scripts:dataValues]48.8 ms48.8 ms
initialize
runs: load.php[scripts:dataValues] (96.0 ms)
load.php[scripts:dataValues]29.6 ms130.2 ms
runScript
runs: load.php[scripts:dataValues] (290.1 ms), load.php[scripts:ext.gadget.AuthorityControl] (30.0 ms)
load.php[startup]23.7 ms424.1 ms
querySelectorAllBrowser internal (not your code)20.7 ms20.7 ms
jQuery.expr.pseudos.visibleload.php[scripts:dataValues]20.7 ms20.7 ms
setTimeoutBrowser internal (not your code)15.0 ms15.0 ms
insertBeforeBrowser internal (not your code)12.7 ms12.7 ms
require
runs: load.php[scripts:dataValues] (14.8 ms)
load.php[startup]12.0 ms31.7 ms
find
runs: load.php[scripts:dataValues] (25.4 ms), querySelectorAll (18.5 ms), getElementsByClassName (1.0 ms)
load.php[scripts:dataValues]10.8 ms54.7 ms
emptyload.php[scripts:dataValues]9.6 ms9.6 ms
implload.php[startup]8.1 ms10.3 ms
addClassload.php[scripts:dataValues]7.9 ms7.9 ms
getSizeload.php[scripts:dataValues]5.9 ms5.9 ms
(anonymous)load.php[scripts:dataValues]5.7 ms5.7 ms

TimersProfile run

How much setTimeout/setInterval work the page runs, credited to the script that scheduled each timer. Many zero-delay timers mean work sliced into a machine-gun of tiny tasks; repeating timers are polling.

Timers set79
Times fired70
Fire time56.8 ms
Zero-delay timers75
Repeating timers0
Zero-delay slicing: jquery split work into 74 back-to-back tasks costing 55 ms. Consider batching the work or moving it to requestIdleCallback or a worker.

Timer cost by script

2 scripts
load.php[scripts:dataValues]
39 ms · set 78 times · fired 55 times
load.php[startup]
18 ms · set 1 time · fired 15 times

The timers, by where they were set

top 5 by fire time
Set byDelayTypeTimes setTimes firedFire time
jquery0 msonce746655.3 ms
SafeStorage in mediawiki.storage2000 msonce220.8 ms
jquery0 msonce110.6 ms
requestUpdate in load.php[startup]:222000 msonce110.1 ms
ajax in jquery30000 msonce100.0 ms

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

5 reflows ≥ 2 ms across 2 scripts
load.php[startup]
252 ms · 2 reflows · worst 243 ms
load.php[scripts:dataValues]
49 ms · 3 reflows · worst 42 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

2 of 2 scripts
load.php[scripts:dataValues]
798 ms · across 4 frames
load.php[startup]
255 ms · across 1 frame

First vs third party CPU time

Main-thread CPU time from the Chrome trace split by domain. First party is wikidata.org.

First party674 ms
Third party0 ms
Domains1

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

1 property · 303 animations
  • top303×

Want to dig deeper? Download the Chrome trace and drag-and-drop it into Performance in DevTools.