How We Added Fonts to the Craftum Editor

This is a story about solving a design problem by removing unnecessary design complexity.

In short: I cut implementation time by 5x and delivered a more flexible solution.

Background

One of my first tasks at Craftum was adding Google Fonts support to the website builder.

The product manager outlined the context:

1. The editor had only a limited set of default fonts (which were not truly system-safe in all environments).
2. Users had been requesting a larger font library for over a year.
3. Stakeholders were unhappy with delivery speed. The feature had to start in the next sprint (within 2 weeks), while more revenue-critical tasks were already queued.
4. There were legacy mockups from a previous designer, but engineering estimated more than a month to implement them.
5. I was asked to validate both the mockups and the solution approach.

I wanted to understand why adding fonts to a dropdown could take over a month.

Reviewing the existing concept revealed two core issues:

1. The baseline approach copied a competitor and was suboptimal: fonts were connected in website settings, not in the editor where users spend most of their time. It also introduced technical limits (up to 2 fonts globally loaded on all pages), which hurt performance.
2. To avoid direct copying, the proposal introduced full Google Fonts-like browsing via Google Fonts API with filters, previews, and advanced UI. This increased scope and timeline without meaningful practical value.

How I Solved It

I canceled the overdesigned settings UI and reused the existing font dropdown in the editor, adding only font-name search.

I replaced live Google Fonts API integration with a static JSON source and SVG previews. They can be updated manually or by cron when needed. Initially, I considered writing a generator script, but found an open, regularly updated repository with ready-to-use assets.

I proposed storing used fonts in each block's metadata. The list is updated client-side when a block changes and sent to the server on save. In testing, this added negligible overhead: under 30ms even for very large blocks on older hardware.

On publish, the server aggregates metadata across all blocks on the page and builds a single font list to load only what that specific page uses.

Done.

Result

Implementation took 1 week instead of the initially expected 5, which freed up engineering capacity for higher-priority tasks.

The new approach provided flexibility uncommon for most builders: users could apply any Google Font anywhere, on any page, with no practical limit. Unlike many competitors, each page loaded only fonts actually used on that page, improving load performance.