Why BrokerFold pages ship almost zero JavaScript

Most real estate websites are built as JavaScript applications: the browser downloads a large bundle, executes it, fetches data, and finally draws a page. BrokerFold tenant sites are built the other way around — pages arrive as finished HTML, and JavaScript is shipped only to the specific components that genuinely need it. This post explains that decision, because it is invisible in a feature list and decisive in how a site feels.

A listing page is a document

Strip the industry habits away and ask what a listing page is: an address, a price, photos, facts, a map, a contact path. That is a document. Documents do not need an application runtime to display — they need well-formed HTML and properly sized images. So our pages render on the server, at the edge, close to the visitor, and the browser’s first job is simply to paint. The buyer on a phone in a parking lot outside the showing — the single most valuable visitor a listing page ever has — gets content on screen without first funding a bundle download on cellular.

Islands, not oceans

Interactivity is real on a listings site: the map moves, carousels swipe, favourites persist, chat opens. The architecture question is scope. In the application model, interactivity anywhere means JavaScript everywhere. In ours, each interactive component is an island — the map is one, a gallery is another — hydrated independently on top of the static page. The header, the listing facts, the neighbourhood copy, the footer ship no script at all. A visitor who never touches the map never pays for the map.

The budget is a failing test

Performance regressions arrive one small dependency at a time, so good intentions do not survive roadmaps. Ours is not an intention: a JavaScript budget check runs against every proposed change to the codebase, and any page whose script weight exceeds its recorded ceiling is rejected automatically before it can ship. Raising a budget is a deliberate, reviewed act. This is the same enforcement philosophy we apply to compliance rules — a standard that is not machine-checked is a hope, not a standard.

Speed is also a search strategy

Fast pages compound beyond user experience. Search engines crawl server-rendered HTML without executing an application first, which means listing pages, neighbourhood pages, and market pages are fully legible to crawlers by default — the foundation our IDX pages and SEO work builds on. Page experience feeds ranking; more importantly, slow sites bleed visitors before any ranking matters. Scale sharpens the point: an agent site carrying thousands of listing and neighbourhood URLs lives or dies by how cheaply a crawler can traverse them. Static HTML that renders in one request gets crawled deeply and often; an application that must boot before its content exists gets sampled. When most of your pages are listings, crawl efficiency is not an optimization — it is whether your inventory is in the index at all. In our view of what makes a good realtor website, speed is not a feature on the list — it is the floor the list stands on.

No numbers, on purpose

You may notice this post quotes no lab scores. Synthetic benchmarks are easy to cherry-pick and impossible for you to audit, so we would rather assign homework: open any template demo on your own phone, on a cellular connection, and browse the listings. Then run the same test on the sites you are comparing us against. The architecture above either shows up in that test or it does not — which is exactly how claims about speed should be settled.