I like what @font-face makes possible, but I also think it is easy to use badly.
For years, web typography was limited by what people already had installed on their machines. That made designs predictable, but it also made them visually repetitive. @font-face changes that by allowing fonts to be loaded as part of the website. The temptation is to see that as unlimited typographic freedom. I think it needs a little more care than that.
A font is not just a visual decision. It affects loading, readability, browser behaviour and maintenance. If the site becomes harder to read or slower to load because I wanted a nicer heading style, then the decision probably needs another look.
Start With The Reading Experience
The first question I ask is where the font will actually be used. A display font for headings is one thing. A decorative font used for long paragraphs is another. The browser may be able to load it, but that does not mean the visitor will enjoy reading it. Typography still has to serve the content.
For body copy, I tend to be more conservative. The font needs to be readable at smaller sizes, behave well across different browsers and not create awkward spacing once it is rendered. A font that looks good in a large design mockup can feel less convincing when it is used for hundreds of words on a real page.
Headings give more room for character, but even there I want restraint. If every heading, button and navigation item uses a distinctive web font, the site can quickly start to feel noisy. A good font choice should support the design rather than become the whole design.
Write The Font Stack Properly
A web font should always have sensible fallbacks. The browser may not load the file immediately. The font file may fail. The visitor may be using a browser with different support. In any of those cases, the site still needs to remain readable and visually stable enough to use.
@font-face {
font-family: 'SiteHeading';
src: url('/fonts/site-heading.woff') format('woff');
font-weight: normal;
font-style: normal;
}
h1, h2 {
font-family: 'SiteHeading', Georgia, serif;
}The fallback should not be chosen randomly. If the intended font is a serif face, the fallback should probably be a serif font. If the intended font is narrow or tall, I want to know how the fallback affects line breaks and spacing. A poor fallback can make the page jump or feel unfinished before the font has loaded.
Do Not Load More Than The Site Needs
One of the easiest mistakes is loading too many weights and styles. A regular font, bold font, italic font and several display weights may look useful during design, but each file adds weight to the page. If the site only uses one heading weight and one body weight, the font setup should reflect that.
This becomes especially important on sites with photography, JavaScript or other large assets. Fonts are part of the total page cost. They may feel smaller than images, but they still affect the first impression because they can influence when text appears and how the layout settles.
I would rather start with the smallest useful font set and add more only when the design genuinely needs it. That keeps the typography deliberate and makes the site easier to maintain.
Keep It Understandable
The best font setup is one I can understand when I return to the project later. Font files should live somewhere predictable, names should make sense and the CSS should not contain several unused families copied from earlier experiments. That sounds obvious, but type experiments can leave messy code behind if they are not cleaned up.
This is one of those areas where design exploration and production code need to be separated. It is fine to test several fonts during the design process. It is not fine to ship all of them because nobody removed the ones that were rejected.
Used carefully, @font-face is a real improvement. It helps keep text as text, gives designs more character and reduces the need for image-based typography. Used carelessly, it becomes another way to make a site heavier and harder to control.