Page summary

https://en.wikipedia.org/wiki/Barack_Obama

Tested 2026-09-20 14:10:11 using Chrome 152.0.7977.64 (script).(runtime settings)

Test visiting multiple pages

First hit the Main_Page with an empty browser cache and then visit Obama

SummaryWaterfallMetricsRenderingCoachPageXrayCPU

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

85 / 100
Coach overall
90 / 100
Performance
79 / 100
Best practice
80 / 100
Privacy

How it loaded →

0 → 1.733 s · median run
Frame at 0 ms
start
Frame at 1100 ms
Largest paint1.100 s
Frame at 1200 ms
1.200 s
Frame at 1400 ms
1.400 s
Frame at 1500 ms
1.500 s
Frame at 1700 ms
Complete1.700 s
1.033 s
First Visual Change
1.134 s
Speed Index
1.333 s
Visual Complete 85%
1.733 s
Last Visual Change
TTFB109 msLCP1.044 sTBT82 msCLS0.03

What to act on · top recommendations

Serve images in modern formats (AVIF, WebP)

0 / 100

The page ships 62 images (out of 62) 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.

Avoid extra requests by setting cache headers

0 / 100

The page has 12 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 90.7 kB the next access.

Avoid CPU Long Tasks

40 / 100

The page has 3 CPU long tasks with the total of 234 ms. The total blocking time is 84 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.

Google Web Vitals

min · median · mean · max of 5 runs
MetricMinMedianMeanMaxRuns agree?
Time To First Byte (TTFB)108 ms109 ms109 ms111 msstable ±1%
Largest Contentful Paint (LCP)1.020 s1.044 s1.038 s1.056 sstable ±2%
Cumulative Layout Shift (CLS)0.03120.03180.03170.0318stable ±1%

Visual Metrics

min · median · mean · max of 5 runs
MetricMinMedianMeanMaxRuns agree?
First visual change1.000 s1.033 s1.026 s1.033 sstable ±2%
Last visual change1.700 s1.733 s1.740 s1.833 sstable ±4%
Speed index1.102 s1.134 s1.128 s1.137 sstable ±2%
Largest image1.633 s1.666 s1.660 s1.667 sstable ±1%
Heading1.633 s1.666 s1.660 s1.667 sstable ±1%
Largest contentful paint1.633 s1.666 s1.660 s1.667 sstable ±1%
Last meaningful paint1.633 s1.666 s1.660 s1.667 sstable ±1%
Visual readiness667 ms700 ms713 ms800 msvaries ±10%
Visual complete 851.200 s1.333 s1.320 s1.366 svaries ±6%
Visual complete 951.666 s1.700 s1.720 s1.833 sstable ±5%
Visual complete 991.666 s1.700 s1.720 s1.833 sstable ±5%

CPU

min · median · mean · max of 5 runs
MetricMinMedianMeanMaxRuns agree?
Total Blocking Time63 ms82 ms78 ms86 msruns disagree ±14%
Max Potential FID94 ms96 ms97 ms106 msvaries ±6%
CPU long tasks 2333runs disagree ±17%
CPU last long task happens at1.226 s1.348 s1.333 s1.421 svaries ±7%

More metrics

min · median · mean · max of 5 runs
MetricMinMedianMeanMaxRuns agree?
First paint1.020 s1.044 s1.038 s1.056 sstable ±2%
Load event end1.034 s1.046 s1.048 s1.062 sstable ±1%

User Timing

min · median · mean · max of 5 runs
MetricMinMedianMeanMaxRuns agree?
mwStartup131 ms132 ms132 ms134 msstable ±1%
mwCentralNoticeBanner1.590 s1.594 s1.603 s1.625 sstable ±1%

Waterfall

Run 4 SpeedIndex median

First paintFCPLCPDOMContentLoadedDOM interactiveLoadRender-blockingRedirectError

Rendering

Run 4 · median
0.000 s
0s0.5s1s1.5s

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

9 frames

Use --filmstrip.showAll to show all filmstrips.

Frame at 0 ms
0 ms
0 %
Frame at 200 ms
200 ms
0 %
Frame at 1.100 s
1.100 s
79 %
Frame at 1.200 s
1.200 s
79 %
Frame at 1.300 s
1.300 s
79 %
Frame at 1.400 s
1.400 s
89 %
Frame at 1.500 s
1.500 s
90 %
Frame at 1.600 s
1.600 s
90 %
Frame at 1.700 s
1.700 s
100 %

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

Visual instability

31.74 % 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 shown18
Partial2
Dropped0
Effective FPS24.8
Longest gap199 msat 1.136 s

Why was rendering delayed?

Rendering was not meaningfully delayed. First paint landed at 1.028 s on a 109 ms first byte; the 1 render-blocking request was done by 536 ms and the remaining ~492 ms is style and layout work (204 ms of it measured style recalculation).

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 16 191 elements cost 204 ms before the page painted (19.8 % of the time to First Contentful Paint), and a single recalculation of 16 108 elements accounts for 197 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 (same paint, 1.028 s)

Recalculations16
Elements16191
Total time203.855 ms
Largest recalculation16108 elements · 197.432 ms

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

Render blocking requests

1 request · 27.1 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 gap after the bars is style and layout work.

RequestWhen it loadedTransferDownload
document
en.wikipedia.org · TTFB 109 ms
494 ms
412.5 KB493 ms
ext.cite.parsoid.styles + 16 more modulesblocking
css · load.php styles batch · en.wikipedia.org
419 ms
27.1 KB419 ms
0257 ms514 msFCP · LCP 1.028 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 131 ms. The wasted-work list below (selectors tried thousands of times that never match) is the place to start.

Matching time131 ms
Match attempts2 140 197
Matches96 116

Selectors by matching time

top 25
SelectorTimeAttemptsMatches
[rel~="mw:referencedBy"]::before4.04 ms9 7972 688
body.mw-mmv-lightbox-open > :not(.mw-notification-area-overlay)3.08 ms17 0320
a:where(:not([role="button"])):visited:hover2.77 ms18 1880
a:where(:not([role="button"])):visited2.60 ms18 1887 468
a:where(:not([role="button"])):visited:active2.18 ms18 1880
.mw-parser-output a1.94 ms9 0947 210
a:visited1.92 ms18 1887 479
a:not([href])1.80 ms9 0940
.skin-theme-clientpref-night .ns-100 .mw-parser-output :not(.notheme):not(a)1.79 ms33 0480
.client-js .outercollapse .innercollapse.mw-collapsible:not(.mw-made-collapsible) > :is(p, table, thead + tbody)1.61 ms33 0480

Wasted selector work: attempts that never match

top 25
SelectorAttemptsTime
.client-js .outercollapse .innercollapse.mw-collapsible:not(.mw-made-collapsible) :is(tr:not(:first-child), .mw-collapsible-content)33 0481.06 ms
.client-js .outercollapse .innercollapse.mw-collapsible:not(.mw-made-collapsible) > :is(p, table, thead + tbody)33 0481.61 ms
.cdx-message__content > *33 0481.09 ms
.skin-theme-clientpref-night .ns-100 .mw-parser-output :not(.notheme):not(a)33 0481.79 ms
.cdx-message__content > :first-child33 0481.02 ms
.cdx-message__content > :last-child33 0481.02 ms
a:where(:not([role="button"])):visited:active18 1882.18 ms
.vector-menu-tabs .mw-list-item.new a:visited:hover18 1880.54 ms
.mw-body-content figure[typeof~="mw:File"] > a18 1880.69 ms
a:where(:not([role="button"])):visited:hover18 1882.77 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. 2 471 style recalculations and 3 629 layout invalidations fired after first paint, on a page the user was already looking at. The biggest driver is attribute title (447×). Start with the script under "Scripts causing invalidations" that keeps triggering it.

Style recalculations2 5382 471 after first paint
Layout invalidations31 8643 629 after first paint

Changes that keep invalidating

top 15
  • attribute: title447×
  • attribute: style203×
  • attribute: hidden152×
  • attribute: class108×
  • pseudo: has50×
  • class: mw-made-collapsible35×
  • pseudo: disabled32×
  • pseudo: enabled32×
  • attribute: disabled21×
  • class: mw-collapsed16×
  • attribute: controls
  • class: phase-pre-ready
  • class: state-no-source
  • attribute: id
  • attribute: role

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 changed1 563
Related style rule707
A node was inserted into the page93
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.69
JavaScript changed an inline styleSet a class instead of writing element.style, so the browser can batch the work.14
Attribute21
An @keyframes rule changed4
An element entered layout529
An element left layout2 503
List value change461
An SVG element changed63
A style change forced layout21
Counter style change18
An element's size changed14
Unknown12
Child changed4
Slider value changed4

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 rule19
A node was inserted into the page28
JavaScript changed an inline styleSet a class instead of writing element.style, so the browser can batch the work.19
An element entered layout28 167
An element left layout56
An SVG element changed5
A style change forced layout1
An element's size changed2
Unknown2

Scripts causing invalidations

top 7

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

90
6 warnings3 info
warn(0)Serve images in modern formats (AVIF, WebP)modernImageFormats

The page ships 62 images (out of 62) 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)Avoid extra requests by setting cache headerscacheHeaders

The page has 12 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 90.7 kB the next access.

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

Offenders
warn(40)Avoid CPU Long TaskslongTasks

The page has 3 CPU long tasks with the total of 234 ms. The total blocking time is 84 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
warn(70)Don't scale images in the browseravoidScalingImages

The page has 3 images 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
infoLong cache headers is goodcacheHeadersLong
infoMake each CSS response smalloptimalCssSize

https://en.wikipedia.org/w/load.php?lang=en&modules=ext.cite.parsoid.styles%7Cext.cite.styles%7Cext.phonos.icons%2Cstyles%7Cext.tmh.player.styles%7Cext.uls.interlanguage%7Cext.visualEditor.desktopArticleTarget.noscript%7Cext.wikimediaBadges%7Cext.wikimediaBadges.ulsV2%7Cext.wikimediamessages.styles%7Cjquery.makeCollapsible.styles%7Cmediawiki.skinning.content.parsoid%7Cmediawiki.skins.legacy%7Cskins.vector.icons%2Cstyles%7Cskins.vector.search.codex.styles%7Cwikibase.client.init&only=styles&skin=vector-2022 size is 27.8 kB (27770) 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://en.wikipedia.org/w/load.php...ia.org/w/load.php27.1 KB214.4 KB
warn(90)Don't use private headers on static contentprivateAssets

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

The page has 6 images (out of 67) 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(95)Inline CSS for faster first renderinlineCss

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

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

Best practice advice

79
1 warning4 info
infoMeta descriptionmetaDescription

The page is missing a meta description.

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

infoGive every image a textual alternativeimageAltText

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

infoAvoid unnecessary headersunnecessaryHeaders

There are 13 responses that sets both a max-age and expires header. There are 30 responses that sets a server header.

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

Offenders
infoDo not send too long headerslongHeaders

https://en.wikipedia...wiki/Barack_Obama has a header content-security-policy that is 4541 characters long.

Do not send response headers that are too long.

Offenders

Privacy advice

80
4 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(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.

TitleBarack Obama - WikipediaThe document title, shown in the browser tab and used by search results.
GeneratorMediaWiki 1.47.0-wmf.20The tool or CMS that generated the HTML, from the page generator meta tag.
Layout viewport1904 × 51768 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 elements23,015Very large, slows layout and styleTotal HTML elements. Fewer means less for the browser to style, lay out and paint.
Avg DOM depth19How deeply elements are nested on average.
Max DOM depth34Very deep treeThe deepest nesting on the page. Deep branches cost more style recalculation.
Iframes0No embedded documents on this page.
Script tags5Number 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 storage959.1 KBData 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://en.wikipedia.org/wiki/auth.wikimedia.org
preconnect
  • https://thumb.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 4

Visual Metrics

Visual milestones

all times from navigation start
Speed Index1.13 show quickly the page looked done
First Visual Change1.03 sfirst paint reaches the screen
Last Visual Change1.70 sscreen stops changing · 0.67 s after first
nothing painted yet
≥85%
First Visual Change1.03 s
Visual Complete 85%1.33 s
Visual Complete 95% · Visual Complete 99% · Last Visual Change1.70 s
Visual Readiness0.67 s· first to last change
00.5 s1.0 s1.5 s
Visual progress
Visual progress at 0 s0.0s
Visual progress at 0.2 s0.2s
Visual progress at 1.1 s1.1s
Visual progress at 1.2 s1.2s
Visual progress at 1.4 s1.4s
Visual progress at 1.5 s1.5s
Visual progress at 1.6 s1.6s
Visual progress at 1.7 s1.7s
FCP1.03s
LCP1.03s
VC851.33s
Long tasks
0.0s0.3s0.7s1.0s1.4s1.7s

Google Web Vitals

from run 4

Largest Contentful Paint

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

1.028 sLCP render time

Phase breakdown

  • TTFB109 ms
  • Resource load delay0 ms
  • Resource load duration0 ms
  • Element render delay919 ms

Element

Element type
<p>
Element id
mwHg
Size (w × h)
188163
Load time
0 ms
Style recalculation before LCP
16 recalculations touching 16191 elements (203.855 ms) — the largest touched 16108 elements (197.432 ms)

DOM path

body > div:eq(2) > div > div:eq(2) > main#content > div#bodyContent > div#mw-content-text > div:eq(0) > section#mwAQ > p#mwHg
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.031cumulative layout shift score

One shift is 100% of your 0.031 CLS. div:eq(2) moved at 1.635 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.031
    100% of CLSshifted at 1.635 s
    <div class="mw-content-container">
    body > div:eq(2) > div > div:eq(2)
    <div class="vector-column-start">
    body > div:eq(2) > div > div:eq(1)
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
mwStartup131 ms
mwCentralNoticeBanner1.590 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 ms2384037965

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
LargestImage250px-President_Barack_Obama.jpg?utm_source=en.wikipedia.org&utm_campaign=parser&utm_content=thumbnail
Display time1.666 s
Position (x, y)1145, 396
Size (w × h)250 × 312
HTML snippet
<img resource="https://en.wikipedia.org/wiki/File:President_Barack_Obama.jpg" src="//thumb.wikimedia.org/wikipedia/commons/thumb/8/8d/President_Barack_Obama.jpg/250px-President_Barack_Obama.jpg?utm_source=en.wikipedia.org&amp;utm_campaign=parser&amp;utm_content=thumbnail" decoding="async" loading="lazy" srcset="//thumb.wikimedia.org/wikipedia/commons/thumb/8/8d/President_Barack_Obama.jpg/500px-President_Barack_Obama.jpg?utm_source=en.wikipedia.org&amp;utm_campaign=parser&amp;utm_content=thumbnail 2x" alt="Obama standing in the Oval Office with his arms folded and smiling" data-file-width="2687" data-file-height="3356" data-file-type="bitmap" height="312" width="250" class="mw-file-element mw-file-upright" style="--mw-file-upright: 1">
LargestImage preview
Heading
Display time1.666 s
Position (x, y)478, 174
Size (w × h)796 × 40
HTML snippet
<h1 id="firstHeading" class="firstHeading mw-first-heading"></h1>
LargestContentfulPaint
Display time1.666 s
Position (x, y)478, 500
Size (w × h)948 × 312
HTML snippet
<p id="mwHg"></p>

PageXray

How the page is built.

HTTP versionHTTP/2.0
Total requests30
Total domains4
Transfer size598.3 KB
Content size3.1 MB
Missing compression0
Cookies130 third-party

Main document

status 200 · 0 redirects

https://en.wikipedia.org/wiki/Barack_Obama

HeaderValue
accept-ch
accept-rangesbytes
age3077
cache-controlprivate, s-maxage=0, max-age=0, must-revalidate, no-transform
content-encodinggzip
content-languageen
content-length416514
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 thumb.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 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.wikidata.org www.wikifunctions.org auth.wikimedia.org; style-src 'self' data: blob: upload.wikimedia.org thumb.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 '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
dateSun, 20 Sep 2026 13:21:47 GMT
last-modifiedSun, 20 Sep 2026 13:13:53 GMT
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-5f96df4694-g9bp8
server-timingcache;desc="hit-front", host;desc="cp3070",co_id;desc="2384037965"
strict-transport-securitymax-age=106384710; includeSubDomains; preload
varyAccept-Encoding,X-Subdomain,Cookie,Authorization,User-Agent
x-analytics
x-cachecp3070 miss, cp3070 hit/6
x-cache-statushit-front
x-client-ip138.201.135.103
x-content-type-optionsnosniff
x-request-id0ed98a30-c7ed-4aae-933a-1ca5a851492f

Response codes

200
2996.7%
202
13.3%

Requests and sizes per content type

6 types

Transfer size598.3 KB

  • html68.9%
  • image13.2%
  • javascript9.3%
  • css4.5%
  • svg3.8%
  • plain0.15%

Content size3.1 MB

  • html85.0%
  • css6.8%
  • javascript6.0%
  • image2.0%
  • svg0.24%

Requests30

  • svg56.7%
  • image26.7%
  • javascript6.7%
  • html3.3%
  • css3.3%
  • plain3.3%
ContentHeader SizeTransfer SizeContent SizeRequests
html0 b412.5 KB2.6 MB1
css0 b27.1 KB214.4 KB1
javascript0 b55.9 KB191.0 KB2
image0 b79.1 KB63.6 KB8
svg0 b22.7 KB7.6 KB17
plain0 b905 B0 b1
Total0 b598.3 KB3.1 MB30

Data per domain

4 domains
DomainTotal download timeTransfer SizeContent SizeRequests
en.wikipedia.org2.998 s509.7 KB3.0 MB18
upload.wikimedia.org416 ms8.9 KB3.2 KB4
thumb.wikimedia.org897 ms77.1 KB63.3 KB7
meta.wikimedia.org101 ms2.6 KB5.2 KB1

Expires & last-modified statistics

typeminmedianmax
Expires0 seconds2 weeks1 year
Last modified8 minutes5 weeks10 years

Requests loaded after onLoad event

13 requests

Includes requests done after load event end.

ContentTransfer SizeRequests
html0 b0
css0 b0
javascript2.6 KB1
image20.8 KB1
font0 b0
favicon0 b0
plain905 B1
svg11.6 KB10
Total35.9 KB13

Requests loaded after onContentLoad

13 requests

Includes requests done after DOM content loaded.

ContentTransfer SizeRequests
html0 b0
css0 b0
javascript2.6 KB1
image20.8 KB1
font0 b0
favicon0 b0
plain905 B1
svg11.6 KB10
Total35.9 KB13

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 total1.1 MB
JS unused492.0 KB
JS unused %42.0%
CSS total400.6 KB
CSS unused316.5 KB
CSS unused %79.0%

Where the bytes go

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

1.5 MB of script and style shipped, and 808.5 KB of it never ran on this page. The biggest win is load.php[styles:ext.cite.parsoid.styles]: 214.4 KB delivered, 159.8 KB unused.

load.php[styles:ext.cite.parsoid.styles]214.4 KB · 75% unused
load.php[scripts:ext.cite.ux-enhancements]185.8 KB · 52% unused
inline157.3 KB · 91% unused
load.php[scripts:ext.popups.main]93.6 KB · 29% unused
load.php[scripts:ext.wikimediaEvents]73.4 KB · 71% unused
load.php[startup]68.0 KB · 8% unused
load.php[scripts:skins.vector.js]62.0 KB · 49% unused
load.php[scripts:ext.uls.interface]47.7 KB · 45% unused
load.php[scripts:ext.testKitchen]32.7 KB · 41% unused
load.php[scripts:ext.visualEditor.desktopArticleTarget.init]32.2 KB · 67% unused
load.php[scripts:ext.centralNotice.choiceData]31.1 KB · 0% unused
load.php[scripts:ext.centralNotice.display]30.8 KB · 37% unused
load.php[scripts:mediawiki.jqueryMsg]30.1 KB · 32% unused
inline29.7 KB · 1% unused
load.php[scripts:mmv.bootstrap]28.7 KB · 24% unused
load.php[scripts:mediawiki.base]28.7 KB · 13% unused
load.php[scripts:ext.eventLogging]28.3 KB · 12% unused
load.php[scripts:ext.cite.referencePreviews]28.0 KB · 24% unused
load.php[scripts:mediawiki.api]27.4 KB · 80% unused
load.php[scripts:ext.visualEditor.targetLoader]23.3 KB · 88% unused
load.php[scripts:ext.gadget.ReferenceTooltips]21.7 KB · 66% unused
load.php[scripts:mediawiki.page.ready]17.1 KB · 55% unused
load.php[scripts:mediawiki.util]16.7 KB · 57% unused
load.php[scripts:oojs]15.2 KB · 75% unused
load.php[scripts:ext.eventLogging.metricsPlatform]14.9 KB · 38% unused
load.php[scripts:oojs-ui.styles.icons-editing-core]14.4 KB · 0% unused
load.php[scripts:skins.vector.clientPreferences]14.0 KB · 29% unused
load.php[scripts:skins.vector.icons.js]13.5 KB · 0% unused
load.php[scripts:ext.navigationTiming]11.0 KB · 84% unused
load.php[scripts:mediawiki.Title]10.5 KB · 39% unused
load.php[scripts:mediawiki.page.watch.ajax]9.9 KB · 70% unused
load.php[scripts:mediawiki.language]9.0 KB · 61% unused
load.php[scripts:ext.centralNotice.kvStore]7.1 KB · 56% unused
load.php[scripts:ext.wikimediaEvents.testKitchen]6.4 KB · 72% unused
load.php[scripts:jquery.textSelection]6.1 KB · 91% unused
load.php[scripts:ext.centralauth.ForeignApi]5.0 KB · 78% unused
67 more files126.2 KB · 43% 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 (.*wikipedia.*||.*wikimedia.*)
JS unused
First 492.0 KBThird 0 b
CSS unused
First 316.5 KBThird 0 b

JavaScript files

showing 25 of 78 URLs (from 80 scripts), sorted by unused bytes
URLTotalUsedUnusedUnused %
load.php[scripts:ext.cite.ux-enhancements]185.8 KB88.8 KB97.1 KB
52.2%
15 modules in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
jquery16rou137.4 KB62.2 KB75.3 KB
54.8%
ext.quicksurveys.lib16nxm14.3 KB7.6 KB6.7 KB
47.1%
ext.cite.ux-enhancements1bohi4.9 KB1.7 KB3.1 KB
64.6%
mw.cx.SiteMapper1fopq4.3 KB1.3 KB3.0 KB
69.6%
ext.tmh.player1rhlj6.5 KB3.6 KB2.9 KB
44.4%
jquery.makeCollapsible13r1h9.2 KB6.7 KB2.5 KB
27.2%
ext.cx.uls.quick.actionst68b02.5 KB1.1 KB1.4 KB
57.1%
mediawiki.toc1hi591.2 KB531 B666 B
55.6%
jquery.spinnerm5xio827 B234 B593 B
71.7%
ext.phonos.init1mtl8962 B512 B450 B
46.8%
mediawiki.page.media1h6ho949 B501 B448 B
47.2%
ext.cx.model1wwuh224 B224 B0 b
0.0%
ext.quicksurveys.init1b0cn345 B345 B0 b
0.0%
ext.scribunto.logs1dyyv141 B141 B0 b
0.0%
jquery.spinner.stylesxaarq2.2 KB2.2 KB0 b
0.0%
load.php[scripts:ext.wikimediaEvents]73.4 KB21.4 KB52.0 KB
70.8%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
ext.wikimediaEventsb1aez73.4 KB21.4 KB52.0 KB
70.8%
load.php[scripts:skins.vector.js]62.0 KB31.8 KB30.2 KB
48.7%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
skins.vector.js14fji62.0 KB31.8 KB30.2 KB
48.7%
load.php[scripts:ext.popups.main]93.6 KB66.6 KB27.0 KB
28.8%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
ext.popups.mainx6boi93.6 KB66.6 KB27.0 KB
28.8%
load.php[scripts:mediawiki.api]27.4 KB5.4 KB22.0 KB
80.4%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
mediawiki.apipwy0p27.4 KB5.4 KB22.0 KB
80.4%
load.php[scripts:ext.uls.interface]47.7 KB26.2 KB21.5 KB
45.0%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
ext.uls.interface1vogg47.7 KB26.2 KB21.5 KB
45.0%
load.php[scripts:ext.visualEditor.desktopArticleTarget.init]32.2 KB10.8 KB21.5 KB
66.6%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
ext.visualEditor.desktopArticleTarget.init1ppcs32.2 KB10.8 KB21.5 KB
66.6%
load.php[scripts:ext.visualEditor.targetLoader]23.3 KB2.8 KB20.5 KB
88.2%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
ext.visualEditor.targetLoaderatgms23.3 KB2.8 KB20.5 KB
88.2%
load.php[scripts:ext.gadget.ReferenceTooltips]21.7 KB7.4 KB14.3 KB
66.1%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
ext.gadget.ReferenceTooltips8teof21.7 KB7.4 KB14.3 KB
66.1%
load.php[scripts:ext.testKitchen]32.7 KB19.2 KB13.6 KB
41.4%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
ext.testKitchenm6xrf32.7 KB19.2 KB13.6 KB
41.4%
load.php[scripts:oojs]15.2 KB3.8 KB11.4 KB
75.1%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
oojs1797x15.2 KB3.8 KB11.4 KB
75.1%
load.php[scripts:ext.centralNotice.display]30.8 KB19.4 KB11.4 KB
37.1%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
ext.centralNotice.display1jgtq30.8 KB19.4 KB11.4 KB
37.1%
load.php[scripts:mediawiki.util]16.7 KB7.1 KB9.6 KB
57.4%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
mediawiki.util1pwbb16.7 KB7.1 KB9.6 KB
57.4%
load.php[scripts:mediawiki.jqueryMsg]30.1 KB20.6 KB9.5 KB
31.6%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
mediawiki.jqueryMsgarc6u30.1 KB20.6 KB9.5 KB
31.6%
load.php[scripts:mediawiki.page.ready]17.1 KB7.8 KB9.3 KB
54.5%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
mediawiki.page.ready12arm17.1 KB7.8 KB9.3 KB
54.5%
load.php[scripts:ext.navigationTiming]11.0 KB1.7 KB9.3 KB
84.3%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
ext.navigationTiming18ja511.0 KB1.7 KB9.3 KB
84.3%
load.php[scripts:mmv.bootstrap]28.7 KB21.7 KB7.0 KB
24.5%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
mmv.bootstrapn96he28.7 KB21.7 KB7.0 KB
24.5%
load.php[scripts:mediawiki.page.watch.ajax]9.9 KB2.9 KB7.0 KB
70.3%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
mediawiki.page.watch.ajax1mh2f9.9 KB2.9 KB7.0 KB
70.3%
load.php[scripts:ext.cite.referencePreviews]28.0 KB21.3 KB6.7 KB
24.1%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
ext.cite.referencePreviewsz17wp28.0 KB21.3 KB6.7 KB
24.1%
load.php[startup]68.0 KB62.3 KB5.7 KB
8.4%
load.php[scripts:ext.eventLogging.metricsPlatform]14.9 KB9.3 KB5.7 KB
37.8%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
ext.eventLogging.metricsPlatformadrwj14.9 KB9.3 KB5.7 KB
37.8%
load.php[scripts:jquery.textSelection]6.1 KB594 B5.6 KB
90.5%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
jquery.textSelection16q5k6.1 KB594 B5.6 KB
90.5%
load.php[scripts:mediawiki.language]9.0 KB3.5 KB5.4 KB
60.7%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
mediawiki.language11hcb9.0 KB3.5 KB5.4 KB
60.7%
load.php[scripts:ext.wikimediaEvents.testKitchen]6.4 KB1.8 KB4.6 KB
71.7%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
ext.wikimediaEvents.testKitchen1pb2h6.4 KB1.8 KB4.6 KB
71.7%
load.php[scripts:mediawiki.Title]10.5 KB6.4 KB4.1 KB
38.9%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
mediawiki.Title11zzw10.5 KB6.4 KB4.1 KB
38.9%

CSS files

showing 25 of 25 URLs (from 30 stylesheets), sorted by unused bytes
URLTotalUsedUnusedUnused %
load.php[styles:ext.cite.parsoid.styles]214.4 KB54.5 KB159.8 KB
74.6%
(inline stylesheet) 6 stylesheets157.3 KB14.3 KB143.0 KB
90.9%
load.php[styles:site.styles]6.7 KB2.3 KB4.4 KB
66.0%
TemplateStyles:r12460913303.1 KB1.2 KB1.9 KB
61.1%
TemplateStyles:r13586202341.3 KB231 B1.1 KB
82.5%
TemplateStyles:r13272699001.1 KB85 B1.0 KB
92.6%
TemplateStyles:r1349637415/mw-parser-output/.tmulti1.8 KB779 B1.0 KB
57.5%
TemplateStyles:r13334331062.1 KB1.3 KB801 B
38.1%
TemplateStyles:r12394002311.1 KB419 B690 B
62.2%
TemplateStyles:r13744274042.3 KB1.8 KB480 B
20.5%
TemplateStyles:r1034237262637 B172 B465 B
73.0%
TemplateStyles:r1307723979946 B559 B387 B
40.9%
TemplateStyles:r1290232777783 B420 B363 B
46.4%
TemplateStyles:r13642795172.1 KB1.9 KB203 B
9.4%
TemplateStyles:r1365158831859 B680 B179 B
20.8%
TemplateStyles:r1314755338851 B680 B171 B
20.1%
TemplateStyles:r1244412712242 B77 B165 B
68.2%
TemplateStyles:r1298804929210 B58 B152 B
72.4%
TemplateStyles:r1214851843363 B234 B129 B
35.5%
TemplateStyles:r1368532237303 B182 B121 B
39.9%
TemplateStyles:r1373117785783 B721 B62 B
7.9%
TemplateStyles:r1235611614795 B788 B7 B
0.9%
TemplateStyles:r1157919884576 B576 B0 b
0.0%
TemplateStyles:r1126788409205 B205 B0 b
0.0%
TemplateStyles:r103884131971 B71 B0 b
0.0%

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:ext.cite.ux-enhancements] is responsible for 62% of blocking time
96 ms of 156 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.

TBT82 ms
Max potential input delay95 ms
Total long tasks2
Total time182 ms
Last task at1.226 s
Before first paint0 ms0 tasks
Before FCP0 ms0 tasks
Before LCP0 ms0 tasks
After load182 ms2 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 frames5every frame ≥ 50 ms
Blocking time508.6 msacross all long frames — what hurts INP and TBT
Forced style & layout28.1 msscripts reading layout mid-frame
Blocking before LCP338.9 msdelaying the largest paint — fix these first
Blocking after load169.7 msafter the load event — didn't delay page load

What to fix first

ScriptFramesTime runningBlocking (share by run time)Forced style & layoutTriggered by
load.php[scripts:ext.cite.ux-enhancements]2144 ms96.4 mstimer or animation callback
load.php[startup]3108.2 ms60 ms28.1 msscript tag, timer 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 · 794 msat 120.4 ms · before LCP
blocking 338.9 ms
  • Scripts & other work437.2 ms
  • Animation callbacks0 ms
  • Style & layout356.8 ms
  • Render0 ms
2 scripts ran during this frame
Ran for
10.7 ms
How it started
script tag
Ran for
16 ms
Started by
IdleRequestCallback
How it started
timer or animation callback
Position in source
character 14402 into the file (locate it via DevTools → Performance → the Long Animation Frames track)
Long animation frame #2 · 193.6 msat 1.116 s · after load
blocking 128.9 ms
  • Scripts & other work110.2 ms
  • Animation callbacks38 ms
  • Style & layout45.4 ms
  • Render0 ms
2 scripts ran during this frame · forced style & layout 28.1 ms
Ran for
95.5 ms
Started by
TimerHandler:setTimeout
How it started
timer or animation callback
Position in source
character 75840 into the file (locate it via DevTools → Performance → the Long Animation Frames track)
Ran for
37.9 ms
Forced style and layout
28.1 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 #3 · 94.2 msat 1.482 s · after load
blocking 28.1 ms
  • Scripts & other work19.4 ms
  • Animation callbacks0 ms
  • Style & layout74.8 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 · 130.1 msat 1.314 s · after load
blocking 10 ms
  • Scripts & other work118.6 ms
  • Animation callbacks0 ms
  • Style & layout11.5 ms
  • Render0 ms
1 script ran during this frame
Ran for
48.5 ms
Started by
TimerHandler:setTimeout
How it started
timer or animation callback
Position in source
character 75840 into the file (locate it via DevTools → Performance → the Long Animation Frames track)
Long animation frame #5 · 55.6 msat 1.058 s · after load
blocking 2.7 ms
  • Scripts & other work32.2 ms
  • Animation callbacks14.3 ms
  • Style & layout9.1 ms
  • Render0 ms
2 scripts ran during this frame
Ran for
29.3 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
14.3 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)

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:ext.cite.ux-enhancements]
96 ms · 2 frames · worst 92 ms
load.php[startup]
60 ms · 5 frames · worst 37 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.

TBT518.3 ms
Blocking tasks5
TBT before LCP366.6 ms1 task

What kind of work blocked

mostly style & layout · 518 ms total
Style & layout339.4 ms65.5%
Running JavaScript90.6 ms17.5%
Other browser work46.6 ms9.0%
Paint & composite36.2 ms7.0%
Garbage collection4.8 ms0.9%
Parsing HTML & CSS0.7 ms0.1%
Style & layout (65%): 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)
Running JavaScript (17%): the scripts responsible are listed right below. See Slowest JS functions · Timers

Top scripts blocking the main thread

3 of 3 scripts
Browser's own work (no script responsible)
435 ms · 3 tasks
load.php[startup]
38 ms · 1 task

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.449 s total
Style & layout555 ms38.3%
Running JavaScript396 ms27.3%
Other browser work (scheduling)202 ms13.9%
Parsing HTML & CSS177 ms12.2%
Paint & composite95 ms6.6%
Garbage collection22 ms1.5%
Parsing & compiling JavaScript2 ms0.1%
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 201 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.

ModuleVersionSelf time
jquery16rou190.4 ms
(rest of the bundle, not tied to one module)28.5 ms
ModuleVersionSelf time
skins.vector.js14fji1.2 ms
(rest of the bundle, not tied to one module)2.3 ms
ModuleVersionSelf time
mediawiki.storagednxpi0.9 ms
(rest of the bundle, not tied to one module)0.1 ms
ModuleVersionSelf time
ext.centralNotice.startUptrejq0.7 ms
(rest of the bundle, not tied to one module)0.1 ms
ModuleVersionSelf time
ext.wikimediaEventsb1aez0.7 ms
ModuleVersionSelf time
ext.navigationTiming18ja50.7 ms
ModuleVersionSelf time
ext.testKitchenm6xrf0.2 ms
ModuleVersionSelf time
ext.eventLogging1xqug0.1 ms
ModuleVersionSelf time
ext.visualEditor.supportCheck1ll9l0.1 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 38 functions
FunctionWhereSelf timeTotal time
setAttributeBrowser internal (not your code)39.6 ms39.6 ms
querySelectorAllBrowser internal (not your code)29.2 ms29.2 ms
getPropertyValueBrowser internal (not your code)28.6 ms28.6 ms
indirectEvalload.php[startup]14.1 ms18.3 ms
buildFragmentload.php[scripts:ext.cite.ux-enhancements]11.8 ms12.7 ms
find
runs: querySelectorAll (22.0 ms), load.php[scripts:ext.cite.ux-enhancements] (1.1 ms)
load.php[scripts:ext.cite.ux-enhancements]11.0 ms35.6 ms
setItemBrowser internal (not your code)10.5 ms10.5 ms
insertBeforeBrowser internal (not your code)9.7 ms9.7 ms
setTimeoutBrowser internal (not your code)7.7 ms7.7 ms
flushWrites
runs: setItem (10.1 ms)
load.php[startup]6.8 ms17.6 ms
replaceChildBrowser internal (not your code)6.7 ms6.7 ms
requestIdleCallbackBrowser internal (not your code)6.5 ms6.5 ms
runScript
runs: load.php[scripts:skins.vector.js] (37.4 ms), load.php[scripts:ext.cite.ux-enhancements] (10.3 ms), load.php[scripts:ext.urlShortener.toolbar] (6.5 ms), load.php[scripts:ext.wikimediaEvents] (5.3 ms), load.php[scripts:ext.popups.main] (4.7 ms)
load.php[startup]5.7 ms92.0 ms
requireload.php[startup]5.4 ms11.5 ms
attr
runs: setAttribute (23.8 ms)
load.php[scripts:ext.cite.ux-enhancements]5.2 ms29.2 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 set57
Times fired55
Fire time215.8 ms
Zero-delay timers52
Repeating timers0
Zero-delay slicing: jquery split work into 50 back-to-back tasks costing 214 ms. Consider batching the work or moving it to requestIdleCallback or a worker.

Timer cost by script

7 scripts
load.php[startup]
151 ms · set 1 time · fired 18 times
load.php[scripts:ext.cite.ux-enhancements]
62 ms · set 51 times · fired 30 times
load.php[scripts:mediawiki.storage]
1 ms · set 2 times · fired 4 times
load.php[scripts:ext.centralNotice.startUp]
0 ms · set 0 times · fired 2 times
load.php[scripts:ext.wikimediaEvents]
0 ms · set 2 times · fired 0 times
load.php[scripts:ext.navigationTiming]
0 ms · set 1 time · fired 0 times

The timers, by where they were set

top 7 by fire time
Set byDelayTypeTimes setTimes firedFire time
jquery0 msonce5050213.9 ms
eval in ext.navigationTiming0 msonce110.7 ms
SafeStorage in mediawiki.storage2000 msonce220.6 ms
jquery0 msonce110.4 ms
requestUpdate in load.php[startup]:222000 msonce110.1 ms
run in ext.wikimediaEvents60000 msonce100.0 ms
setActive in ext.wikimediaEvents100000 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

1 reflow ≥ 2 ms across 1 script
load.php[startup]
28 ms · 1 reflow · worst 28 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
load.php[startup]
28 ms · across 1 frame

First vs third party CPU time

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

First party344 ms
Third party1 ms
Domains1

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