Translated from the original Japanese article
Tech 7 min read

Replaced Geist with Gen Interface JP: jsDelivr CDN, 4 weights, Geist Mono kept

CSS UI デザイン Web
IkesanContents

I had been wanting to swap the body font on lilting.ch.
The current BaseLayout.astro loaded Geist and Geist Mono from Google Fonts, and the body text simply rode on font-sans.
Latin glyphs looked fine, but for a site that’s mostly Japanese reading, things leaned a bit too far toward the Latin side.

Gen Interface JP fit neatly into that gap.
The official site positions it as a Japanese-Latin mixed typeface for “digital interfaces,” aiming for harmony between the two scripts.
Parascope’s Gen Interface JP feature also describes it as a font that combines Inter and Noto Sans JP to align Latin and Japanese rendering on UI surfaces.

Keep an Inter-ish feel while making Japanese readable

What I want for my own site is a body font where Japanese doesn’t suddenly look heavier.
On a Japanese blog, putting a Latin font in front does tighten up code names, product names, and English abbreviations.
On the other hand, the Japanese in body copy falls back to Noto Sans JP, and the tension of the typesetting flips between scripts.

Gen Interface JP mixes that from the start.
The Latin side feels close to Inter, and the Japanese side leans on Noto Sans JP shaped for UI usage.
If the goal is a site where Japanese body copy and product names sit at the same visual density — instead of a “Latin-only handsome site” — it’s a pretty straightforward choice.

In Three resources to dramatically improve Claude Code’s UI output, I touched briefly on font choice when letting AI generate UI.
That article was framed as “avoid Inter, Roboto, Arial, system fonts,” but the blog itself isn’t a place to play with quirky display fonts.
Keeping long Japanese reading comfortable while not letting UI Latin glyphs feel detached matters more.

With 8 weights, applying it site-wide is easy

The weights are Thin, ExtraLight, Light, Regular, Medium, SemiBold, Bold, ExtraBold — eight in total.
Body, dates, tags, card headings, navigation, TOC headings: that’s plenty to differentiate.

For this site, body could stay Regular, card headings and navigation Medium, and article titles SemiBold.
Bold and above stay reserved for emphasis or larger headings.
The current heavy use of font-medium should drop in without breaking layout.

That said, loading every weight indiscriminately makes the web font heavy.
The official site shows a jsDelivr all.css example, but for site-wide use it’s better to limit to weights actually used, or self-host with tuned preload.

<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/gen-interface-jp@0.1.2/all.css">

If I write a follow-up on the actual CSS swap, that’s the meat of it.
Astro’s style scope ties into what I wrote in AI keeps forgetting that Astro’s scoped CSS doesn’t apply to JS-generated elements, but this time it’s the site-wide base font, so the changes belong in BaseLayout.astro and the global CSS.

OFL keeps it easy for ordinary blog use

The license is SIL Open Font License 1.1.
The npm package metadata also lists OFL-1.1.
For loading it as a web font on a blog, that’s quite different from awkward commercial-font contracts.

Parascope’s SUMMARY notes that even when converted to bitmaps for embedded devices, the license carries forward.
This site doesn’t go that far, but I do check “how the font file is being redistributed” whenever taking it outside the web.

v0.1.2 came out after the v0.1.1 introduction

A note just on this.
Parascope’s feature page is dated 2026-05-06, and its SUMMARY references GitHub Releases v0.1.1.
But when I checked on 2026-05-07 JST, the official site’s CSS load was already pointing at gen-interface-jp@0.1.2.
npm latest was also 0.1.2, and GitHub Releases had Gen Interface JP v0.1.2 published.

The v0.1.2 release notes mention bumping ofl-font-baker to 0.3.6 to fix STAT info on static weights.
That’s a quiet detail for a font-pick post, but it ties into how browsers and design tools read weight metadata.
If you’re picking it up now, look at v0.1.2 instead of v0.1.1.

Swapped via CDN directly

I postponed self-hosting and dropped it in via jsDelivr direct, the same flow as the existing Google Fonts load.
Only the body sans switches to Gen Interface JP; the code-block Geist Mono stays.

Trim the font load in BaseLayout.astro to only the weights actually used.

<link rel="preconnect" href="https://cdn.jsdelivr.net" crossorigin />
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/gen-interface-jp@0.1.2/400.css" />
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/gen-interface-jp@0.1.2/500.css" />
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/gen-interface-jp@0.1.2/600.css" />
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/gen-interface-jp@0.1.2/700.css" />
<link href="https://fonts.googleapis.com/css2?family=Geist+Mono&display=swap" rel="stylesheet" />

Skipping all.css is because the full Unicode range plus all weights tips it over 1.6MB.
I narrowed weights to 400 for body plus 500/600/700 matching Tailwind’s font-medium font-semibold font-bold.
Anything I miss later, I can add per-weight.

The --font-sans in globals.css only changes at the head. I dropped the Geist fallback entry but kept the Japanese fallback chain intact.

--font-sans: 'Gen Interface JP', 'Hiragino Kaku Gothic ProN', 'Hiragino Sans', 'Noto Sans JP', sans-serif;

First impression: a touch crisper than I expected.
The glyph edges feel sharper than with Geist, and Latin and Japanese sit at almost the same visual density.
That said, this is just a short look right after the swap, so I’ll cruise around the site for a while before deciding whether the body reading experience is good enough to keep.

Update: Vercel started flagging tons of /w/normal/... 404s

A few hours after the swap, Vercel pinged me about 2,500-plus 404s on paths like /w/normal/600/059.woff2.
Nothing on lilting.ch ever served those paths, so I first suspected a bot scan — but the cause was on my side.

The CSS files served by jsDelivr (e.g. gen-interface-jp@0.1.2/600.css) reference woff2 files with relative URLs.

@font-face {
  font-family: "Gen Interface JP";
  font-weight: 600;
  src: url("./w/normal/600/000.woff2") format("woff2");
  /* ... */
}

Real browsers resolve those relative to the CSS file’s location (jsDelivr), so the actual font is fetched correctly from cdn.jsdelivr.net/npm/gen-interface-jp@0.1.2/w/normal/600/000.woff2.
But crawlers that just regex url(...) out of CSS, or tools with sloppy relative-URL handling, end up resolving url("./w/...") against the page’s origin instead. That sends them to lilting.ch/w/normal/600/000.woff2 — which 404s.

Gen Interface JP slices glyphs into a lot of Unicode-block subsets, so a single CSS file references dozens to nearly 100 woff2 files. With one buggy crawler hitting one page, you can rack up several hundred 404s per visit, which is how the count blew past 2,500 quickly.

No real-user impact, but the alert noise and bandwidth weren’t worth ignoring, so I added a vercel.json redirect that forwards /w/* to the actual jsDelivr path. Bots get the real woff2, no side effect.

{
  "redirects": [
    {
      "source": "/w/:path*",
      "destination": "https://cdn.jsdelivr.net/npm/gen-interface-jp@0.1.2/w/:path*",
      "permanent": false
    }
  ]
}

I kept it as permanent: false (302) so caches don’t lock onto an old version path when I bump the font version.
Self-hosting would eliminate the issue at the source, but it adds hundreds of woff2 files to the repo, so I’m holding off for now.

References