Как да хоствате шрифтове локално, вместо да използвате Google Fonts

Защо да хоствате Google Fonts самостоятелно?

Google Fonts направи добрата типография лесна. Добавяте stylesheet, избирате няколко тежести и публикувате страницата. В продължение на години това беше разумният стандарт за малки екипи.

Компромисът е, че браузърът на всеки посетител се свързва с услуга на трета страна, за да изтегли CSS за шрифтове и файловете на шрифтовете. Това има две последици.

Първо, добавя външна зависимост към рендирането. Ако CSS за шрифта е бавен, блокиран или недостъпен в региона или мрежата на потребителя, страницата ви чака или преминава към резервен вариант.

Второ, създава въпрос за поверителността. Заявка за шрифт може да разкрие IP адреса на потребителя, user agent, контекста на referrer policy и информация за времето към трета страна. Google Fonts посочва, че не задава cookies чрез Fonts API, но „без cookies“ не е същото като „без лични данни“. По GDPR IP адресът все още може да бъде лични данни в конкретен контекст.

Самостоятелното хостване на шрифтове не е автоматично задължително за всеки уебсайт и това не е правен съвет. Но за европейски сайтове, сайтове от публичния сектор, здравеопазване, образование, финанси или всеки екип, който се опитва да намали ненужните заявки към трети страни, локалното хостване обикновено е по-чистият избор.

То често носи и по-добра производителност, когато е направено добре. Уловката е „направено добре“. Копирането на шест файла с шрифтове в /assets/fonts/ и зареждането им на всяка страница може да е по-лошо от използването на хостваната услуга. Ако искате по-широкия контекст за производителността, предишната ни статия за това защо уеб шрифтовете все още са най-лесната победа за производителността в повечето сайтове разглежда често срещаните модели на разхищение.

Какво се променя, когато хоствате самостоятелно

Когато използвате Google Fonts по обичайния начин, страницата ви прави това:

<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&display=swap" rel="stylesheet">

Браузърът първо заявява CSS от fonts.googleapis.com, след което изтегля файлове с шрифтове от fonts.gstatic.com.

Когато хоствате самостоятелно, страницата ви трябва да заявява както CSS, така и файловете с шрифтове от вашия собствен домейн:

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

Това премахва заявката за шрифт към трета страна. То също така ви прави отговорни за избора на файлови формати, cache headers, резервни шрифтове и актуализации.

Тази отговорност заслужава сериозно отношение. Шрифтовете са част от критичния път на рендиране. Лошата настройка на шрифтовете може да причини невидим текст, размествания на оформлението и бавно първо рендиране.

Стъпка 1: Одитирайте какво наистина използвате

Преди да изтегляте каквото и да било, избройте font families, тежестите, стиловете и наборите от символи, от които сайтът ви действително се нуждае.

Типичен маркетингов сайт може да се нуждае от:

• Regular 400 за основен текст
• Semibold 600 или bold 700 за заглавия и бутони
• Italic 400 само ако дизайнът действително използва курсив
• Само латиница, освен ако сайтът не поддържа повече езици

Подхождайте подозрително към стари стандартни настройки в design system. Много сайтове зареждат 300, 400, 500, 600, 700, italics и множество скриптове, защото някой ги е избрал веднъж в избор на шрифт.

В browser DevTools отворете панела Network, филтрирайте по „font“, презаредете страницата и проверете кои файлове се заявяват. След това прегледайте CSS за използване на font-weight. Ако CSS никога не използва 300, не хоствайте 300.

Ако по-късно преглеждате въздействието, Lighthouse може да помогне, но не приемайте резултата му като цялата история. Използвайте го като диагностичен инструмент, не като съдия. Имаме отделно ръководство за четене на Lighthouse report без паника, което е полезно при приоритизиране на поправки, свързани с шрифтовете.

Стъпка 2: Изтеглете правилните файлове с шрифтове

Google Fonts предлага open-source шрифтове. Можете да ги изтеглите от уебсайта на Google Fonts или от съответното хранилище на проекта за шрифта. Проверете лиценза, но повечето Google Fonts се разпространяват под отворени лицензи като SIL Open Font License или Apache License.

За уеб предпочитайте WOFF2. Той се поддържа широко от съвременните браузъри и обикновено е много по-малък от TTF или OTF. През 2026 г. директното обслужване на TTF към браузъри рядко е оправдано за публични уебсайтове.

Разумна структура на директориите изглежда така:

/public
  /fonts
    inter-latin-400.woff2
    inter-latin-600.woff2
    inter-latin-700.woff2

Използвайте описателни имена на файлове. След шест месеца font.woff2 ще бъде досадно. inter-latin-600.woff2 е скучно и полезно.

Ако сайтът ви използва build system, дръжте изходните шрифтове на ясно място и оставете build pipeline да копира оптимизираните файлове в директорията с публични assets.

Стъпка 3: Създавайте поднабори на шрифтовете, когато е уместно

Subsetting означава премахване на символи, от които не се нуждаете. Пълен шрифт може да включва латиница, кирилица, гръцки, виетнамски, символи и много OpenType функции. Ако вашата English-only landing page се нуждае само от латински символи, поднаборът може да бъде драматично по-малък.

Има два често срещани подхода:

1. Използвайте предварително изграден поднабор от доставчика или хранилището на шрифта.
2. Генерирайте собствен поднабор с инструмент за шрифтове като pyftsubset от fonttools.

За много екипи предварително изградените Latin subsets са достатъчни. Персонализираният subsetting е полезен, когато имате много ограничени страници, например единична campaign page с малко текст или product UI с предвидимо покритие на символите.

Бъдете внимателни с многоезични сайтове. Липсващите glyphs водят до смесване на резервни шрифтове, което може да изглежда счупено и да навреди на четимостта. Ако поддържате няколко езика, съпоставяйте поднаборите на шрифтове с езиковите routes, вместо да налагате един малък поднабор навсякъде.

Стъпка 4: Напишете вашите @font-face правила

Минимална локална настройка изглежда така:

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

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

body {
  font-family: "Inter", system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
}

Няколко детайла тук са важни.

Използвайте font-display: swap за повечето content sites. Това казва на браузъра бързо да покаже резервен текст, а след това да го замени с уеб шрифта, когато той пристигне. Така се избягва най-лошата версия на FOIT: flash of invisible text.

Задайте изричен fallback stack. Ако custom font се провали, потребителите пак трябва да получат четим текст. Резервните варианти не са последваща мисъл; те са част от дизайна. Ако трябва да преразгледате размерите, дължината на реда и избора за основен текст, започнете с практично ръководство за четима типография в съвременния уеб.

Съпоставяйте тежестите правилно. Ако CSS иска font-weight: 500, но сте дефинирали само 400 и 700, браузърът може да синтезира междинна тежест. Това не винаги е ужасно, но може да изглежда непоследователно.

Стъпка 5: Премахнете външните заявки към Google Fonts

След като добавите локален CSS за шрифтовете, премахнете старите remote calls от templates.

Търсете:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?..." rel="stylesheet">

Проверете също:

• Theme settings в CMS platforms
• Page-builder typography panels
• Third-party widgets
• Tag managers
• Стари CSS imports като @import url('https://fonts.googleapis.com/...')

Последното е често срещано. CSS @import за шрифтове обикновено е по-лош за производителността, защото забавя откриването. Ако хоствате самостоятелно, дефинирайте шрифтовете директно в основния си CSS или във font CSS file, зареден рано.

Работата по поверителността често се проваля, защото екипите поправят очевидния template, но пропускат scripts, widgets и legacy embeds. Същият модел се среща и при работата със съгласие; нашето ръководство за какво се промени за cookies през 2026 г. е полезно допълнение, ако намалявате по-широко повърхността към трети страни.

Стъпка 6: Задайте cache headers

Файловете с шрифтове са static assets. Те трябва да се кешират агресивно, ако имената им са versioned или content-hashed.

Добър production header е:

Cache-Control: public, max-age=31536000, immutable

Използвайте дълготрайно immutable caching само ако URL се променя, когато файлът се променя. Например:

inter-latin-400.a8f3c2.woff2

или versioned path:

/fonts/v2/inter-latin-400.woff2

Ако презапишете /fonts/inter-latin-400.woff2, без да промените URL, някои потребители може да запазят стария файл за дълго време. Това е приемливо, докато не стане проблем. Versioning избягва проблема.

Също така обслужвайте шрифтовете с правилния MIME type:

Content-Type: font/woff2

Повечето съвременни hosting platforms се справят с това автоматично, но си струва да го проверите.

Стъпка 7: Обмислете preloading само за критичния шрифт

Preloading може да помогне на браузъра да открие важен шрифт по-рано:

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

Използвайте това пестеливо. Preload-вайте основния шрифт за текст above-the-fold, не всяка тежест на шрифта. Прекомерният preloading се конкурира с CSS, изображения и JavaScript.

Дори за same-origin fonts включвайте crossorigin при font preloads. Зареждането на шрифтове използва CORS mode и пропускането му може да причини двойни изтегляния в някои настройки.

Ако не сте сигурни, тествайте. Не копирайте preloads механично само защото checklist го казва.

Стъпка 8: Тествайте поверителността и производителността

Тестването е директно.

Отворете DevTools, презаредете страницата с изключен кеш и филтрирайте панела Network за:

• fonts.googleapis.com
• fonts.gstatic.com
• .woff2
• font

Трябва да виждате файлове с шрифтове, обслужвани от вашия собствен домейн, и никакви заявки към Google Fonts.

След това тествайте със студен кеш и топъл кеш. При първото посещение шрифтовете трябва да се изтеглят веднъж. При следващи посещения те трябва да идват от memory или disk cache в зависимост от браузъра.

Проверете за layout shift, когато шрифтът се смени. Ако заглавията подскачат, metrics на резервния шрифт се различават твърде много от уеб шрифта. Можете да намалите видимото разместване, като изберете по-близък резервен вариант или използвате по-нови CSS font metric overrides като size-adjust, ascent-override, descent-override и line-gap-override. Те са по-напреднали, но полезни за изпипани интерфейси.

Накрая тествайте страниците в private browsing или с включени content blockers. Едно предимство на самостоятелното хостване е, че инструментите за поверителност е по-малко вероятно случайно да блокират типографията ви.

Чести грешки, които да избягвате

Хостване на твърде много тежести

Това е най-честият провал. Две тежести често са достатъчни. Три обикновено са напълно достатъчни. Пет са признак за проблем в design system, освен ако нямате силна причина.

Забравяне на курсивите

Ако съдържанието ви използва истинско подчертаване чрез курсив, заредете истински italic file. Синтетичните курсиви могат да изглеждат зле, особено в дълго editorial content.

Запазване на стария Google CSS link

Това обезсмисля целта. След миграцията нито една заявка за шрифт не трябва да отива към Google, освен ако друг компонент не я инжектира.

Обслужване на шрифтове без дългосрочно кеширане

Самостоятелното хостване ви дава контрол. Използвайте го. Шрифтовете са идеални кандидати за дълъг живот на кеша.

Игнориране на правната и документационната работа

Ако вашата privacy policy преди е споменавала Google Fonts или зареждане на шрифтове от трети страни, актуализирайте я след миграцията. Ако поддържате data-processing inventory, актуализирайте и него. Техническата промяна и compliance записът трябва да съвпадат.

<!-- tool-cta:start -->

💡 Опитайте това: Преобразувайте TTF файловете, които сте изтеглили от Google Fonts, в WOFF2 за самостоятелно хостване плюс CSS с Webfont Generator.

<!-- tool-cta:end -->

Прост checklist за миграция

1. Избройте font families, тежестите, стиловете и scripts, които действително използвате.
2. Изтеглете WOFF2 файлове и потвърдете лиценза.
3. Създайте поднабори на шрифтовете, ако сайтът има ограничени езикови нужди.
4. Добавете локални @font-face правила с font-display: swap.
5. Премахнете всички Google Fonts link, preconnect и @import references.
6. Обслужвайте шрифтовете от собствения си домейн с дълготрайни cache headers.
7. Preload-вайте само най-важния above-the-fold font, ако тестовете го подкрепят.
8. Проверете в DevTools, че не остават заявки към Google Fonts.
9. Актуализирайте документацията за поверителност, ако е нужно.

Самостоятелното хостване на шрифтове не е бляскава работа. Това е вид малко инфраструктурно почистване, което намалява риска от зависимости, подобрява позицията по отношение на поверителността и ви дава по-предвидимо рендиране. Обикновено си струва часа или двата, които отнема.