Overview

Prevent slow fonts from blocking readable text.

Font Performance (font-display, preload) is about user experience under real-world limits. Fast pages prioritize important work, avoid unnecessary bytes, and measure changes instead of guessing.

Core Ideas

• Measure Font Performance (font-display, preload) with a repeatable baseline before changing code.
• Optimize the resource or task that users feel first.
• Avoid moving work around if it does not improve a real metric.
• Keep budgets visible so regressions are caught early.

Step by Step

1. Record the current Font Performance (font-display, preload) metric or resource size.
2. Make one optimization at a time so the result is attributable.
3. Retest with throttling and compare the before/after numbers.
4. Keep the change only if the metric improves without hurting usability.

Beginner Explanation

Font Performance (font-display, preload) helps text appear quickly while still using custom typography.

Fonts can block readable text, shift layout, or download more weights than the page really needs.

Beginners should limit font families and weights, preload only critical fonts, use font-display, and keep fallback fonts close in size.

Before You Start

• Before practicing Font Performance (font-display, preload), choose one page and one user task to measure.
• Record the current result before changing code so you have a baseline.
• Open the Network and Performance panels and reload with cache disabled once, then reload with cache enabled once.
• Note the largest resources, longest tasks, render-blocking files, layout shifts, and slow requests.
• Change only one performance variable at a time so the before and after result makes sense.

Key Performance Concepts

• font-display controls whether text waits for the custom font.
• Preload only the font files needed for first render.
• Subsetting removes unused glyphs when the site supports a limited character range.
• Fallback font metrics affect layout shift when the custom font swaps in.

Plain-English Glossary

• LCP: Largest Contentful Paint, usually the moment the main visible content appears.
• INP: Interaction to Next Paint, a measure of how responsive the page feels after interactions.
• CLS: Cumulative Layout Shift, a measure of unexpected visual movement.
• Render-blocking: a file or task that delays the browser from painting useful content.
• Main thread: the browser thread that runs JavaScript, style, layout, painting, and many user interactions.
• Long task: main-thread work that takes long enough to delay interaction or rendering.
• Waterfall: the Network panel timing view that shows request order, waiting, transfer, and blocking.
• Cache hit: a resource loaded from browser or intermediary cache instead of downloaded again.

What You Will Learn

• Explain which user-visible delay or instability Font Performance (font-display, preload) improves.
• Read a Network or Performance trace and point to the likely bottleneck.
• Apply one small optimization in the editor or a real page and compare before and after.
• Avoid fixes that improve one metric while making accessibility, reliability, or maintainability worse.

Where You Use This in Real Projects

You use Font Performance (font-display, preload) on home pages, article pages, product pages, dashboards, admin tools, checkout flows, search pages, media pages, and any page with images, fonts, scripts, API data, or third-party tags.

Performance work is especially important on mobile devices, slower CPUs, weak networks, high-latency connections, and pages with many scripts or images.

In real projects, the best workflow is baseline, hypothesis, focused change, retest, document the result, and add a budget or regression check.

Browser and Measurement Notes

• Local fast machines can hide problems that appear on mobile phones and slower networks.
• Disable cache for first-load debugging, then enable cache to understand repeat visits.
• Run tests multiple times because network and CPU noise can change single-run numbers.
• Use lab tools for debugging and real user data for production priority decisions.
• Measure the same page state each time, such as logged out, logged in, empty data, or full dashboard.

Code Example

<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter.woff2") format("woff2");
  font-display: swap;
}

Another Example

<link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin>

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-var.woff2") format("woff2");
  font-display: swap;
}

More Practice Examples

Example 1: Measure one interaction

const button = document.querySelector('#measureButton');
const output = document.querySelector('#metricOutput');

button?.addEventListener('click', () => {
  performance.mark('interaction-start');

  requestAnimationFrame(() => {
    performance.mark('interaction-painted');
    performance.measure('button interaction', 'interaction-start', 'interaction-painted');
    const measure = performance.getEntriesByName('button interaction').at(-1);
    output.textContent = `${measure.duration.toFixed(2)} ms`;
  });
});

• performance.mark creates named timestamps in the browser.
• requestAnimationFrame waits until the browser is ready to paint.
• Measuring one interaction is easier to understand than measuring the whole app at once.

Example 2: Reserve space for media

<img src="/lesson-card.webp"
     width="640"
     height="360"
     alt="Lesson card preview"
     loading="lazy"
     decoding="async">

• width and height let the browser reserve space before the image loads.
• loading="lazy" is useful for images below the first viewport.
• decoding="async" lets image decoding avoid blocking other rendering work.

Example 3: Keep noncritical code out of the first load

const loadChartButton = document.querySelector('#loadChart');

loadChartButton?.addEventListener('click', async () => {
  const module = await import('./chart.js');
  module.renderChart();
});

• The chart code is not downloaded until the user asks for it.
• Dynamic import is useful for heavy features below the first task.
• Do not split tiny code so much that extra requests become the new problem.

Example Explained

• The Font Performance (font-display, preload) example focuses on one measurable performance problem instead of trying to optimize everything at once.
• The code either reduces bytes, prevents blocking work, reserves layout space, improves cache reuse, or measures a user-visible metric.
• The important part is the before and after comparison, because performance work without measurement can become guesswork.
• A good fix should improve the target metric without hurting accessibility, content quality, analytics needs, or long-term maintainability.

How to Read This Example

1. Identify what the example is improving: load time, response time, layout stability, transfer size, or perceived waiting.
2. Find the resource, metric, or browser API being used.
3. Predict what should improve before running the code.
4. Run the example, record the result, then change one value and compare again.
5. Connect the result back to Font Performance (font-display, preload) by explaining what the user would notice.

Checklist

• Measure before and after every optimization.
• Optimize the largest and most blocking resources first.
• Test on a throttled network and a slower CPU profile.

Common Mistakes

• Optimizing without a baseline measurement.
• Loading important resources late while loading noncritical resources early.
• Improving lab scores while ignoring real device behavior.

Do and Don't

• Do: measure Font Performance (font-display, preload) before and after changing code.
• Do: optimize the biggest user-visible bottleneck first.
• Do: keep image sizes, script cost, font loading, cache headers, and layout stability visible during review.
• Don't: chase a perfect score while breaking accessibility, content, analytics, or maintainability.
• Don't: preload, lazy-load, split, or cache everything blindly. Each technique has tradeoffs.

Practice Challenge

Apply the Font Performance (font-display, preload) idea to one real page, record a before number, make one change, and record the after number.

Try These Changes

• Change one image size or loading attribute and explain how it could affect LCP or CLS.
• Add one artificial long task in the editor, then remove it and compare the measured interaction time.
• Move one noncritical feature behind a button click or idle callback.
• Add a simple budget for scripts, images, or total requests.
• Write a short note explaining what metric improved and what tradeoff you accepted.

Quick Check

• Question: What should you do before optimizing? Answer: Record a baseline measurement.
• Question: Which metric tracks the main content appearing? Answer: LCP.
• Question: Which metric tracks unexpected visual movement? Answer: CLS.
• Question: Why can too much JavaScript hurt performance? Answer: It can block parsing, rendering, and interaction on the main thread.
• Question: Why are budgets useful? Answer: They prevent gradual regressions as the site grows.

Debugging Checks

• Use the Network panel to find large files, slow requests, blocked requests, and cache misses.
• Use the Performance panel to find long tasks, layout shifts, expensive rendering, and delayed interactions.
• Check whether images have correct dimensions, responsive sources, and suitable loading behavior.
• Check whether scripts can be deferred, split, removed, or run after the first task.
• Retest with throttling and repeat runs so one lucky result does not hide the real issue.

Mini Project

Build a font loading demo for Font Performance (font-display, preload): one custom font, one fallback stack, font-display, optional preload, and notes about layout shift.

Mastery Check

• You can say which metric Font Performance (font-display, preload) improves and how you measured it.
• You can explain the tradeoff of the optimization.
• You can add a budget or regression check for the same issue.