Comment importer Google Fonts en CSS
How to Import Google Fonts in CSS
Adding a custom font to a website used to require licensing, purchasing font files, and manually configuring web font delivery. Google Fonts changed this completely. Since its launch in 2010, Google Fonts has made professional-quality typefaces available to anyone with a text editor and a browser, with an API that handles file delivery, compression, and browser compatibility automatically.
Despite this simplicity, Google Fonts is frequently implemented in ways that damage performance, create rendering problems, or miss important optimization opportunities. This guide covers every method of importing Google Fonts in CSS — from the absolute basics to production-ready optimization — so you can add beautiful typography to your site without hurting the experience of the people using it.
Table of Contents
- Method 1: The HTML Link Tag (Recommended)
- Method 2: CSS @import
- Selecting Specific Weights and Styles
- The display=swap Parameter
- Loading Multiple Font Families
- Common Mistakes to Avoid
Method 1: The HTML Link Tag (Recommended)
The HTML <link> tag is the preferred method for loading Google Fonts. It should be placed in the <head> section of your HTML document, before any stylesheets that use the font. When placed correctly, the browser can begin downloading the font file as early as possible during page parsing — reducing the delay before text renders with the correct typeface.
The basic structure uses three elements: a preconnect hint for the Google Fonts API server, a preconnect hint for the static files server, and the actual stylesheet link:
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Inter:wght@400;600;700&display=swap" rel="stylesheet">
The two preconnect hints are not strictly required, but they meaningfully reduce loading time. Without them, the browser must complete a full DNS lookup, TCP connection, and TLS handshake with Google's servers before it can begin downloading the font CSS file. These steps typically add 200–500ms on average internet connections. The preconnect hints tell the browser to start these connection steps immediately when the page begins loading, so by the time the <link> tag is encountered, the connection is already established.
Notice that the second preconnect (fonts.gstatic.com) includes the crossorigin attribute. This is required because fonts are loaded from a different domain than your page, and the crossorigin attribute is necessary for the browser to apply the preconnected session to the font download correctly. Omitting it causes the browser to open a new connection for the font files despite the preconnect.
After adding the <link> tag, reference the font in your CSS using its exact name in the font-family property, followed by a generic family as a fallback:
body {
font-family: 'Inter', sans-serif;
}
h1, h2, h3 {
font-family: 'Inter', sans-serif;
font-weight: 700;
}
The generic fallback (sans-serif, serif, monospace) is displayed while the web font loads and serves as a permanent fallback if the font fails to load entirely.
Method 2: CSS @import
The CSS @font-face and @import directives provide an alternative way to load Google Fonts entirely from within your stylesheet, without modifying HTML:
@import url('https://fonts.googleapis.com/css2?family=Roboto:wght@400;500;700&display=swap');
body {
font-family: 'Roboto', sans-serif;
}
The @import method is convenient because it keeps font loading inside CSS files, which is especially useful in component-based CSS architectures or CSS Modules where you want all typography dependencies declared alongside the styles that use them. It also works in CSS files that are loaded dynamically or conditionally.
The significant disadvantage of @import is performance. When the browser encounters an @import rule, it must first download and parse the containing CSS file before it can discover the font import. This creates a render-blocking chain: HTML download → CSS download and parse → Google Fonts CSS download → font file download. Each step waits for the previous one to complete. With the <link> method, the font request begins as soon as the HTML is parsed, skipping one level of the dependency chain.
For production sites where performance matters, the <link> tag in HTML is almost always the better choice. The @import approach is reasonable for development environments, prototypes, and low-traffic sites where the performance difference is acceptable.
One specific case where @import remains useful: if you're using a CSS-only component system like a CSS framework that has no access to the HTML <head>, embedding the import inside the CSS file is often the only option.
Selecting Specific Weights and Styles
The Google Fonts API accepts precise specifications for which weights and styles you need. This is one of the most important optimizations available — loading only the weights you actually use can reduce font payload by 50–80% compared to loading the full family.
Weights are specified in the URL using the wght parameter with colon separation after the family name:
family=Inter:wght@400;700
The numbers correspond to CSS font-weight values: 100 (Thin), 200 (ExtraLight), 300 (Light), 400 (Regular), 500 (Medium), 600 (SemiBold), 700 (Bold), 800 (ExtraBold), 900 (Black). Not every font has every weight available — Google Fonts will return the closest available weight if an exact match doesn't exist for that family.
For italic styles, combine the ital and wght axes:
<!-- Only italic at 400 weight -->
<link href="https://fonts.googleapis.com/css2?family=Open+Sans:ital,wght@1,400" rel="stylesheet">
<!-- Both normal and italic at 400 and 700 -->
<link href="https://fonts.googleapis.com/css2?family=Open+Sans:ital,wght@0,400;0,700;1,400;1,700" rel="stylesheet">
When specifying multiple axis values, note the specific ordering: the ital value comes first (0 for normal, 1 for italic), followed by the weight value. The values are separated by a comma within the axis value set. This syntax is more complex than the weight-only case, but it's precise about exactly which combinations you need.
For variable fonts, use two dots to specify a continuous range rather than discrete values:
<!-- Inter as a variable font, full weight range -->
<link href="https://fonts.googleapis.com/css2?family=Inter:[email protected]&display=swap" rel="stylesheet">
<!-- Poppins as a variable font, limited range for performance -->
<link href="https://fonts.googleapis.com/css2?family=Poppins:[email protected]&display=swap" rel="stylesheet">
The range notation returns a single variable font file instead of multiple static font files, which can be more efficient when you need many intermediate weight values.
The display=swap Parameter
The display=swap parameter is one of the most important additions to any Google Fonts URL. It maps directly to the CSS font-display descriptor, which controls what happens to text while the web font is loading.
Without display=swap, the default behavior in many browsers is to hide text entirely while the font loads — a phenomenon called Flash of Invisible Text, or FOIT. Depending on network speed and server response time, this can mean users see no text at all for anywhere from a fraction of a second to several seconds. For content-heavy sites, this is a significant usability problem.
With display=swap, the browser renders text immediately using a system fallback font. When the Google Font finishes loading, the browser swaps the text to the correct font. This approach — sometimes called Flash of Unstyled Text, or FOUT — is almost always preferable to FOIT because users can read content immediately, even if the final typography isn't in place yet:
<!-- Without display=swap: potentially blocks text rendering -->
<link href="https://fonts.googleapis.com/css2?family=Roboto:wght@400;700" rel="stylesheet">
<!-- With display=swap: text immediately visible, font swaps when ready -->
<link href="https://fonts.googleapis.com/css2?family=Roboto:wght@400;700&display=swap" rel="stylesheet">
The swap strategy has one trade-off: the layout shift that occurs when text reflows from the fallback font to the web font. Fallback system fonts often have different metrics (line height, character width, x-height) than the web font, causing text to reflow and shift page elements when the swap occurs. This contributes to Cumulative Layout Shift (CLS), one of Google's Core Web Vitals metrics.
To minimize this layout shift, use the CSS size-adjust, ascent-override, descent-override, and line-gap-override descriptors to make your fallback font metrics match your web font as closely as possible. The @font-face rule can apply these to a local system font:
@font-face {
font-family: 'Fallback for Inter';
src: local('Arial');
ascent-override: 90%;
descent-override: 22%;
line-gap-override: 0%;
size-adjust: 107%;
}
body {
font-family: 'Inter', 'Fallback for Inter', sans-serif;
}
This approach, covered in depth in our Google Fonts performance guide, significantly reduces the visual disruption of the font-swap event.
Loading Multiple Font Families
When you need more than one font family — typically one for headings and one for body text — Google Fonts allows you to combine them in a single API request, which is more efficient than making separate requests:
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Playfair+Display:ital,wght@0,700;1,700&family=Inter:wght@400;500;600&display=swap" rel="stylesheet">
The URL structure concatenates families using &family= separators. Each family can have its own weight and style specifications. A single request to the Google Fonts API is always more efficient than separate requests because it reduces the number of DNS lookups and HTTP connections required.
In CSS, reference each family by its exact name:
h1, h2, h3 {
font-family: 'Playfair Display', Georgia, serif;
}
body, p, li {
font-family: 'Inter', system-ui, sans-serif;
}
The order of families in the CSS font-family declaration matters. The browser tries each family in order and falls back to the next if the previous isn't available. Put your preferred web font first, then a similar system font as fallback, then a generic category last.
Common Mistakes to Avoid
Several mistakes consistently affect Google Fonts implementations in production.
Loading too many weights is the most common. Many developers copy the full embed code from the Google Fonts website, which often includes 6–8 weights "just in case." Each weight is a separate file download. Audit your actual CSS and count exactly which font-weight values you use, then request only those. Typically most sites need only 3–4 weights.
Forgetting display=swap causes invisible text during loading. Always append &display=swap to your Google Fonts URL unless you have a specific reason to use a different font-display strategy.
Placing the font <link> after your stylesheet <link> delays font loading. Browsers read HTML sequentially, and a font referenced in a CSS file will only be requested after that CSS is parsed. Place your Google Fonts link before other stylesheets in the <head> to start the font download as early as possible.
Using @import inside a CSS file rather than a <link> in HTML creates an avoidable render-blocking chain. Unless you genuinely need CSS-only font loading, the HTML link approach loads faster.
Not specifying a fallback font in CSS means users with failed font loads get the browser default. Always include a system font fallback and a generic family category in every font-family declaration.
For deeper optimization beyond these basics — including self-hosting, subsetting, and preloading — our Google Fonts developers guide covers the full implementation stack. If you're evaluating whether to use the Google Fonts CDN or self-host, how to self-host Google Fonts walks through the complete self-hosting setup. For the CSS properties that control how web fonts render once they're loaded, the how to use @font-face guide covers the full @font-face specification and all available descriptors.
Typography Terms
Try These Tools
Fonts Mentioned
Designed by Christian Robertson for Google's Material Design ecosystem, this neo-grotesque sans-serif is the most widely used typeface on the web and Android. Its dual-nature design balances mechanical precision with natural reading rhythm, making it equally at home in UI labels and long-form text. The variable font supports width and weight axes alongside Cyrillic, Greek, and extended Latin scripts.
Steve Matteson crafted this humanist sans-serif with upright stress and open apertures that prioritize legibility across screen sizes and resolutions. One of the most-deployed web fonts ever published, it strikes a neutral, professional tone well-suited to body copy, email templates, and web applications. Variable width and weight axes, plus Hebrew and Greek script support, make it a versatile multilingual workhorse.
Rasmus Andersson spent years refining this neo-grotesque specifically for computer screens, optimizing letter spacing, x-height, and stroke contrast for high readability at small sizes on digital displays. An optical size axis (opsz) lets the font automatically adjust its design for captions versus headlines, while the weight axis covers the full range from thin to black. It has become the de facto choice for dashboards, documentation sites, and developer tools worldwide.
Developed by the Indian Type Foundry, this geometric sans-serif pairs perfectly circular bowls and uniform stroke widths with native Devanagari support, making it one of the few typefaces that genuinely integrates Latin and Indic scripts at a design level. The precise, modern letterforms project confidence and approachability, making Poppins a favorite for startup landing pages and app interfaces. Available in 18 styles across 9 weights, it offers practical flexibility without a variable font.