I’m currently developing a few websites and, since I already built a visual library I can reuse, I decided to start working on the SEO and prerendering side of things. While going through some recent posts about SSR and how static collections work now after an update in WeWeb, I started looking into alternatives and came across OSTR.IO and Page Replica - Enhance SEO with Prerendering, Caching, and Static Page Serving. Both options seem fairly priced and not so crazy to install.
It seems like a good workaround to handle prerendering and improve SEO without having to build a more complex setup. I think this could be the best next step, especially since other approaches would require a bit more configuration.
Do you think they could work well with WeWeb? Could they be viable directions to take for the website, or is there something I should consider before going down this path?
NOTE: I understand this is a feature that was actually removed. Are there any plans to add a toggle for this behavior in the editor?
I looked into pre-rendering before and went down the path of setting up a html rewriter using cloudflare workers, with the plan that dynamic collection content gets injected this way.
In theory it works, but the way WeWeb is hosted, it isn’t possible to change the DNS in Cloudflare to “proxied” which is needed to allow this method to work unfortunately. As a result I didn’t try any other prerendering solutions thinking this will be a similar blocker - but would like to know if you are successful.
I gave it a read and I agree with the comments. It’s good news, but honestly a bit underwhelming. Like @MCMichael pointed out, I understand there must be some sort of prioritization method for feature rollouts, but I really think SSR should be much higher on that list.
Understanding the development cost: When comparing it to something like a chat component, I believe SSR could bring way more value to a broader range of use cases, and possible integrations.
What I was referring to is something somewhat related, though not a replacement for SSR, which is the pre-rendering of static collection records. From what I understand, this could have a meaningful impact on performance for the overall app and some SEO benefits.
For static pages that heavily rely on a CMS, I’m thinking of 2 possible pathways right now:
Moving them to a separate platform while SSR is not available; or
Exporting WeWeb’s Vue app and hosting it as a standalone project. That way I could try implementing the pre-rendering technologies I mentioned.
What do you think? I see that you’ve been working some time on your project, so I assume you’ve hit this wall a couple times.
Maybe I can give some insight into how we solved this at my company. I will try to keep the explanation as non-technical as possible.
We use a Bunny CDN in front of WeWeb, domain is pointing at Bunny and the CDN’s origin is pointing at WeWeb (Cloudflare). This makes it possible to use Bunny’s edge rules, scripting etc. (you could also do this using a Cloudflare CDN / Worker setup).
The CDN is running an edge script that decide if it’s a crawler or not. If it’s a crawler it will forward the request to seo4ajax.com and serve a pre-rendered version of the page.
If it’s not a crawler, it will inject a javascript link into the head of the html before returning it to the browser. This javascript link is actually just a custom made up url: www.domain.com/api-preload/
In Bunny CDN we’ve created an edge rule that says, if the url contains /api-preload/ it should forward the request to a specific script.
Inside the script, we capture the from the requested url and fetch the specific information from backend API and return it using a javascript response that set a specific window.__weweb_data variable with the backend API response. The CDN cache these responses, so it have it ready on next request.
Inside the WeWeb page we have an on load workflow that check if the window._weweb_data is present, then use the data or else it follow normal flow and fetch collection.
The result is that the page load much faster and data is ready as soon as WeWeb is ready to render the page.
