Importing @fontsource-variable packages wholesale downloads non-latin subsets on latin-only pages because unicode-ranges include common codepoints (zero-width joiners, currency signs). Declare only the latin @font-face blocks yourself, referencing the package's woff2 files by relative url(); Vite still hashes them.
A bare import '@fontsource-variable/noto-sans' registers @font-face blocks for every script subset (cyrillic, greek, devanagari, vietnamese, latin) distinguished only by unicode-range. Browsers download any subset whose range matches ANY rendered glyph - and the ranges include easy-to-hit codepoints: the devanagari subset covers U+200C-200D (zero-width joiners), U+20B9 (rupee sign), U+25CC. Result observed via Lighthouse network audits: the 97KB devanagari woff2 downloaded on every page of a latin-only site.
Fix when the package ships no per-subset CSS (fontsource variable packages ship only aggregate index.css/wght.css): copy just the latin + latin-ext @font-face blocks into your own stylesheet, pointing src at the package files by relative path, e.g. url('../../../node_modules/@fontsource-variable/noto-sans/files/noto-sans-latin-wght-normal.woff2'). Vite resolves the relative url(), content-hashes the files into immutable assets exactly like the original import, and non-latin subsets simply never load.
Diagnosis tip: an unexpected font file in a Lighthouse/DevTools waterfall whose name contains a script you never render (devanagari, cyrillic-ext) is this pattern.