Jottings•me

Dashboard →

The Search Index: How Your Content Becomes Searchable

• 7 min read • Guides

One of my favorite features of Jottings is how fast the search is.

You start typing a query in the search box, and results appear instantly. No API calls. No server waiting time. No network latency. The search happens locally in your browser, and it's snappy.

The magic behind this isn't some fancy JavaScript framework. It's actually much simpler: we pre-build the search index when we generate your site.

Let me explain how this works, why I chose this approach, and what it means for your site's performance.

The Search Problem

When most people think about search, they imagine what Google does: a massive distributed database, queries hitting servers in milliseconds, ranking algorithms deciding what's most relevant.

But your personal blog doesn't need that. You have a few hundred jots at most, not billions of web pages. You want search to be instant, not just fast.

Traditional search solutions like Elasticsearch or Algolia solve the wrong problem for you. They're overkill. They add complexity. They add cost. They require API calls, which means network latency.

Instead, we solved it differently.

Pre-Indexing at Build Time

Here's the key insight: your content is static.

When you click "Publish" on a jot, your site rebuilds. HTML gets generated. Files get uploaded to Cloudflare's CDN. The content is locked in place until you publish something new.

Because the content doesn't change between builds, we can do something that would be wasteful for a dynamic site: pre-compute the search index and include it with your site.

When we build your site, we iterate through every single jot. For each jot, we extract:

  • The title
  • The content (plain text version, without HTML markup)
  • The tags
  • The creation date
  • Any metadata (like links in link jots)

All of this gets packed into a compact JSON file—your search index—and uploaded alongside your site.

The file is tiny. Even a jot-prolific author with 1000 published pieces typically has a search index under 100KB.

The Client-Side Search

When someone visits your site and clicks the search box, the browser downloads that pre-built index. It's just one HTTP request, and it happens in parallel with other page resources.

Then, the search runs entirely in JavaScript in the visitor's browser. As they type, a search algorithm (we use a lightweight fuzzy search library) matches their query against the indexed content.

Results appear instantly. No server. No latency. No API limits.

Why This Matters

Let me break down why I chose this approach over other options:

Speed: Network requests are the slowest part of any web interaction. By eliminating them for search, we made search instant. Type a character, see results. It's the difference between "this feels responsive" and "this feels laggy."

Reliability: Your search never goes down because there's no server to go down. Search is as reliable as the static files on the CDN, which have 99.99%+ uptime.

Privacy: The search index is downloaded once and cached locally. We never see what your visitors search for. We never log queries. It's completely private.

Cost: No API calls means no monthly search service bills. The index is just static files served from a CDN. The only cost is the extra few kilobytes on your site, which is negligible.

Scalability: Even if your site gets a million visitors searching simultaneously, there's no load on our infrastructure. Each visitor runs search locally.

Bundle Size Optimization

The obvious question: isn't including the search index going to bloat my site?

Not really. Here's how we keep it lean:

First, we only index published jots. Drafts and unlisted content don't contribute to the search index. That immediately cuts the size in half.

Second, we strip HTML and markdown formatting from the indexed content. We store plain text. That compresses well.

Third, we use efficient JSON compression. The index isn't human-readable—it's optimized for size. For an author with 500 jots, this is typically 50-80KB.

Fourth, the index is gzipped when served by the CDN. That same 50-80KB file becomes about 15-25KB on the wire. Most modern browsers support gzip, so it's transparent.

Last, the index is cached in the browser. On return visits, search is instant without even downloading it again.

Real numbers: A prolific author with 1,000 published jots typically has a search index of ~150KB compressed. That's less than the size of a single high-quality blog image. The performance trade-off is minimal.

Full-Text Search

The search algorithm matches queries against:

  • The full text of every jot
  • Tag names
  • Jot titles

It's not just keyword matching. Our fuzzy search algorithm understands typos (search for "poblish" and it still finds "publish"). It weights title matches higher than content matches. It finds partial matches.

So if you wrote a jot about "static site generation" two years ago and you're looking for it, you can search "static" or "site gen" or even "ssg" and find it.

Updating the Index

Every time you publish or delete a jot, the build system regenerates the search index from scratch. It takes milliseconds. The new index gets uploaded alongside the rebuilt HTML.

Visitors see the updated search results the next time they reload your site (or within the cache period, if their browser has cached the old index).

This is one tiny trade-off of the pre-built approach: search results aren't perfectly real-time. But in practice, the delay is a few seconds to a minute, which is totally acceptable for a personal blog.

Search Index in Action

Here's what a simplified search index looks like (it's actually much more compact):

{
  "jots": [
    {
      "id": "jot-123",
      "title": "Why I Switched to Jottings",
      "content": "I've been blogging for years...",
      "tags": ["blogging", "platforms"],
      "date": "2025-12-01"
    },
    {
      "id": "jot-456",
      "title": "Static Sites Are the Future",
      "content": "Dynamic databases are overrated...",
      "tags": ["web", "static"],
      "date": "2025-11-28"
    }
  ]
}

When someone searches for "static", the search algorithm finds both the second jot's title and any mentions of "static" in other jot content.

What's NOT Searchable

For privacy and performance reasons, we don't index:

  • Draft jots
  • Unlisted jots (if you have that setting)
  • Full metadata (like IP addresses or timestamps)

The search is intentionally limited to content. We don't track what people search for or build profiles based on search behavior.

The Future of Search

As Jottings grows, we might add:

  • Author names (searchable if multiple people write on a site)
  • Filtered search by tag (search within a specific tag)
  • Date-based filtering (show me jots from 2024)

But we'll maintain the core principle: search index pre-built at build time, runs locally in the browser, zero API calls.

This scales elegantly. Even sites with 10,000 jots would have a reasonable index size. And the performance stays snappy because it's all client-side computation.

Try It Yourself

The next time you're in the Jottings dashboard or viewing a published site, try the search box. Type a word from a jot you published months ago.

Notice how fast it is. No loading spinner. No API delay. Just instant results.

That's the difference between a thoughtfully architected feature and a generic solution. We chose an approach that optimizes for your use case: a personal site with hundreds of jots, not billions of documents.

Ready to publish with built-in search? Sign up for Jottings and start building your searchable microblog today. Your content deserves to be found.

← Back to Blog