Meta tags:
description=Our docs platform used to store each entire site as a single monolithic JSON object. Here s why that fell apart, and how we rebuilt storage so a one-page edit only touches the one page.;

Headings (most frequently used words):

the, it, got, our, largest, docs, sites, now, render, 4x, faster, how, used, to, work, problem, with, one, big, object, fix, store, pieces, not, whole, publishing, cheap, reading, fast, making, sure, nobody, noticed, where, landed, what, next,

Text of the page (most frequently used words):
the (70), and (42), site (24), page (20), one (15), docs (14), every (13), our (12), seconds (12), sites (11), #render (11), for (11), content (11), blob (10), now (9), what (9), was (9), pages (9), same (9), new (8), fern (8), pieces (8), cli (7), largest (7), with (7), storage (7), old (7), out (7), customers (6), that (6), path (6), publish (6), small (6), into (6), backend (6), documentation (5), how (5), your (5), time (5), instead (5), before (5), read (5), back (5), slow (5), api (5), single (5), faster (4), first (4), large (4), after (4), where (4), only (4), are (4), got (4), few (4), when (4), like (4), actually (4), routes (4), navigation (4), this (4), per (4), everything (4), pointer (4), never (4), stored (4), whole (4), loads (4), 2026 (3), blog (3), sdks (3), started (3), view (3), markdown (3), also (3), product (3), book (3), demo (3), existing (3), system (3), there (3), next (3), customer (3), changed (3), written (3), but (3), those (3), break (3), they (3), config (3), through (3), had (3), 000 (3), from (3), just (3), section (3), rendering (3), publishing (3), were (3), work (3), between (3), version (3), its (3), hash (3), each (3), edit (3), multi (3), big (3), caching (3), meant (3), object (3), spec (3), company (2), pricing (2), careers (2), resources (2), openapi (2), getting (2), rebuilt (2), soc (2), all (2), beautiful (2), agent (2), july (2), chris (2), broadfoot (2), sandeep (2), dinesh (2), you (2), engineering (2), actual (2), free (2), over (2), merge (2), improvement (2), kept (2), nothing (2), could (2), without (2), changes (2), than (2), valid (2), two (2), can (2), identical (2), redirects (2), description (2), database (2), pipelines (2), rewrite (2), most (2), design (2), result (2), typical (2), cold (2), load (2), times (2), cache (2), changing (2), anything (2), caches (2), doesn (2), touch (2), around (2), short (2), thing (2), straight (2), layers (2), top (2), level (2), sidebar (2), servers (2), problem (2), reach (2), fast (2), once (2), not (2), finish (2), tells (2), looks (2), monolithic (2), postgres (2), addressed (2), blobs (2), url (2), tree (2), request (2), change (2), snapshot (2), writes (2), uploading (2), piece (2), publishes (2), touches (2), made (2), heavier (2), entire (2), being (2), 500 (2), grew (2), json (2), full (2), used (2), use (2), sign (2), dev, located, brooklyn, york, postman, terms, service, privacy, policy, github, brand, kit, support, compatibility, revamping, website, designers, marketing, interest, type, systems, operational, subscribe, delight, developers, idiomatic, wasting, infrastructure, try, coming, months, migrate, onto, retire, paths, switch, automatic, action, needed, downtime, minute, really, payabli, nvidia, numbers, real, tell, story, byte, some, landed, honest, ledger, happened, field, formats, dropped, reason, budget, user, visible, zero, rather, testing, cases, thought, generated, lots, weird, configurations, automatically, since, odd, combinations, exactly, migrations, any, mismatch, found, saved, permanent, test, screenshots, turned, weak, signal, cover, look, while, differing, ways, matter, metadata, auth, differ, often, boring, reasons, fonts, defined, clean, leaving, incidental, details, ids, rule, input, both, should, produce, live, platform, success, invisible, identically, effort, wasn, proving, matched, making, sure, nobody, noticed, saw, average, dropping, killed, longstanding, annoyance, setup, entry, invalidated, scoped, tweak, leaves, alone, editing, body, except, identified, effectively, forever, has, freshness, window, anyone, waits, flips, cached, simply, referenced, again, bust, reads, holding, shell, map, lives, bundle, itself, someone, opens, several, internal, services, dependency, anywhere, blocked, reading, heavy, processing, server, side, purpose, improving, deploy, fixes, upgrade, required, notices, immediately, stops, matters, more, sounds, plenty, whether, touched, milliseconds, doing, pointless, works, quick, forth, figures, hands, upload, spots, missing, then, uploads, file, bytes, pass, cheap, pulled, hit, cascade, def, route, architecture, let, flatten, resolution, walked, nested, own, row, resolving, lookup, walk, identifying, makes, did, trivial, reuse, belongs, shares, else, previous, kilobytes, megabyte, modify, identify, key, realization, hundreds, three, ideas, fix, store, these, problems, compounded, pushed, toward, stale, worst, seeing, repeated, outages, well, past, occasionally, falling, mid, fixing, typo, even, though, already, loading, memory, deserializing, which, enough, outgrew, layer, make, overwrote, last, history, unlocks, ability, diff, rollbacks, becomes, unit, part, dragging, rest, along, data, loaded, serve, varied, minutes, 150, sections, versions, 600, reference, schemas, endpoints, reasonable, breaking, kind, scale, run, today, example, composed, many, different, including, references, images, long, them, lived, compressed, overwritten, bigger, organizations, stopped, minor, friction, way, basics, finding, information, shipping, updates, hosts, companies, building, developer, platforms, prospect, forms, impression, figure, giant, rewritten, reloaded, broke, listen, podcast, min, start, get, readiness, score, compliant, secure, trust, center, hiring, learn, interact, terminal, client, libraries, designed, language, experts, customizable, websites, products,

Text of the page (random words):
our largest docs sites now render 6 4x faster fern products resources docs beautiful customizable documentation websites sdks client libraries designed by language experts cli interact with your api from the terminal documentation learn how to use fern careers we re hiring trust center soc 2 compliant and secure get your agent readiness score customers blog pricing sign in start for free book a demo sign in book a demo back to blog view as markdown our largest docs sites now render 6 4x faster july 2 2026 6 min read sandeep dinesh chris broadfoot engineering docs listen as podcast 0 00 0 00 1 tl dr every fern docs site used to be one giant json blob rewritten on every publish and reloaded in full on every page view we broke it into small content addressed pieces so a one page edit only touches one page and the largest sites render 6 4x faster fern hosts documentation for companies building developer platforms docs are where a prospect forms a first impression of the product and where existing customers go to figure out how to actually use it but as our customers grew into bigger organizations slow page loads and publishes stopped being minor friction and started getting in the way of the basics finding information and shipping updates how it used to work a fern docs site is composed of many different pieces including markdown pages api references images config and navigation for a long time all of them lived as a single compressed json blob in our database one object per site that was overwritten on every publish and read back in full to render every page load this was a reasonable design when sites were small but started breaking as sites grew into the kind of multi version multi product scale our largest customers run today for example one of our largest customer s site looks like this 2 000 content pages 50 api versions each with 5 mb openapi spec 500 endpoints per spec 1 500 schemas per spec 600 api reference pages 150 navigation sections the data for 35 000 routes was being loaded to serve a single page cold render times varied between 1 3 minutes we now render the same request in 5 10 seconds the problem with one big object when an entire site is a single object the whole thing becomes the unit of work you can t touch a small part without dragging the rest along fixing a typo on one page meant re uploading the entire site even though 99 9 of it was identical to what was already stored rendering a single page meant loading the whole blob into memory and deserializing it which got slow enough on big sites that it outgrew the caching layer meant to make it fast and every publish overwrote the last one so there was no stored history the new system unlocks the ability to diff and rollbacks these problems compounded big blobs made page loads slow slow loads pushed us toward heavier caching and heavier caching made content go stale at the worst of it we were seeing repeated outages page loads well past 30 seconds and large sites occasionally falling mid render the fix store the pieces not the whole the key realization was that most of a docs site doesn t change between publishes a typical edit touches one or two pages out of hundreds as a result we rebuilt storage around three ideas break the site into small pieces identify each piece by a hash of its content never modify a piece once it s written identifying content by its hash makes did this change trivial same content same hash reuse what s there a site is stored in layers each page the section it belongs to and a top level snapshot so changing one page writes a new page section and snapshot and shares everything else with the previous version a single page edit on a large site now writes a few kilobytes instead of re uploading a multi megabyte blob the same rewrite let us flatten url resolution the old system walked a nested navigation tree at request time now every valid path is written out as its own row at publish time so resolving a url is one lookup instead of a tree walk read path architecture before next js s3 monolithic blob 10 50 mb postgres after next js s3 version blob 5 kb s3 route sidebar blob s3 content api def blob before vs after the old read path pulled a 10 50 mb monolithic blob and hit postgres the new one is a short cascade of small content addressed s3 blobs publishing got cheap publishing a documentation site now works as a quick back and forth between the cli and our backend first the cli tells the backend what the site looks like the backend figures out what s actually new and hands back upload spots for just the missing pieces the cli then uploads those pieces straight to storage so the file bytes never pass through our servers and tells the backend to finish up if nothing changed the backend notices immediately and stops that matters more than it sounds plenty of ci pipelines publish on every merge whether or not the docs were touched and those now finish in milliseconds instead of doing pointless work we kept the heavy processing server side on purpose improving how we break a site into pieces is just a backend deploy so fixes reach every site at once with no cli upgrade required reading got fast when someone opens a docs page our servers render it and rendering had the same whole blob problem as publishing the old read path could reach back through several internal services before rendering anything so a slow dependency anywhere blocked the page the new path is just a few reads straight from storage and they re the same layers the site is stored in a small top level pointer holding the site s shell and a map of where everything lives a bundle with the routes and sidebar for a section of pages and the page content itself everything except that pointer is identified by content and never changes so it caches effectively forever the pointer has a short freshness window of a few seconds and it s the only thing anyone waits on publish the pointer flips over and old cached pieces are simply never referenced again no cache to bust this also killed a longstanding annoyance the old setup had one cache entry per site so changing anything invalidated everything now caches are scoped to what actually changed a config tweak leaves your page content alone and editing a page s body doesn t touch the pages around it the result typical large 5 000 routes sites saw a 5x improvement in average cold load times dropping from 10 seconds to 2 5 seconds making sure nobody noticed a storage rewrite on a live platform is only a success if it s invisible every page on every site had to render identically before and after so most of the actual effort wasn t the storage design it was proving the new path matched the old one screenshots turned out to be a weak signal they cover few pages two pages can look identical while differing in ways that matter redirects metadata auth and when they differ it s often for boring reasons like fonts so instead we defined a clean description of what a site actually is routes pages redirects navigation config leaving out incidental details like database ids the rule same input through both pipelines should produce the same description same site out we also kept an honest ledger of what happened to every field as it changed formats and nothing could be dropped without a written reason the budget for user visible changes was zero and rather than only testing cases we thought of we generated lots of valid but weird site configurations automatically since those odd combinations are exactly what break migrations any mismatch one found got saved as a permanent test where it landed the numbers on real customer sites tell the story time to first byte on some of our largest sites customer before after improvement nvidia 10 6 seconds 2 07 seconds 5 1x merge 3 5 seconds 0 55 seconds 6 4x payabli 14 6 seconds 2 7 seconds 5 4x really large site 1 minute 5 seconds 11 4x what s next over the coming months we ll migrate every existing site onto the new storage system and retire the old storage and render paths for existing customers the switch is automatic there s no action needed and no downtime and if you re wasting engineering time on docs infrastructure instead of your actual product try fern for free or book a demo sandeep dinesh chris broadfoot july 2 2026 delight your developers with beautiful docs idiomatic sdks an agent first cli subscribe all systems operational soc 2 type ii also of interest our largest docs sites now render 6 4x faster how 2 designers and ai rebuilt fern s marketing site revamping our website view as markdown documentation getting started openapi compatibility docs sdks cli resources blog careers customers support pricing company brand kit github privacy policy terms of service 2026 fern a postman company located in brooklyn new york dev