Website Designer in Pune: How to Load Web Fonts Without Slowing Your Site or Shifting Your Layout (Marathi and Hindi Included)

Website Designer in Pune: How to Load Web Fonts Without Slowing Your Site or Shifting Your Layout (Marathi and Hindi Included)

Web fonts slow a site down in two ways: they can delay when your text appears, and they can make the page jump when the real font replaces the temporary one. A website designer in Pune can fix both with a short list of decisions: use fewer font files, serve them as WOFF2, tell the browser what to show while the font loads (font-display), make the fallback font the same size as the real one (size-adjust), and load only the characters each page needs. None of this changes how your brand looks. It changes how it behaves while the page is loading, which is exactly the moment a visitor on a mid-range phone decides whether to stay.

This article is for business owners and marketing managers who have a designed site, or a designer's mock-up, and want to understand what to ask for. It covers how fonts load, the font-display options, layout shift and how to reduce it, Google Fonts versus self-hosting, variable fonts, Devanagari (Marathi and Hindi) fonts, a worked audit and a briefing checklist. Technical facts come from web.dev's font best-practices guide (last updated October 2022) and MDN's CSS documentation, read in October 2026. Browser behaviour changes, so test on the live site. Where I describe general practice rather than a documented rule, I say so. The worked example is hypothetical and no real client is described. This article does not cover payments, shipping or tax.

Why a website designer in Pune should treat fonts as a performance decision

Most people see fonts as a branding choice: a heading typeface, a body typeface, perhaps a third for buttons. For a browser they are also files that must be downloaded before text can be drawn in the intended style. A page can have excellent images and clean code and still feel slow because the headline sits invisible for a second, or because the paragraph beneath it jumps down when the font finally arrives.

Two things are being measured when that happens. The first is how soon the main content appears, which Google reports as Largest Contentful Paint (LCP) in its Core Web Vitals. If your largest element is a headline, a late font can hold up LCP. The second is Cumulative Layout Shift (CLS), which counts unexpected movement of content as the page loads. web.dev's CLS guide treats 0.1 or less as good and anything above 0.25 as poor, measured at the 75th percentile of page loads; check the current page before you put a threshold in a contract, since Google can revise it. A font swap that reflows a paragraph is a classic source of CLS.

Fonts matter more on the kind of audience many Pune businesses serve. A visitor opening your site on a mid-range Android phone over a patchy mobile connection feels every extra file. If the site also carries Marathi or Hindi text, the font files involved are not the small Latin files most performance advice assumes, which we come back to below.

How a browser actually loads a font

Understanding the sequence makes every later recommendation easier.

1. The browser downloads the HTML and then the stylesheet.
2. It reads the @font-face rules, which declare a font family and where its files live. web.dev points out that a @font-face rule alone does not trigger a download. The font is fetched only when some text on the page actually uses it.
3. It builds the page and works out which text needs which font, and only then requests the files.
4. While the file is arriving, the browser has to decide what to do with the text. It can hide the text, show it in a fallback font, or show the fallback and then swap.

That fourth step is where the user-visible problems arise. web.dev notes that Chromium and Firefox hide text for up to three seconds when a web font has not loaded, and that Safari can hide it indefinitely. Three seconds of missing headline is a long time on any page.

The practical consequence is that fonts are discovered late. They are found only after the HTML and CSS have been read, so every technique below either helps the browser find the files sooner, makes the files smaller, or controls what the visitor sees in the gap.

The font-display options, in plain English

font-display is a descriptor you set inside @font-face. It tells the browser what to do while the font loads. web.dev describes the block and swap periods for each value:

web.dev's own guidance on which to choose is useful to quote directly in a brief. For performance, it suggests optional, which limits any delay of text to roughly 100 milliseconds and avoids swap-related shifts, with the trade-off that the web font may not appear on a slow first visit. To show text quickly while still using the web font, it suggests swap, provided the font is delivered early enough to avoid a visible jump. To insist on the web font, block. It also suggests combining them: swap for distinctive brand elements and optional for body text.

For most business sites, a sensible default is swap for the headline font and optional or swap for body text, then check the result on a throttled mobile connection. If a designer says the brand cannot tolerate a fallback font appearing even briefly, that is a legitimate preference, but it should be a decision made knowingly, with the cost stated. The cost is a blank headline on slow connections.

Reducing layout shift when the font swaps

Even with swap, you can make the swap far less noticeable. The idea is to make the fallback font occupy nearly the same space as the web font, so the text barely moves when the real font arrives.

MDN documents size-adjust, an @font-face descriptor that scales a font's glyphs and metrics by a percentage; its initial value is 100%. Its stated purpose is to help match a fallback font's size to a web font rendered at the same font-size. MDN marks it as widely available across browsers since September 2023. Related descriptors named in the CSS Fonts specification, ascent-override, descent-override and line-gap-override, adjust line-box height; check MDN's pages for each before relying on them.

In practice a developer creates a second @font-face rule that points to a locally installed system font (for example Arial) and applies size-adjust and the override descriptors so that it sits in the same space as your brand font. The font stack then lists the web font first, the adjusted fallback second and a generic family last. Tools exist that compute the numbers from the font files; I have not verified any particular tool's current state, so ask your developer which they use and why.

The outcome you want is measurable: run the page through a lab tool such as Lighthouse, or look at CLS in Chrome's performance panel, with and without the adjusted fallback. If the shift disappears or falls substantially, the work paid for itself.

A caution from web.dev: icon fonts cause more significant layout shifts than text fonts, because their fallback characters look different and may even convey a different meaning. Where possible, icons should be inline SVG instead.

Fewer fonts, fewer files

The cheapest font is the one you never load. Before tuning anything, count what the page requests.

A common pattern on small business sites: a heading family in three weights, a body family in four weights, plus italics, plus an icon font. That can be ten or more files, many of which are used once. A tidy rule for a designer:

• One or two families. A heading family and a body family is plenty. Often one family does both jobs.
• Two or three weights each. Regular and bold cover most needs; a medium or semibold can be a third. If a weight appears in only one place, drop it and use another.
• System fonts where brand allows. web.dev points out that font-family: system-ui uses the font already installed on the visitor's device, so there is nothing to download. For dashboards, admin screens and some body copy this is entirely acceptable.

A useful exercise is a font inventory: list every family, weight and style the live site requests, then mark which ones are visible on the page the visitor sees first. Anything not visible on that page can often load later or not at all.

Use WOFF2, and subset what you can

web.dev recommends the WOFF2 format, noting that it uses Brotli compression and compresses about 30% better than WOFF; it quotes the 2022 Web Almanac advice to use only WOFF2. All current mainstream browsers support it, so older formats such as TTF, EOT or plain WOFF add weight without benefit for most sites. If a designer hands over only TTF or OTF files, a developer should convert them to WOFF2 before the site goes live. Check the licence first: some font licences restrict conversion, embedding or self-hosting, and web.dev specifically advises checking before subsetting.

Subsetting means removing characters you do not need. web.dev notes that a typical Latin font holds about 100 to 1,000 glyphs, while some scripts, such as CJK, run beyond 10,000. The unicode-range descriptor lets you split a font into pieces so the browser downloads only the pieces a page needs. Google Fonts does this for you on its CSS API, serving separate files per script; a self-hosted setup needs a developer to do it, with tools such as subfont or glyphanger, both named in web.dev's guidance.

Google Fonts or self-hosting?

This is the question designers and developers argue about most, and the honest answer is: measure on your site.

Third-party hosting (for example Google Fonts). The advantage is convenience and automatic format and subset selection. The cost is extra connections: the browser must contact one domain for the stylesheet and another for the font files. web.dev advises adding a preconnect hint for the stylesheet origin and a separate one, with crossorigin, for the font file origin; for Google Fonts those are fonts.googleapis.com and fonts.gstatic.com.

Self-hosting. Serving the font files from your own domain removes the extra connections and lets you control caching, subsetting and font-display. But web.dev is careful here: it says self-hosting clearly helps only if you use a CDN and HTTP/2, and advises measuring transfer time, including connection setup, before switching. A self-hosted font served from a slow shared host can be slower than Google's edge network.

Privacy and consent. Loading fonts from a third party sends the visitor's IP address to that provider. Whether that matters for your site is a legal and policy question, particularly if you are working through your Digital Personal Data Protection duties; our article on DPDP Act website compliance covers the wider picture. This is a question for your lawyer, and self-hosting removes it entirely.

A reasonable default for a Pune business site on decent hosting behind a CDN: self-host WOFF2 files, subset where it is easy, preload only the one or two files used above the fold, and keep everything else lazy. If you are on cheap shared hosting without a CDN, test both ways.

Preload with care

A preload hint tells the browser to fetch a file early rather than waiting to discover it. web.dev calls preloading effective for late-discovered fonts, but warns that it takes bandwidth from other resources and ignores unicode-range, so it is best used for a single font format. It also recommends fixing the root cause first, for example by inlining the @font-face rules and critical CSS in the <head> so the browser finds the fonts sooner, before reaching for preload. Do not inline the font files themselves.

The rule of thumb: preload the one or two files that draw the headline on your most important pages, never the whole set. If you preload five weights and the visitor sees two, you have made the page slower.

Variable fonts: useful, not magic

A variable font holds a range of weights, and sometimes widths or slants, inside one file. web.dev notes that variable fonts can replace several static files but are larger than any single static file, so they pay off mainly for sites that use many styles and weights.

For a business site using regular, medium and bold of one family, three small static WOFF2 files may be lighter than one variable file. For a design system with five or six weights and fine typographic control, the variable file often wins. As with most things here, the answer is to test both and compare the total bytes and the visible result.

Marathi and Hindi: Devanagari fonts need extra care

If your site serves Maharashtra, Marathi and Hindi text is not optional decoration; it is the content. Devanagari fonts differ from Latin fonts in ways that affect performance and design:

• They can be heavier. Devanagari includes conjuncts and combining marks, so a complete font carries a lot more shapes than a basic Latin font. I do not quote a typical file size, because it varies widely by family; check the actual WOFF2 size in your network panel.
• Fallbacks look very different. A fallback Devanagari font on a visitor's phone may have a different height and line spacing, so the layout shift when the web font arrives can be larger than with Latin text. That makes size-adjust and line-height settings more important, not less.
• Line height needs room. Marks above and below the line need more vertical space than Latin text. A body line-height that looks fine in English can clip or crowd Marathi text.

Several well-known families cover Devanagari, including Noto Sans Devanagari and the Ek Type families Hind and Mukta, among others; check each font's licence and current Google Fonts listing before choosing. A good practice, which our article on building a Marathi and Hindi online store discusses from the ecommerce side, is to load the Devanagari font only on pages that contain Devanagari text. With unicode-range or per-language stylesheets, an English page does not pay for a script it does not show.

Always review the Marathi and Hindi pages on a real mid-range phone, not only in a desktop browser. Text that is crisp on a laptop can look cramped or broken at small sizes.

A worked audit (hypothetical)

Imagine a Pune clinic's website, a WordPress site with a bilingual home page. These numbers are illustrative; they are not from a real client.

What the designer found on inspection:

• Two families from Google Fonts, one for headings and one for body, plus a Devanagari family.
• Eleven font files requested on the home page, including weights used nowhere on the page.
• An icon font for six small icons.
• font-display left at the default in a theme stylesheet.
• No fallback adjustment.
• The Devanagari font loaded on English-only inner pages too.

What the fixes looked like:

1. Reduced to two families by letting one do both jobs; dropped four unused weights.
2. Replaced the icon font with inline SVG.
3. Self-hosted WOFF2 files behind the site's CDN, after a test showing no slowdown.
4. Set swap for the heading and optional for body text.
5. Added an adjusted local fallback with size-adjust for the main Latin font and checked the Devanagari fallback by eye on two phones.
6. Preloaded the heading font only, on the home page.
7. Loaded the Devanagari file only on pages that contain Marathi or Hindi text.

How it was verified: Lighthouse and Chrome's performance panel on a throttled mobile profile, before and after, comparing LCP, CLS and the number and size of font requests. I am not stating results, because they would be invented; the point is that each change has a measurement beside it.

What to ask your website designer in Pune

Use this list in a brief or a review call.

1. How many font files does the home page load, and which are visible above the fold?
2. Are all files WOFF2, and have they been subset where possible?
3. What font-display value is used for each font, and why?
4. Is there a fallback font adjusted with size-adjust, and was CLS measured before and after?
5. Is the font served from our own domain behind a CDN, or from a third party, and was the choice measured?
6. Which font files are preloaded, and why only those?
7. How are Marathi and Hindi fonts loaded, and have they been checked on real phones?
8. Are icons SVG or an icon font?
9. Who holds the font licences, and do they allow web use and self-hosting?
10. Can we see LCP and CLS field data from Search Console or a real-user tool after launch, not only lab scores?

A designer who can answer these with specifics is thinking about performance. One who answers with "it's a standard theme" may not have checked.

Working with Govindani Infotech

Govindani Infotech is a web design and development company at 2nd Floor, Landmark Plaza, 206 Satara Road, Parvati Paytha, Pune 411009. If your current site feels slow or jumpy and you suspect fonts, we can review which files the site loads, how they are served and what the typography is costing in real-world speed, then tell you plainly what to change.

For a new build, our website creation service is where typography, performance budgets and bilingual layouts are agreed at the design stage rather than patched afterwards. If search visibility is the concern, our SEO service page explains how page speed fits alongside content and technical work. Related reading: the guide to fixing slow images with WebP, AVIF and LCP and the article on accessibility and Core Web Vitals for a Pune designer. To talk it over, use the contact page or message us on WhatsApp.

Frequently Asked Questions

Which font-display value should I use for my website?

There is no single right answer. web.dev suggests optional when performance matters most, since it limits text delay to about 100 milliseconds and avoids swap-related shifts, and swap when you want text to show quickly while still using the web font. A common split is swap for headline and brand text and optional or swap for body text, then testing on a slow mobile connection.

Is self-hosting fonts faster than Google Fonts?

Not always. web.dev says self-hosting clearly helps only if you use a CDN and HTTP/2, and advises measuring the transfer time, including connection setup, before switching. On good hosting behind a CDN self-hosting is usually a safe choice; on basic shared hosting, test both.

Do web fonts really affect Core Web Vitals?

Yes, in two ways. A late font can delay the text that is your largest element, which affects LCP, and a swap that reflows content adds to CLS. The size of the effect depends on the page, the number of font files and the connection, so measure your own pages.

What is size-adjust and do I need it?

size-adjust is a CSS descriptor that scales a font's glyphs and metrics by a percentage. MDN says it helps a fallback font match the size of a web font, which reduces the jump when the web font arrives. If your site uses swap and you see layout shift at load, it is worth having your developer add it.

Are Marathi and Hindi fonts slower to load?

They can be, because a Devanagari font carries more shapes than a basic Latin one, and a mismatched fallback can cause bigger shifts. Check the real file size in your browser's network panel, load the font only on pages that contain Marathi or Hindi text, and test on real phones.

Sources:

• https://web.dev/articles/font-best-practices
• https://web.dev/articles/cls
• https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/size-adjust