Bundle Size and Core Web Vitals: What We Usually Measure After a Vue 3 Migration (and What Surprises Us)

A rollup-plugin-visualizer treemap (or the Vite equivalent) is still essential—it shows which dependencies dominate the graph. But Core Web Vitals are measured on real users. After go-live, we line up CrUX (if you have enough traffic) or RUM you already run (DataDog, Sentry Performance, etc.) with at least a two-week window before/after the release.

Lab tools like Lighthouse remain useful for debugging, but they are a spot check. The pattern we watch for: lab scores improve while LCP p75 in the field is flat. That almost always means the critical path is not the framework—it is hero images, third-party scripts, or server time to first byte.

Interaction to Next Paint (INP) is sensitive to long tasks on the main thread. Vue 3’s reactivity and smaller runtime can reduce work per update, and moving off legacy Babel targets can help too—especially if you were shipping large polyfill bundles to support aging browsers for Vue 2.

LCP, by contrast, is frequently dominated by the largest image or font and by when your app becomes interactive enough to render it. Do not be surprised if INP improves while LCP needs a separate pass on assets and critical CSS. If you are also changing the build tool ( Webpack to Vite, for example), confirm you did not accidentally change chunk boundaries in a way that delays the LCP image request.

Total kilobytes can drop while Total Blocking Time in Lighthouse stays elevated. Common causes: one vendor bundle (chat, analytics, A/B) still executing a long script during startup; synchronous JSON inlined in HTML; or a large synchronous import on a layout component that every route loads.

The fix is usually route-level or feature-level lazy loading, not another pass over Vue itself. This is where a migration checklist helps: verify dynamic imports for admin-only and modal-only chunks after the framework work is stable.

We try to lead with one field metric the executive cares about (usually LCP p75 on a key template) and one engineering metric (main bundle size or JS parse time) so both sides see a coherent story. We avoid “the site is faster” without a labeled chart.

• Before/after for the same week-over-week period to control for seasonality
• Segment by connection type or country if traffic is global
• Call out confounders (marketing added pixels, a new hero image, a pricing page redesign)

There is no single tool that answers “did Vue 3 make us faster?” cleanly. The setup we use on most engagements is a small, boring combination of build-time, lab, and field tools that each answer a different question. The trick is wiring them up before you cut over so the “after” is comparable.

Build-time

• rollup-plugin-visualizer or vite-bundle-visualizer for treemaps; we save the JSON output per release
• size-limit with a budget per route entry, wired into CI so a regression fails the PR
• Source map explorer when a chunk grows and you need to find the new tenant (often a transitive dependency, not your code)

Lab

• Lighthouse CI on at least three template URLs (home, a long-tail content page, an authenticated dashboard)
• WebPageTest for waterfalls when LCP regresses and you need to see request order across CDN, app, and third parties

Field

• CrUX (via PageSpeed Insights or BigQuery) for p75 LCP, INP, CLS by URL group
• RUM in your existing stack (Sentry, DataDog, New Relic) so you can segment by browser, country, and release
• A simple web-vitals shim that posts to your analytics endpoint when CrUX coverage is thin

Even on clean migrations, a few patterns repeat. None of them mean the upgrade was a mistake; they just remind you that bundle size is one input to user-perceived performance, not the whole story.

Most teams skip writing down a JavaScript budget because it feels arbitrary. It is, a little. But arbitrary numbers in CI still beat zero numbers in CI. We usually start with three budgets per template that are tracked release-over-release:

// .size-limit.json
[
  { "path": "dist/assets/entry-home-*.js",    "limit": "60 KB" },
  { "path": "dist/assets/entry-app-*.js",     "limit": "180 KB" },
  { "path": "dist/assets/vendor-*.js",        "limit": "220 KB" }
]

Numbers are gzip-compressed. Pick yours from a measured baseline plus 10% headroom; tighten quarterly. Pair budgets with a rule that any PR exceeding them must include a one-line justification on the PR description. That single discipline tends to keep bundles within range across teams who never otherwise talk about performance.

• “We removed Vue 2 polyfills, ship it.” Many apps still target browserslist defaults that include IE-era polyfills. Audit browserslist together with the upgrade.
• Global imports on shared layouts. A single import dayjs from 'dayjs' in App.vue can pull plugins into every route. Co-locate inside the component that needs it.
• Storing performance data only in lab. Field data is the source of truth. Lab is for repro, not reporting.
• Comparing different weeks. Always align Tuesday-to-Tuesday over the same campaign or promotion window when comparing pre- and post-migration.
• Treating Vite as a free win. Build tool choice matters, but if your app is image-heavy or third-party heavy, see our Webpack-to-Vite mid-migration notes before claiming credit for runtime wins.

• Lock a baseline before cutover (CrUX + lab + bundle JSON)
• Add size-limit budgets to CI
• Verify route-level code splitting per top template
• Audit browserslist and drop legacy targets
• Move heavy globals (date, charts, markdown) into lazy chunks
• Add fetchpriority="high" on the LCP image
• Pre-connect to required third parties; defer the rest
• Re-baseline budgets quarterly so wins compound

If you are still wrestling with state management or test stability while reading bundle reports, that is normal. See our full Vue 3 migration checklist and our notes on Cypress component tests after Vue 3 for sequencing.

Conclusion

Vue 3 is a real opportunity to improve Core Web Vitals, but the framework is only one layer in the stack. Measure field data, watch for INP and LCP diverging, and keep an eye on third-party and asset pipelines when the numbers look “wrong” after a successful upgrade.

Getting the measurement story right is what turns a technical win into budget for the next round of improvements.