jQuery Was Supposed to Be Dead. 64% of the Web Still Runs It, and Those Sites Are Faster

For a decade, 'still using jQuery?' has been a polite way of calling a website old and slow. The advice that follows is always the same: rip it out, move to a modern framework, get faster. The field data says the opposite. Across nine and a half million websites, the ones still shipping jQuery pass Google's Core Web Vitals more often on mobile than the ones that dropped it.

That matters because speed is not a vanity metric. It decides whether a visitor stays or leaves, whether a product page converts, and how a page ranks in Google. Core Web Vitals are Google's attempt to put numbers on the experience real people feel: how fast the main content loads, how quickly the page responds to a tap, and how much the layout jumps around while it settles. A site that falls short is losing users and search visibility every day.

These figures come from Google's real-user field data, the same Chrome UX Report readings Google itself uses to judge a page, not a lab test on a fast connection. They describe how actual Chrome users experienced these sites on their own phones.

We started with HTTP Archive's technology detection, which records whether each site ships jQuery, and joined it to the Chrome UX Report, Google's field-data programme that collects Core Web Vitals from real Chrome users. That gave us 9.58 million mobile origins with a field reading, split into those that use jQuery and those that do not. Passing Core Web Vitals means a site is good on all three metrics at once at the 75th percentile of its visitors: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1. It is a high bar, set so that a passing site is fast for three-quarters of the people who load it, and these results are measured on mobile, where most of the web is browsed.

jQuery is supposed to be dead. It is not close. jQuery still runs on roughly 64% of the mobile origins in our dataset, about 6.1 million sites. It powers a huge share of the WordPress ecosystem, countless themes and plugins, and a long tail of classic server-rendered sites that have worked reliably for years.

That reach is what makes the comparison meaningful. Because jQuery sits under such a broad, ordinary cross-section of the web, comparing jQuery sites to the rest is really comparing two different architectural worlds, and the performance gap between them turns out to be large.

On mobile, sites that use jQuery pass Core Web Vitals 44.2% of the time. Sites that do not use it pass only 39.0% of the time. The library everyone treats as a performance anchor is attached to the faster-passing half of the web, a 5.2-point advantage.

The reason is not that jQuery makes pages fast. It is that the sites which carry jQuery tend to be lightweight, server-rendered pages that build their HTML on the server and add a little interactivity on top. The sites that removed jQuery usually replaced it with something much heavier.

Split the three metrics apart and the story sharpens. Loading is nearly identical between the two groups, and jQuery sites are slightly better on layout stability. Most of the gap lives in responsiveness. jQuery sites are good on Interaction to Next Paint 89.8% of the time on mobile; sites without it only 76.1%, a 13.7-point difference on the metric that measures how fast a page reacts to a tap.

This is selection, not sorcery. The no-jQuery population is dominated by React, Vue, Angular and other single-page-app frameworks, the stacks that, as our framework study shows, pass Core Web Vitals on barely a third of mobile sites. jQuery does comparatively little work: a bit of DOM manipulation, some event handling. A full framework downloads a large bundle, hydrates a component tree, and re-renders on every state change. On a mid-range phone that difference lands directly on Interaction to Next Paint.

So jQuery sites look good because the typical jQuery site never took on the responsiveness burden of a full client-side app. jQuery is the marker sitting on the lightweight side of the split, not the cause of the speed.

The clearest proof that jQuery is not the variable comes from desktop. There the ranking reverses: non-jQuery sites pass slightly more often, 56.9% to 55.2%. On a desktop CPU the frameworks' responsiveness penalty disappears, good-INP runs 97% to 99% for everyone, so the no-jQuery group's other advantages, often newer and better-maintained builds, edge them ahead.

The library did not change between mobile and desktop. Only the hardware did. That is the signature of a main-thread-cost story: it only hurts where the processor is slow enough to feel it, which is the phone in your visitor's hand.

Buckets are non-exclusive. Per-metric good rates are among origins where the metric is reported.

Do not rip out jQuery for Core Web Vitals reasons alone. The 44.2% versus 39.0% mobile pass rate, and the wider 89.8% versus 76.1% split on responsiveness, show no Interaction to Next Paint penalty for using it. Removing the library will not improve INP unless you are also cutting main-thread work, and the teams that swapped it for a heavier single-page-app framework are the ones now passing on barely a third of mobile origins.

The durable lesson sits underneath the jQuery headline. Most of the gap is responsiveness, and responsiveness is a main-thread cost that only bites where the processor is slow, which is why the ranking flips to 56.9% versus 55.2% on desktop hardware. Fast is an outcome of shipping less JavaScript to the phone, so a team that treats client-side code as a budget and measures INP on real mobile devices will pass more often than one chasing the newest stack.