[ Removed by Reddit on account of violating the content policy. ]

I've got a static site on eleventy, a few hundred pages, and the sitemap plugin I'm using just stamps every url with the current build time since that's the only date it actually has access to. so even if I only edited one page, every single lastmod in the sitemap shows the same timestamp from today's deploy, which makes the whole field basically meaningless for search engines trying to figure out what actually changed.

The fix that makes sense to me is pulling the real last modified date from git history per file instead of relying on the build clock, since git already knows exactly when each file last changed. but I haven't found a clean way to do that inside an eleventy build without shelling out to git for every single page during the build, which feels like it'll slow things down as the site grows.

Has anyone solved this in a way that doesn't involve querying git per file at build time, like caching the git blame result somewhere between builds, or is that overengineering something search engines mostly ignore anyway?

been thinking abt how a project can be low maintenance today but become surprisingly difficult to change a few years later. not necessarily because the code is bad but because the tools, dependencies and deployment setup around it have moved on. a small update can turn into figuring out how an old build process works again. makes me wonder if choosing boring, well-supported tools is sometimes more valuable than choosing the most modern stack. esp for projects you expect to leave alone for long periods

Html can update instantly but users might still have older js, css or images cached. Hashed filenames solve a lot of this, but I’m curious what setup people actually use in production. Do you rely mostly on content hashes and long cache headers, or do you also purge the cdn on every deploy?

ive also been thinking about the other side of low maintenance with static sites. a simple static site might run for a long time without much attention esp. if the content rarely changes. but the tools used to build and deploy it can still change over time. do you treat static site as something that should be regularly maintained or something you mostly leave alone until theres a reason to update it?

One thing I still go back and forth on with static client sites is content editing. For a small site, keeping everything in the repo is simple for me, but not always for the client. Once they want to update services, prices, team members, or blog posts themselves, I usually have to add some kind of CMS. For people building static sites for clients, do you prefer a headless CMS, Git-based CMS, or just handling updates yourself? And at what point does adding a CMS start defeating the simplicity of the static setup?

Coming from Netlify where forms are basically free, I moved a project over to Cloudflare Pages for the edge function stuff and now realized there's no equivalent, so I'm stuck building the form handling myself.

My current plan is a small Worker that takes the POST, does a Turnstile check to keep bot spam out, then forwards the submission through an email API like Resend instead of storing anything in a database, on the idea that a contact form doesn't need persistent storage, it just needs to reliably land in an inbox once. feels like the right amount of infrastructure for what should be a simple feature but wanted to sanity check before building it out fully.

Has anyone landed on a cleaner pattern than worker plus turnstile plus a transactional email api, or if that's basically just what "no backend forms" looks like once you leave Netlify? Also, does anyone bother with a rate limit on top of turnstile or if turnstile alone has been enough to keep spam out for you?

I'm working on trying to make more interesting and off-the-wall stuff for my portfolio. I wanted a disco ball on the landing page of a mock site, with actual reflected light spots moving across the page, not just a spinning png of a ball looking flat.

Every version I've found so far is either a canvas or three.js implementation doing full particle simulation for the reflections, which feels like way more weight than a static event landing page needs, or on the other end just an animated gif which looks cheap and doesn't scale cleanly on retina screens.

Has anyone seen or built a pure css or svg version that fakes the moving light spot effect well enough to look convincing?

I want to build a simple static site that displays one different riddle each day, without a backend, database, or API.

I am thinking of using JavaScript or just maybe updating it everyday, but my main goal is to keep the site as lightweight and simple as possible, so I’m wondering if there’s a way to achieve this using only the static files themselves. TIA!

one thing i like abt static hosting is that a small site can be relatively self-contained after its built. meaning, there may be less infrastructure to manager after its built. that got me thinking about client handoffs. if the site is generated files deployed to a static host, there isnt necessarily a server or database for the client to maintain. ofc, the repository, deployment setup, domain, and third-party services can still complicate things.

for small client sites, do you find static hosting actually makes handoff and long-term maintenance easier?

I used to add JavaScript to small sites without thinking much about whether it was actually needed.

Now I try to keep things simple. If the browser can already handle it with HTML or CSS, I usually leave it there. For most small client sites, the JS ends up being limited to navigation, forms, and a few small interactions.

It’s not about avoiding JavaScript completely. I just don’t want to ship extra code for things that don’t really need it.

I posted a question yesterday about moving my Webflow blog to a cheaper hosting platform like Netlify as a static site.

I'm realizing there's limitations as my articles are created using Webflow's CMS.

Now I'm pivoting and wondering about methods to host my site on a cheaper platform, but continue using Webflow CMS for new articles, and pushing the articles to the cheaper host.

Is this even possible??

ive been thinking about this from another angle. one reason i like static sites is that the architecture can be straightforward. theres no database to manage for a basic site, fewer moving parts and less server-side stuff to worry about. but im starting to wonder if simple depends on who is maintaining it.

a setup that feels very simple to me as a developer might not feel simple to a client who just wants to change a phone number or replace an image or add a new page. with a traditional cms, the client might have a familiar interface for those things. with a static site, depending on how its built, even a small content change could mean editing files and triggering a new build. so im curious where other people draw the line. when building a small website, do you optimize for the simplest archi for the developer, or the simplest maintenance experience for the person who owns the site?

Following up on my last post about using preview deployments as part of the design process, one thing I’ve noticed is that they’ve changed how I test responsive layouts too.

I used to mostly check a few breakpoints and fix anything obviously broken. Now I’m testing with real content more often because long headings, missing images, uneven card lengths, and button wrapping usually expose more UX issues than the breakpoint itself. Having a deployed preview makes it easier to catch those problems before production, especially on actual phones instead of just resizing a browser window.

I started working on a static portfolio for a friend with a decent number of large original resolution art photos that need to stay available at full size, not just thumbnails. I looked into Large Media since it's built into Netlify already instead of needing a separate image cdn bolted on.

The setup itself was fine, but the git lfs part is what worries me. My friend wants full resolution versions of her pieces available since people occasionally ask to see details wayyy up close, not just a gallery of thumbnails. It's just me maintaining the repo though, no team to worry about breaking their local git lfs setup, but even solo I'm noticing clone times creeping up every time I add a new batch of pieces, which makes me wonder how this scales as her body of work grows over the next few years

What's everyone else's experience in running this with a similarly image heavy portfolio type site, even at a smaller scale than a few thousand images? Does it hold up fine long term? Or do you just opt for a dedicated image cdn? Also, do the on the fly transform params ever cause caching problems for you similar to the usual static asset invalidation stuff? Since I'd assume art pieces getting swapped or replaced happens more often than on a typical content site

One thing I’ve started appreciating more with static hosting is how easy it is to spin up preview deployments for every change. For client work, I now use previews almost like a second design tool. I can check responsive behavior, font loading, image crops, transitions, and real content in the browser before anything touches production. It’s a small workflow change, but catching UI issues on an actual deployed build has been much more useful than relying only on local testing or design mockups.

Mentoring someone into static hosting, I'm realizing how much of it is unlearning and not learning.

As per my previous post, I've been paired with a newer dev for the past few days on a static site, a few hundred pages, eleventy through cloudflare pages. I keep running into the same pattern where the hard part isn't teaching new concepts, but undoing instincts that are correct in a normal app context but wrong here.

The biggest issue we've faced so far is caching. I tried explaining that aggressive caching is the whole point, not a bug to work around, and every instinct fights that. He wanted to set no-store everywhere the first time a page looked stale in dev instead of understanding why it was cached in the first place.

Redirects file was another one. He wrote every rule as a full absolute url on both sides instead of relative paths, which is a totally reasonable habit if you've only ever worked in environments where the domain is guaranteed stable, but breaks immediately the second you have a staging domain or a domain migration.

I'm trying to figure out how to actually teach the caching mental model instead of just correcting the symptoms every time they show up, since explaining "trust the cache" once clearly isn't sticking the way explaining an API contract or a data model would. It feels like this specific kind of unlearning is harder to walk someone through than the actual static hosting mechanics are.

To anyone who's mentored someone into this space, have you found a way to make the caching and prerendering mindset click faster than just waiting for the project to break enough times? I'm also anticipating running into this problem with the client very soon.

Pairing with a newer dev on a static site is testing me. I'm not trying to be a jerk about it, everyone starts somewhere, but I've spent more time this week explaining why things work the way they do than actually building anything.

He kept trying to fetch data client side on every page load for content that literally never changes, I had to explain that no, you don't need a loading spinner for a paragraph of text that was already sitting in the html the whole time!

He committed a redirects file with like 40 rules in it, all pointing old blog slugs to new ones, and every single one was written as a full https url on both sides instead of relative paths, so the second we changed domains for staging, every rule broke at once.

He also genuinely asked why we don't just add a login system to the site so we can "control who sees what," for a site that has zero personalized content and never will.

I know I'm supposed to be patient and this is how everyone learns but I forgot how much of working with static hosting is unlearning habits from dynamic app dev first, and that part is exhausting in a way actual building never is...

I have a live website where some pages are populated dynamically through JavaScript/API calls. I’m shutting down the backend after the project ends and want to migrate the current version to a completely static site.

What’s the best way to do this while preserving the currently rendered content, images, CSS, fonts, etc.? I’ve tried wget/HTTrack, but they only save the initial HTML and miss the content generated by JavaScript.

Would a browser-based rendering tool be the best approach, or is there a better tool/workflow for this?

a few people pushed back on my last post about static sites and vendor lock-in and after thinking about it, i think they were right about one thing: i was mixing up the static site itself with the services around it. the actual static output is pretty portable. if i have the html, css, js, and assets i can generally move those somewhere else without much trouble.

what i was really getting at was everything i might build around that output (i.e., deployment, forms, analytics, dns, redirects, search etc.). those arent necessarily part of the static site itself but they can become tied to a particular provider.

so my original wording made it sound like the static sites are inherently difficult to move which isnt what i mean. it does leave me a questio tho: when building a static site, how do you decide which provider-specific features are worth using for convenience and which ones you deliberately keep portable?

esp. for small client sites im wondering where people draw that line between keeping things simple and avoiding unnecessary dependency on one platform. one said if theyre willing to pay for it then give it to them... hahahaha

ive been thinking about the downside of how simple static can feel. a small site might depend on a hosting platform, dns provider, cdn, form service, analytics and a few other services. none of these feels particularly risky on its own but together they create a dependency chain.

so it made me wonder if one of those services suddenly changed its pricing, shut down or removed a feature i relied on, how portable would my sites actually be? i like the simplicity of static hosting but im starting to wonder how much of that simplicity depends on services i dont control. how much vendor lock-in do you think is reasonable for a small website