Page summary

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

Tested 2026-08-24 22:54:54 using Chrome 151.0.7922.75 (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
91 / 100
Performance
79 / 100
Best practice
80 / 100
Privacy

How it loaded →

0 → 1.666 s · median run
Frame at 0 ms
start
Frame at 1000 ms
1.000 s
Frame at 1100 ms
Largest paint1.100 s
Frame at 1300 ms
1.300 s
Frame at 1500 ms
1.500 s
Frame at 1700 ms
Complete1.700 s
1.000 s
First Visual Change
1.030 s
Speed Index
1.000 s
Visual Complete 85%
1.666 s
Last Visual Change
TTFB110 msLCP1.012 sTBT65 msCLS0.00

What to act on · top recommendations

Serve images in modern formats (AVIF, WebP)

0 / 100

The page ships 61 images (out of 61) 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 91.5 kB the next access.

Avoid CPU Long Tasks

60 / 100

The page has 2 CPU long tasks with the total of 171 ms. The total blocking time is 71 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)110 ms110 ms110 ms110 msidentical
Largest Contentful Paint (LCP)984 ms1.012 s1.020 s1.048 sstable ±3%
Cumulative Layout Shift (CLS)0.00050.00050.00050.0005identical

Visual Metrics

min · median · mean · max of 5 runs
MetricMinMedianMeanMaxRuns agree?
First visual change966 ms1.000 s1.006 s1.033 sstable ±3%
Last visual change1.666 s1.666 s1.680 s1.700 sstable ±1%
Speed index995 ms1.030 s1.035 s1.060 sstable ±3%
Largest image1.133 s1.200 s1.180 s1.200 sstable ±3%
Heading966 ms1.000 s1.006 s1.033 sstable ±3%
Largest contentful paint1.133 s1.200 s1.180 s1.200 sstable ±3%
Last meaningful paint1.133 s1.200 s1.180 s1.200 sstable ±3%
Visual readiness633 ms666 ms673 ms734 msvaries ±8%
Visual complete 85966 ms1.000 s1.006 s1.033 sstable ±3%
Visual complete 951.133 s1.200 s1.180 s1.200 sstable ±3%
Visual complete 991.500 s1.533 s1.533 s1.566 sstable ±2%

CPU

min · median · mean · max of 5 runs
MetricMinMedianMeanMaxRuns agree?
Total Blocking Time54 ms65 ms72 ms109 msruns disagree ±42%
Max Potential FID89 ms104 ms102 ms112 msruns disagree ±11%
CPU long tasks 2224runs disagree ±50%
CPU last long task happens at1.271 s1.444 s1.446 s1.634 sruns disagree ±13%

More metrics

min · median · mean · max of 5 runs
MetricMinMedianMeanMaxRuns agree?
First paint984 ms1.012 s1.020 s1.048 sstable ±3%
Load event end1.030 s1.068 s1.155 s1.436 sruns disagree ±19%

User Timing

min · median · mean · max of 5 runs
MetricMinMedianMeanMaxRuns agree?
mwStartup132 ms133 ms133 ms136 msstable ±2%

Waterfall

Run 5 SpeedIndex median

First paintFCPLCPDOMContentLoadedDOM interactiveLoadRender-blockingRedirectError

Rendering

Run 5 · 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.000 s
1.000 s
88 %
Frame at 1.100 s
1.100 s
88 %
Frame at 1.200 s
1.200 s
98 %
Frame at 1.300 s
1.300 s
98 %
Frame at 1.500 s
1.500 s
98 %
Frame at 1.600 s
1.600 s
99 %
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

18.9 % 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 shown14
Partial1
Dropped0
Effective FPS19.7
Longest gap171 msat 1.220 s

Why was rendering delayed?

Rendering was not meaningfully delayed. First paint landed at 1.012 s on a 110 ms first byte; the 1 render-blocking request was done by 524 ms and the remaining ~488 ms is style and layout work (228 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 257 elements cost 228 ms before the page painted (22.5 % of the time to First Contentful Paint), and a single recalculation of 15 635 elements accounts for 212 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.012 s)

Recalculations18
Elements16257
Total time227.633 ms
Largest recalculation15635 elements · 211.772 ms

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

Render blocking requests

1 request · 27.2 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 110 ms
493 ms
412.5 KB492 ms
ext.cite.parsoid.styles + 16 more modulesblocking
css · load.php styles batch · en.wikipedia.org
406 ms
27.2 KB406 ms
0253 ms506 msFCP · LCP 1.012 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 143 ms. The wasted-work list below (selectors tried thousands of times that never match) is the place to start.

Matching time143 ms
Match attempts2 265 661
Matches97 126

Selectors by matching time

top 25
SelectorTimeAttemptsMatches
[rel~="mw:referencedBy"]::before4.52 ms9 7892 682
body.mw-mmv-lightbox-open > :not(.mw-notification-area-overlay)3.12 ms17 0160
a:where(:not([role="button"])):visited2.97 ms18 2027 474
a:where(:not([role="button"])):visited:hover2.88 ms18 2020
a:where(:not([role="button"])):visited:active2.55 ms18 2020
.mw-parser-output a2.19 ms9 1017 217
a:visited2.17 ms18 2027 487
.skin-theme-clientpref-night .ns-100 .mw-parser-output :not(.notheme):not(a)1.76 ms33 0710
a[rel="mw:referencedBy"]::before1.62 ms9 7892 562
a:not([href])1.60 ms9 1010

Wasted selector work: attempts that never match

top 25
SelectorAttemptsTime
.cdx-message__content > *33 0711.36 ms
.skin-theme-clientpref-night .ns-100 .mw-parser-output :not(.notheme):not(a)33 0711.76 ms
.cdx-message__content > :first-child33 0711.04 ms
.client-js .outercollapse .innercollapse.mw-collapsible:not(.mw-made-collapsible) :is(tr:not(:first-child), .mw-collapsible-content)33 0711.15 ms
.cdx-message__content > :last-child33 0711.06 ms
.client-js .outercollapse .innercollapse.mw-collapsible:not(.mw-made-collapsible) > :is(p, table, thead + tbody)33 0711.43 ms
.mw-body-content figure[typeof~="mw:File"] > a18 2020.68 ms
a:where(:not([role="button"])):visited:hover18 2022.88 ms
.vector-dropdown-content .mw-list-item a:not(.mw-selflink):visited:hover18 2020.57 ms
.vector-menu-tabs .mw-list-item.new a:visited18 2020.51 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 480 style recalculations and 3 559 layout invalidations fired after first paint, on a page the user was already looking at. The biggest driver is attribute title (446×). Start with the script under "Scripts causing invalidations" that keeps triggering it.

Style recalculations2 5682 480 after first paint
Layout invalidations31 7713 559 after first paint

Changes that keep invalidating

top 15
  • attribute: title446×
  • attribute: style249×
  • attribute: hidden152×
  • attribute: class107×
  • pseudo: has50×
  • pseudo: disabled42×
  • pseudo: enabled42×
  • class: mw-made-collapsible35×
  • attribute: disabled28×
  • class: mw-collapsed16×
  • attribute: controls
  • class: phase-pre-ready
  • class: state-no-source
  • attribute: id
  • class: vector-animations-ready

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 568
Related style rule707
A node was inserted into the page95
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.16
Attribute21
An @keyframes rule changed4
An element entered layout516
An element left layout2 528
List value change460
A style change forced layout21
An element's size changed12
Unknown10
An SVG element changed7
Slider value changed5

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 rule24
A node was inserted into the page35
JavaScript changed an inline styleSet a class instead of writing element.style, so the browser can batch the work.24
An animation updated stylesAnimate transform and opacity so the compositor can run it off the main thread.4
An element entered layout28 189
An element left layout11
A style change forced layout1
An element's size changed2
Unknown2
An SVG element changed5
Scrollbar changed2

Scripts causing invalidations

top 8

4 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

91
5 warnings3 info
warn(0)Serve images in modern formats (AVIF, WebP)modernImageFormats

The page ships 61 images (out of 61) 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 91.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
warn(60)Avoid CPU Long TaskslongTasks

The page has 2 CPU long tasks with the total of 171 ms. The total blocking time is 71 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
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 (27810) 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.2 KB215.8 KB
infoAdd decoding="async" to non-critical imagesdecodingAsync

The page has 5 images (out of 66) 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 4501 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.16The tool or CMS that generated the HTML, from the page generator meta tag.
Layout viewport1904 × 51735 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,005Very 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 storage988.7 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://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

4 technologies

Data from run 5

Visual Metrics

Visual milestones

all times from navigation start
Speed Index1.03 show quickly the page looked done
First Visual Change1.00 sfirst paint reaches the screen
Last Visual Change1.67 sscreen stops changing · 0.67 s after first
nothing painted yet
≥85%
≥95% rendered
First Visual Change · Visual Complete 85%1.00 s
Visual Complete 95%1.20 s
Visual Complete 99%1.53 s
Last Visual Change1.67 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 s1.0s
Visual progress at 1.1 s1.1s
Visual progress at 1.3 s1.3s
Visual progress at 1.5 s1.5s
Visual progress at 1.6 s1.6s
Visual progress at 1.7 s1.7s
FCP1.01s
LCP1.01s
VC851.00s
Long tasks
0.0s0.3s0.7s1.0s1.4s1.7s

Google Web Vitals

from run 5

Largest Contentful Paint

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

1.012 sLCP render time

Phase breakdown

  • TTFB110 ms
  • Resource load delay0 ms
  • Resource load duration0 ms
  • Element render delay902 ms

Element

Element type
<p>
Element id
mwHg
Size (w × h)
188163
Load time
0 ms
Style recalculation before LCP
18 recalculations touching 16257 elements (227.633 ms) — the largest touched 15635 elements (211.772 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.001cumulative layout shift score

One shift is 100% of your 0.001 CLS. div#skin-client-prefs-skin-theme moved at 1.650 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.

The shift is spread across many movements below 0.01, none large enough to single out. Check the video or filmstrip to see what moved.

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
mwStartup132 ms

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 ms2495046054

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.200 s
Position (x, y)1145, 311
Size (w × h)250 × 312
HTML snippet
<img resource="https://en.wikipedia.org/wiki/File:President_Barack_Obama.jpg" src="//upload.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="//upload.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.000 s
Position (x, y)478, 90
Size (w × h)796 × 40
HTML snippet
<h1 id="firstHeading" class="firstHeading mw-first-heading"></h1>
LargestContentfulPaint
Display time1.200 s
Position (x, y)478, 415
Size (w × h)948 × 312
HTML snippet
<p id="mwHg"></p>

PageXray

How the page is built.

HTTP versionHTTP/2.0
Total requests30
Total domains2
Transfer size599.1 KB
Content size3.1 MB
Missing compression0
Cookies20 third-party

Main document

status 200 · 0 redirects

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

HeaderValue
accept-ch
accept-rangesbytes
age669
cache-controlprivate, s-maxage=0, max-age=0, must-revalidate, no-transform
content-encodinggzip
content-languageen
content-length416541
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 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 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
dateMon, 24 Aug 2026 22:47:33 GMT
last-modifiedMon, 24 Aug 2026 22:29:20 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-5bc9965477-cgf2h
server-timingcache;desc="hit-front", host;desc="cp3070",co_id;desc="2495046054"
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-id2849287a-8558-4157-bcb3-864971685a5f

Response codes

200
2996.7%
202
13.3%

Requests and sizes per content type

6 types

Transfer size599.1 KB

  • html68.9%
  • image13.9%
  • javascript8.9%
  • css4.5%
  • svg3.7%
  • plain0.15%

Content size3.1 MB

  • html84.9%
  • css6.8%
  • javascript5.9%
  • image2.1%
  • svg0.24%

Requests30

  • svg56.7%
  • image30.0%
  • html3.3%
  • css3.3%
  • javascript3.3%
  • plain3.3%
ContentHeader SizeTransfer SizeContent SizeRequests
html0 b412.5 KB2.6 MB1
css0 b27.2 KB215.8 KB1
javascript0 b53.3 KB185.8 KB1
image0 b83.0 KB68.0 KB9
svg0 b22.3 KB7.7 KB17
plain0 b900 B0 b1
Total0 b599.1 KB3.1 MB30

Data per domain

2 domains
DomainTotal download timeTransfer SizeContent SizeRequests
en.wikipedia.org3.057 s509.8 KB3.0 MB18
upload.wikimedia.org1.809 s89.4 KB71.0 KB12

Expires & last-modified statistics

typeminmedianmax
Expires0 seconds2 weeks1 year
Last modified18 minutes11 weeks10 years

Requests loaded after onLoad event

10 requests

Includes requests done after load event end.

ContentTransfer SizeRequests
html0 b0
css0 b0
javascript0 b0
image0 b0
font0 b0
favicon0 b0
svg11.6 KB10
Total11.6 KB10

Requests loaded after onContentLoad

11 requests

Includes requests done after DOM content loaded.

ContentTransfer SizeRequests
html0 b0
css0 b0
javascript0 b0
image0 b0
font0 b0
favicon0 b0
plain900 B1
svg11.6 KB10
Total12.5 KB11

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.2 MB
JS unused502.3 KB
JS unused %41.9%
CSS total465.8 KB
CSS unused378.6 KB
CSS unused %81.3%

Where the bytes go

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

1.6 MB of script and style shipped, and 880.9 KB of it never ran on this page. The biggest win is the inline code: 221.3 KB delivered, 204.8 KB unused.

inline221.3 KB · 93% unused
load.php[styles:ext.cite.parsoid.styles]215.8 KB · 74% unused
load.php[scripts:ext.cite.ux-enhancements]185.8 KB · 56% unused
load.php[scripts:ext.popups.main]93.6 KB · 29% unused
load.php[scripts:ext.wikimediaEvents]71.5 KB · 70% unused
load.php[scripts:mmv.codex]71.1 KB · 0% unused
load.php[startup]67.3 KB · 9% unused
load.php[scripts:skins.vector.js]62.0 KB · 49% unused
load.php[scripts:ext.uls.interface]47.9 KB · 45% unused
load.php[scripts:ext.visualEditor.desktopArticleTarget.init]31.7 KB · 67% unused
load.php[scripts:ext.centralNotice.display]30.8 KB · 69% unused
load.php[scripts:mediawiki.jqueryMsg]30.1 KB · 32% unused
inline29.6 KB · 1% unused
load.php[scripts:ext.testKitchen]29.5 KB · 36% 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:mmv.bootstrap]27.2 KB · 26% 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.0 KB · 54% 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.1 KB · 69% unused
load.php[scripts:mediawiki.language]9.0 KB · 61% unused
load.php[scripts:ext.centralNotice.choiceData]8.9 KB · 0% unused
load.php[scripts:ext.centralNotice.kvStore]7.1 KB · 80% unused
load.php[scripts:jquery.textSelection]6.1 KB · 91% unused
load.php[scripts:ext.wikimediaEvents.testKitchen]5.0 KB · 78% unused
65 more files119.3 KB · 47% 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 502.3 KBThird 0 b
CSS unused
First 378.6 KBThird 0 b

JavaScript files

showing 25 of 76 URLs (from 78 scripts), sorted by unused bytes
URLTotalUsedUnusedUnused %
load.php[scripts:ext.cite.ux-enhancements]185.8 KB82.4 KB103.4 KB
55.7%
15 modules in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
jquery16rou137.4 KB55.4 KB82.0 KB
59.7%
ext.quicksurveys.lib1fpdw14.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.8 KB2.7 KB
41.1%
jquery.makeCollapsible1hfl29.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 B669 B280 B
29.5%
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.stylesii5wt2.2 KB2.2 KB0 b
0.0%
load.php[scripts:ext.wikimediaEvents]71.5 KB21.2 KB50.3 KB
70.4%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
ext.wikimediaEventsld9cv71.5 KB21.2 KB50.3 KB
70.4%
load.php[scripts:skins.vector.js]62.0 KB31.7 KB30.3 KB
48.9%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
skins.vector.js4b8bz62.0 KB31.7 KB30.3 KB
48.9%
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.main1lydc93.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.apiz5im027.4 KB5.4 KB22.0 KB
80.4%
load.php[scripts:ext.uls.interface]47.9 KB26.2 KB21.6 KB
45.2%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
ext.uls.interface1qeqr47.9 KB26.2 KB21.6 KB
45.2%
load.php[scripts:ext.centralNotice.display]30.8 KB9.5 KB21.3 KB
69.1%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
ext.centralNotice.display1jgtq30.8 KB9.5 KB21.3 KB
69.1%
load.php[scripts:ext.visualEditor.desktopArticleTarget.init]31.7 KB10.6 KB21.2 KB
66.7%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
ext.visualEditor.desktopArticleTarget.init1k7ox31.7 KB10.6 KB21.2 KB
66.7%
load.php[scripts:ext.visualEditor.targetLoader]23.3 KB2.8 KB20.6 KB
88.2%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
ext.visualEditor.targetLoaderde2wa23.3 KB2.8 KB20.6 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: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.testKitchen]29.5 KB18.9 KB10.6 KB
36.0%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
ext.testKitchen1rj0w29.5 KB18.9 KB10.6 KB
36.0%
load.php[scripts:mediawiki.util]16.7 KB7.1 KB9.6 KB
57.4%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
mediawiki.util15zox16.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: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:mediawiki.page.ready]17.0 KB7.8 KB9.2 KB
54.3%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
mediawiki.page.readyzdup417.0 KB7.8 KB9.2 KB
54.3%
load.php[scripts:mmv.bootstrap]27.2 KB20.2 KB7.0 KB
25.7%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
mmv.bootstrap1wfvb27.2 KB20.2 KB7.0 KB
25.7%
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.referencePreviewsuchsq28.0 KB21.3 KB6.7 KB
24.1%
load.php[scripts:mediawiki.page.watch.ajax]9.1 KB2.8 KB6.3 KB
69.3%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
mediawiki.page.watch.ajax126um9.1 KB2.8 KB6.3 KB
69.3%
load.php[startup]67.3 KB61.6 KB5.7 KB
8.5%
load.php[scripts:ext.centralNotice.kvStore]7.1 KB1.4 KB5.7 KB
80.0%
1 module in this bundle, by unused bytes
ModuleVersionTotalUsedUnusedUnused %
ext.centralNotice.kvStore1ggbc7.1 KB1.4 KB5.7 KB
80.0%
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: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 29 stylesheets), sorted by unused bytes
URLTotalUsedUnusedUnused %
(inline stylesheet) 5 stylesheets221.3 KB16.5 KB204.8 KB
92.6%
load.php[styles:ext.cite.parsoid.styles]215.8 KB55.5 KB160.3 KB
74.3%
load.php[styles:site.styles]6.5 KB2.3 KB4.2 KB
65.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:r13331330642.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:r1266661725783 B721 B62 B
7.9%
TemplateStyles:r1235611614795 B788 B7 B
0.9%
TemplateStyles:r1157919884576 B576 B0 b
0.0%
TemplateStyles:r103884131971 B71 B0 b
0.0%
TemplateStyles:r1126788409205 B205 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 78% of blocking time
119 ms of 152 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.

TBT65 ms
Max potential input delay105 ms
Total long tasks2
Total time165 ms
Last task at1.448 s
Before first paint0 ms0 tasks
Before FCP0 ms0 tasks
Before LCP0 ms0 tasks
After load165 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 frames6every frame ≥ 50 ms
Blocking time551 msacross all long frames — what hurts INP and TBT
Blocking before LCP353.6 msdelaying the largest paint — fix these first
Blocking after load187.6 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]2148.7 ms119.2 mstimer or animation callback
load.php[startup]272.9 ms32.9 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 · 786.3 msat 120.9 ms · before LCP
blocking 353.6 ms
  • Scripts & other work414.2 ms
  • Animation callbacks0.1 ms
  • Style & layout372 ms
  • Render0 ms
2 scripts ran during this frame
Ran for
11.4 ms
How it started
script tag
Ran for
15.7 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 · 182.5 msat 1.189 s · after load
blocking 107.8 ms
  • Scripts & other work130.5 ms
  • Animation callbacks0.1 ms
  • Style & layout51.9 ms
  • Render0 ms
1 script ran during this frame
Ran for
105.9 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 #3 · 124.8 msat 1.381 s · after load
blocking 50.1 ms
  • Scripts & other work67.6 ms
  • Animation callbacks2.3 ms
  • Style & layout54.9 ms
  • Render0 ms
1 script ran during this frame
Ran for
42.8 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 #4 · 96.6 msat 1.512 s · after load
blocking 29.7 ms
  • Scripts & other work20 ms
  • Animation callbacks0.1 ms
  • Style & layout76.5 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 #5 · 68 msat 1.067 s · before load
blocking 9.8 ms
  • Scripts & other work36.4 ms
  • Animation callbacks17.8 ms
  • Style & layout13.8 ms
  • Render0 ms
2 scripts ran during this frame
Ran for
28.2 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
17.6 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)

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:ext.cite.ux-enhancements]
119 ms · 2 frames · worst 87 ms
load.php[startup]
33 ms · 4 frames · worst 13 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.4 ms
Blocking tasks6
TBT before LCP380.6 ms1 task

What kind of work blocked

mostly style & layout · 518 ms total
Style & layout346.0 ms66.8%
Running JavaScript93.5 ms18.0%
Other browser work45.3 ms8.7%
Paint & composite27.6 ms5.3%
Garbage collection4.3 ms0.8%
Parsing HTML & CSS1.6 ms0.3%
Style & layout (67%): usually a large DOM, expensive CSS selectors or JavaScript forcing synchronous layout. See Forced reflows · Slowest CSS selectors (Rendering tab) · Style invalidations (Rendering tab)
Running JavaScript (18%): 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)
452 ms · 4 tasks
load.php[startup]
10 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.443 s total
Style & layout585 ms40.5%
Running JavaScript384 ms26.6%
Other browser work (scheduling)198 ms13.7%
Parsing HTML & CSS169 ms11.7%
Paint & composite86 ms6.0%
Garbage collection19 ms1.3%
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 197 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
jquery16rou159.5 ms
(rest of the bundle, not tied to one module)19.5 ms
ModuleVersionSelf time
skins.vector.js4b8bz0.9 ms
(rest of the bundle, not tied to one module)9.5 ms
ModuleVersionSelf time
mediawiki.storagednxpi0.8 ms
(rest of the bundle, not tied to one module)0.2 ms
ModuleVersionSelf time
ext.centralNotice.startUp1ipzh0.6 ms
(rest of the bundle, not tied to one module)0.3 ms
ModuleVersionSelf time
ext.wikimediaEventsld9cv0.7 ms
ModuleVersionSelf time
ext.navigationTiming18ja50.5 ms
ModuleVersionSelf time
ext.testKitchen1rj0w0.1 ms
(rest of the bundle, not tied to one module)0.1 ms
ModuleVersionSelf time
ext.visualEditor.supportCheck1ll9l0.1 ms
ModuleVersionSelf time
ext.eventLogging1jxo20.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 41 functions
FunctionWhereSelf timeTotal time
setAttributeBrowser internal (not your code)36.1 ms36.1 ms
querySelectorAllBrowser internal (not your code)28.8 ms28.8 ms
getPropertyValueBrowser internal (not your code)14.5 ms14.5 ms
indirectEvalload.php[startup]14.1 ms18.1 ms
buildFragmentload.php[scripts:ext.cite.ux-enhancements]11.6 ms12.3 ms
insertBeforeBrowser internal (not your code)11.1 ms11.1 ms
replaceChildBrowser internal (not your code)9.6 ms9.6 ms
setItemBrowser internal (not your code)9.3 ms9.3 ms
find
runs: querySelectorAll (22.9 ms), load.php[scripts:ext.cite.ux-enhancements] (1.8 ms)
load.php[scripts:ext.cite.ux-enhancements]8.1 ms34.1 ms
runScript
runs: load.php[scripts:skins.vector.js] (23.0 ms), load.php[scripts:ext.cite.ux-enhancements] (8.5 ms), load.php[scripts:ext.urlShortener.toolbar] (8.1 ms), load.php[scripts:ext.wikimediaEvents] (6.8 ms), load.php[scripts:ext.popups.main] (4.3 ms)
load.php[startup]6.6 ms76.6 ms
setTimeoutBrowser internal (not your code)6.5 ms6.5 ms
attr
runs: setAttribute (23.6 ms)
load.php[scripts:ext.cite.ux-enhancements]5.2 ms30.1 ms
requireload.php[startup]4.8 ms11.4 ms
flushWrites
runs: setItem (9.3 ms)
load.php[startup]4.7 ms14.4 ms
addload.php[scripts:ext.cite.ux-enhancements]4.4 ms7.5 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 set53
Times fired51
Fire time177.9 ms
Zero-delay timers47
Repeating timers0
Zero-delay slicing: jquery split work into 45 back-to-back tasks costing 176 ms. Consider batching the work or moving it to requestIdleCallback or a worker.

Timer cost by script

6 scripts
load.php[scripts:ext.cite.ux-enhancements]
162 ms · set 46 times · fired 28 times
load.php[startup]
15 ms · set 2 times · fired 17 times
load.php[scripts:mediawiki.storage]
0 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 msonce4545176.1 ms
jquery0 msonce110.6 ms
eval in ext.navigationTiming0 msonce110.6 ms
SafeStorage in mediawiki.storage2000 msonce220.5 ms
requestUpdate in load.php[startup]:222000 msonce220.2 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

2 reflows ≥ 2 ms across 2 scripts
load.php[startup]
14 ms · 1 reflow · worst 14 ms
load.php[scripts:skins.vector.js]
2 ms · 1 reflow · worst 2 ms

First vs third party CPU time

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

First party318 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.

Why they could not be composited

4 animations
  • animation has no visible change

The reason decides the action: “animation has no visible change” means Chrome skipped compositing because nothing visible moves — harmless. Property-related reasons mean the keyframes animate something other than transform or opacity.

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