In a Next.js app, what does importing a font from `next/font/google` do that a `<link>` to fonts.googleapis.com does not — where does the browser actually fetch the font file from at runtime?

## The problem next/font solves The classic way to use a Google font is a stylesheet link in the document head: ```html <link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Inter&display=swap"> ``` That one line hides a long serial chain. The browser does a DNS lookup and TLS handshake for `fonts.googleapis.com`, downloads the stylesheet — which is render-blocking, because it is a stylesheet in the head — parses it, and only *then* discovers that the actual font binary lives on a different host, `fonts.gstatic.com`. That means a second DNS lookup and TLS handshake, and finally the woff2 download. Nothing can be parallelised, because each step's URL is only known after the previous step finishes. On a slow connection this is easily several hundred milliseconds during which the page cannot paint text in its intended typeface. ## What next/font/google does instead In Next.js you write the font as an import and a call at the top of a module: ```ts import { Inter } from 'next/font/google' const inter = Inter({ subsets: ['latin'] }) ``` This is not a runtime API. `next/font` is implemented as a build-time transform: when the compiler sees this call it fetches the font files for the requested family, weights, styles and subsets, writes them into the application's own static output, and generates `@font-face` CSS that points at those local URLs. The call expression is replaced with an object describing the generated CSS. So in the shipped application: - There is **no** `<link>` to `fonts.googleapis.com` and **no** request to `fonts.gstatic.com`. - The `@font-face` declarations arrive with the page's own CSS, which the build already knows about, rather than being discovered after a third-party stylesheet parses. - The woff2 file is served from the same origin as the app, so it reuses the connection the browser already has open. The practical effect is that the discovery chain collapses from *three origins, three round-trip groups* to *one origin, one request*, and the font request can start much earlier because the browser learns about it from first-party CSS (and, where preloading applies, from a preload hint in the initial HTML). ## What it does not do Be precise here, because interviewers probe it. Self-hosting does **not** mean there is no font download — the woff2 still has to come over the network the first time. It means the download is same-origin and discovered earlier. It also does not, by itself, mean the text is painted in the web font immediately; the default `font-display` behaviour still shows a fallback face first and swaps when the font arrives. What next/font adds on top is automatic fallback-metric adjustment so that swap does not move the layout. Another nuance candidates miss: shared cross-site font caching stopped being a benefit years ago. Browsers partition the HTTP cache by top-level site, so a visitor who downloaded Inter from Google on another site does not get a cache hit on yours. The old argument for using Google's CDN — "the user probably already has it cached" — is simply false in current browsers, which removes the main reason anyone tolerated the third-party chain. ## The build-time consequences Because the work happens at build time, the font choice is fixed at build time. That has good and awkward consequences. Good: a typo in a family name, or a weight that family does not publish, fails the build with a clear error rather than producing a silent fallback in production. Also good: your app has no runtime dependency on a third-party host, and no request carrying the user's IP and User-Agent leaves for Google on every page view — which is exactly the argument used in the GDPR discussions that pushed many teams to self-host in the first place. Awkward: the fonts are pinned to whatever the build fetched, and the build needs network access to Google's font endpoints (or a warm cache) to succeed. If a build environment is fully offline, the equivalent is `next/font/local`, where you commit the font files into the repo and point the loader at them with a `src` path. `next/font/local` gives the same generated `@font-face` output and the same self-hosted serving; it just skips the download step because you supplied the binaries. ## How to verify it in an interview answer A convincing answer names the observable check: open DevTools, filter the network panel by Font, and confirm the woff2 request is on your own origin, then search the shipped HTML for `fonts.googleapis.com` and find nothing. That is a concrete, falsifiable claim, and it is exactly what a reviewer would do to confirm someone actually migrated a page off the third-party link.