wdyt: Dynamic to static site via proxy?
I'm usually building my sites using Vuejs.
Others use react, svelte...
Or other solutions like Wordpress.
The common thing to many sites is that they are just pure content with no personalized content for logged-in users.
All of these sites can benefit from becoming truely static. Meaning, not some framework that creates the dom using js. But pure html directly served from the server.
SSR and SSG ( server side rendering and static site generator) are pretty common and there are several good alternatives to choose from. But none of them is too easy to implement. You have to become familiar with the framework and bake it into your ci/cd. If you use WordPress or other site builder this is even harder to implement.
What I'm thinking about is a service that will be integrated simply by pointing your DNS record to it, and adding another txt record that points to your origin server. The service will be a proxy to your site, and you will get the following benefits:
- The entire site will be rendered on the server, the client will get html
- Everything will be behind CDN
- All meta tags for SEO and social tags and preview image will be controlled from the service UI
- Auto generated sitemap
- Additional future feature can be tag manager (like google tag manager). You'll be able to inject any js tag without changing your deployment. And because this is a proxy, you will not even have to embed the "main" tag.
What do you think about this?
Would you use such service?
Doesn’t Cloudflare do nearly the exact same thing for free already? If your cache tags are in order (and most of these platforms such as WordPress do that for you), the only hits your backend server may get is a cache validation. The entire content including static images and js then comes from the Cloudflare cache, which due to its global distribution also minimizes latency.
I use cloudflare myself. They don't do exactly that.
If your origin server serves html, then yes, you will get similar effect.
But if your origin server serves react/vue/svelte - you will get that app to your browser via cloudflare, and your browser will still run the react app that will generate the dom using javascript.
This means that facebook bot, for example, will not see the metatags because it doesn't run js.
Google and bing do run js, so it's less of a problem.
Other benefits that you will not get with cloudflare -
https://wordpress.org/plugins/simply-static/
https://www.hardypress.com/
Awesome, thanks!
It means that this is indeed a problem, and there are some players that try to solve it.
My first thought is that a person that understands the benefits you are providing (pretty technical) is probably already using SSG/SSR. Who is your ideal customer, and what do you have in mind when they will search for you in Google? That may help us understand your thought process.
If you search for ssr/ssg/prerender for popular frameworks, you will see that:
Bottom line, developers can set this up, but it is time consuming, can make your build process long, can be more expensive to host, and has a learning curve.
I started to even think about it because I'm trying to solve this for myself...
Is the intent to render it "on the fly" (as opposed to pre-rendering, as is done with server-side rendering) as a way to assist users who don't have the software development resources to do it themselves?
If so, while it's an interesting idea, why would someone who does not have their own software dev resources to do it themselves have such an app in the first place? Maybe I'm missing something, though...
And, such a solution may not handle SEO as well as doing native SSR.
I was thinking about pre-rendering. Every time the origin is updated, the service will crawl it. The crawler will have to actually run the origin using headless browser like Electron.
The result will be cached and used for serving.
The solution is not aimed at non-developers only. I'm a developer myself, and setting up SSG for my Vuejs site is really a pain in the arse.
I would be very happy to have something like that. This is how I came to think about it.
OK, thanks for the clarification - while I am only just starting to look at SSGs, jamstack, et al (so I don't yet fully understand the pain points involved with that), I do have experience with a reactjs SPA which has led to my thinking about SSR - but the SPA that I work with daily is not static, rather it has custom, user-specific dynamic content which therefore would not be a candidate for your proposed solution. But I will give your proposal some more thought as I get more experience with jamstack...
Thanks!
This is indeed not intended for web applications, only web sites with static content.