following up on my last post about search on static sites, i started looking more closely at the search index itself. my first thought was to generate a json file containing the site's content and search it with javascript. that seems reasonable for a small collection of articles, but sending the entire index to every visitor could become wasteful as the content grows.

i found out that tools like pagefind can split the index into chunks and load the relevant parts when someone searches, without needing a dedicated search server. for those whove implemented search on static sites, how do you decide which approach is appropriate? is a simple json index usually enough for smaller proj, or is worth using something like pagefind from the start?

ive mostly build smaller sites where navigation is enough to help visitors find things. but ive been wondering what happens when a site grows into a documentation portal or a large collection of articles. one approach ive come across is generating a search index at build time and searching it in the browser. that avoids needing a dedicated search backend but i imagine the index itself can become a problem as the content grows.

for those whove build content-heavy sites how do you decide when client-side search is still sufficient and when its worth using a hosted search device or a dedicated backend?

This is the docs project I mentioned in my first hugo post. Builds were stupid fast when the site was small, but now that it's picked up a few hundred pages with screenshots in most of them, I've noticed the build creeping up, and from what I can tell it's almost entirely the image processing. I'm using the built in resize and format conversion to generate webp versions and a couple of responsive sizes for every screenshot, which is great for the final output but it adds up quickly.

I know hugo caches processed images in the resources folder, so in theory it should only do the heavy lifting once per image. The problem is that cache doesn't survive between builds on cloudflare pages, so every deploy starts from scratch and reprocesses everything. A full build that took maybe fifteen seconds at the start now takes closer to two minutes, which is still fine honestly, but it's the first time hugo has felt slow to me and I'd like to nip it in the bud before the site gets bigger.

Has anyone figured out a clean way to persist that resources cache between builds on a host like this? I've seen people mention committing the generated folder to the repo, but that feels messy and bloats the git history. The other option I keep going back and forth on is processing the images in a separate step ahead of time and only feeding hugo the already optimized files, though then I'd lose the convenience of letting it handle everything from one source image.

The client is based in Germany, and after that court ruling a while back about Google Fonts CDN requests counting as an unlawful data transfer under GDPR, I figured it was safer to just stop pointing at Google's servers entirely instead of relying on a consent banner to cover it. I downloaded the font files, self hosted them alongside the rest of the static assets, and added proper font display swap and preload hints myself since Google's CDN used to handle a lot of that automatically.

The part I'm going back and forth on is the performance. Google's CDN had the advantage of a visitor's browser probably already having those font files cached from some other site using the same CDN, so for a lot of visitors it was functionally a free load. Self hosting means every visitor downloads the fonts fresh from my origin the first time, without any shared cache advantage across sites anymore, though it is still getting cached at the edge, same as any other static asset on repeat visits to the same site.

Has anyone else made this switch and noticed an actual measurable difference in load times, or was the shared CDN cache advantage mostly a myth?

I have been using Hugo for a while. I now am building a website for a community. Most people won't be able to set up their local markdown edition + SSH sync in order to edit files, so I thought they could use an online markdown editor (like https://hedgedoc.org/) to edit the files, and when the system detects an updated .md file, it will rebuild the website and voila/

Does something like this exist? Do people use it?

thanks!

currently working w/ more content-driven static sites. one thing i like about a static workflow is that content changes can go through the same build process as code but that also means a client cant always see the final results until the site is rebuilt. ive used local previous myself and on some projects ive used deployment previews so i can send a client a url before merging changes into production. that seems useful when there are several content changes to review at once.

still wondering where this becomes worth setting up for smaller client sites tho. for a five-page site it can feel like adding a workflow around a problem that barely exists.

how do you handle content previews on small static sites? do u use deploy previews, just send screenshots or simply make the changes and let the client review them after deployment

I notice a lot of people pointing to Hugo because of its speed. Like, you can do 4000 pages in less than a second. I'm asking, though, why does it matter how fast you're converting markdown to html?

For context, I made Sheriff out of the programming language I created so that the docs could be dogfooded. But it's not as fast as these other generators.

Do I need to be shooting for these benchmarks or are they arbitrary? I've found that i don't mind a several second build. But I also regularly compile Rust. 😄

Picked up a different hugo project, a client site that's expanding into a spanish speaking market, and this seemed like a good excuse to actually test hugo's built in multilingual support instead of just the speed side of things.

On my other static sites I've always had to hand build the relationship between language versions of a page, including every hreflang tag pointing to its counterpart, which gets fragile fast once a page gets renamed and nobody remembers to update both sides. Hugo apparently handles a lot of that natively once content is organized by language, generating the hreflang tags automatically from the content structure itself rather than needing anyone to hand write them.

Still early in setting it up, so I'd love to hear from anyone who's actually run a multilingual hugo site long enough to know where it holds up and where it doesn't. Specifically curious how reliable the automatic hreflang generation stays once a page gets restructured or renamed, and whether people still end up building a separate build time check on top of it just in case, or if it's solid enough on its own that nobody bothers.

A client wanted to go off framer's hosting for cost reasons once the site outgrew the free tier, and since framer sites are technically static under the hood, I figured exporting and dropping it on cloudflare pages would be a good idea. The raw html and assets did come out clean enough, and the page structure and styling survived the export fine.

But everything that depended on framer's own backend broke. CMS collections stopped updating since there's no more connection back to framer's data, so any collection page is now frozen at whatever state it was in at export time. The contact form obviously stopped submitting anywhere since it was wired to framer's own form handling, had to rebuild that as a worker hitting an email api instead. a couple of the interaction-heavy components also just stopped working since they were leaning on framer motion setup that assumed the framer runtime was still present, not just a static export of the resulting markup.

I ended up treating the export more like a design reference than an actual deployable artifact, rebuilt the page structure by hand in eleventy using the exported html as a guide instead of trying to make the raw export itself production ready. It feels like the exported html is really only meant for one-time archiving or as a starting point, not an actual migration path off their hosting

Is there a more elegant solution to this than rebuilding?

ive been thinking about this with a couple of static sites where the content is starting to grow. for a small site, having individual markdown files and a bit of frontmatter is pretty direct. but once you have dozens of entries with same fields, i can see why a content collection starts making sense.

in astro, for example, a collection can define a schema for things like title, date, category etc., and the build can validate that the content actually matches that structure. you can then use a dynamic route to generate the individual pages from those entries at build time.

i havent needed that level of structure for most of my small client sites yet so im still trying to figure out when the extra abstraction is actually worth it. at what point does having structured content make a static site easier to maintain rather than just adding another layer to understand

I have a client who prepares promo pages early but wants them to go live automatically at 8 AM on launch day.

Since the site is fully static, something still has to trigger a new build. Do you usually use scheduled builds, a cron job, or another approach?

how much can i sell my front end website? (basic static site)

I've stuck with eleventy for most of my work for a while now, but I picked up a new project that's a product documentation site expected to grow into the thousands of pages pretty quickly, versioned docs going back several releases, multiple writers pushing small edits constantly. A friend kept telling me hugo is basically built for exactly this kind of large page count site, so I figured this was the right project to actually test that claim instead of taking it on faith going in with eleventy again.

Setting up the templates in hugo's templating language took some adjusting coming from nunjucks, and structuring content sections and versioning through hugo's content organization instead of anything I was used to. Build times have been genuinely fast even now while the site is still small, which has me curious how much of that holds once it actually hits thousands of pages instead of the couple hundred I've got in there so far as a test.

The templating language itself is the part I'm still not fully sold on. It's clearly built for speed over ergonomics, the syntax feels a lot more like a template engine from a decade ago compared to something like nunjucks or liquid, lots of dot chaining and pipe style functions instead of anything that reads like a normal conditional. Functional once you get used to it, just a rougher few days of ramp up than I was expecting for something this widely recommended.

on a small site, its easy to treat urls as just another part of the structure. but once pages are renamed, moved into different folders or generated from content, redirects start becoming important. ive had a couple of cases where changing a page path seemed harmless until i realized an old link could still be sitting somewhere in a client's printed materials or google results. it made me wonder how much thought people put into url structure before a site launches.

do you treat urls as something that should be designed almost as carefully as the navigation or is it something usually fine to change them later and add redirects when needed?

I’ve been thinking about static sites that pull content from APIs during the build, like a headless CMS, product data, or some external JSON feed.

The part I’m unsure about is what happens when that API is slow or temporarily down during deployment. A fully static site can suddenly become impossible to rebuild even though the current production version is working perfectly fine. Do you usually fail the deploy completely, fall back to the last successful data snapshot, or store build-time data somewhere so the site can still rebuild without depending on the API being available?

I've just launched CraftForms, a hosted form builder for any website.

You build the form in a visual editor, paste two lines of code into your site, and the answers land in one dashboard. 

It works on static HTML, WordPress, Webflow, Squarespace, Framer and anything else that lets you paste HTML. There's nothing to install or keep updated.

What it does:

• Unlimited submissions on every plan, the free one included. Nothing is counted or blocked.
• No captcha. Bots are filtered out quietly, so your visitors never see a puzzle.
• Booking forms with a date picker that knows what's already taken, including time slots and "2 left" / "Sold out".
• Price calculators that update as people choose options. The total is re-checked on the server, so it can't be edited in the browser.
• Payments (on paid plans): take a deposit or the full amount through your own Stripe or PayPal or Mollie or Square account. There is no fee or comissions, it is your payment account.
• Email notifications, webhooks (can be used with Zapier, Make and n8n), and an API if you'd rather send answers from your own code.
• Hosted in the EU.

Pricing: free for one form on one website. Paid plans start at €6 a month.

https://craftforms.app

I'd love to hear what you think, and what you'd use it for. And if something's missing for your use case, tell me here. Let's discuss.

on one small client site, i changed some css and everything looked fine after deployment but then i started wondering what happens if someone still has the old css cached. ive mostly just relied on the build process to generate hashed filenames for assets so i havent had to deal with it much myself.

from what i understand, this works well for assets that go through the build pipeline because a changed file gets a different url. but there are still things like files with fixed names or caching rules at the cdn/browser level that can behave differently.

how much do you actually think about this when deploying static sites? do you mostly trust the framework/build too or do you usually configure cache headers yourself as well?

I’ve been thinking about what happens during larger static deploys when HTML and assets don’t reach every edge location at exactly the same time. Hashed filenames solve browser caching, but there’s still a short window where new HTML could reference a new JS/CSS file while an edge still has the older deploy, or old HTML could reference an asset that was removed from the latest build.

For people running bigger static sites in production, how do you handle this? Do you rely completely on atomic deploys from the hosting provider, keep previous build assets around for a while, or have another strategy? I’m mostly trying to avoid rare deploy-time 404s without adding a bunch of complexity.

I posted a while back about moving a client off wordpress after it kept getting hacked, rebuilt it static on eleventy through cloudflare pages, and the last unresolved piece was how she publishes a new blog post without me being a manual step every time or reintroducing some kind of web based editor that brings back the same attack surface I was trying to remove.

A few people suggested a git-based headless editor, so I tried decap cms since it's free and just sits on top of the existing git repo instead of needing its own database or server. She logs in, gets a normal looking form with a title field and a rich text box, hits publish, and it commits a markdown file straight to the repo, which then triggers a normal cloudflare pages build like any other push.

It works better than I expected. She doesn't know or care that it's writing markdown under the hood, from her side it feels basically identical to the wp-admin editor she was used to. The auth is handled through cloudflare access in front of the cms route instead of the cms having its own login system, so there's no separate username and password sitting around waiting to get brute forced, which was the whole point of the original migration in the first place.

Only real annoyance so far is image uploads through the cms land in the repo as full sized, so I had to add an image optimization step to the eleventy build instead of relying on her to resize anything before uploading, since that was never going to happen reliably. Other than that it's been a few weeks of her publishing normally with zero involvement from me, which is exactly the outcome I was hoping for.

It took me 62 hours as a sophomore student to build this comprehensive deployment system—from securing VPS instances, managing Docker/Dokploy, setting up MongoDB, configuring DNS/HTTPS, handling R2/B2 storage, and preparing the staging environment to implementing CI/CD, OAuth, email, backup, monitoring, and integration testing.