Replies: 1 comment 2 replies
-
|
@manniL do you maybe have an idea, if this is possible with the currently available route rendering modes? |
Beta Was this translation helpful? Give feedback.
-
|
First question would be: Do you want the "non-static" content be part of the SSR, so relevant for SEO as well (I'd assume yes, right)? If "no", then this should be rather easy. If yes, I think that kind of architecture is possible with a bit of manual work I wonder if it wouldn't be easier to "cache" the full amount of data for the initial request but I understand it might not be desired and the data should be as current as possible. The "cost of caching"/"building" varies a lot on where you store the cached data and whether you want to save them all on build or "incrementally" when running the app |
Beta Was this translation helpful? Give feedback.
-
|
@manniL Thank you for your answer! Really appreciate it :)
Yup, parts of the non-static content would have to be cached as well. Those are described in "Requirements". It's about a bare minimum for making google crawler happy. Some canonical tags, a header and a proper translation, so that different URLs have different content. Especially the last one from requirement could be tricky, coz for setting filters I would have to make a call to an external backend to grab possible filters and then pick the right ones, set them as 'already chosen' and translate, and then cache it all without triggering the rest of the requests to the backend (those triggered by choosing some filter). Could you provide some links or direction, what should I be looking for or what approach would be recommended?
Sadly the second one is the answer. The data changes quite often and our backend needs also some time to give us the results so the idea was to cache at least what is needed for a good SEO score and provide the rest as a skeleton to be filled later by the client request. Important:
Most probably it would stay in the Azure Front Door. I thought about creating the cache in the build phase, but maybe as you suggested it would be easier to run it when the build is done (running app). I assume that this approach would kind of simulate a crawler going through all the listed URLs and caching them (although only partially). What about pages that are not cached yet? Would it just take longer to deliver them/ would they work in the same manner even for non-JS crawlers? Is there some article about it comparing the build times, running app load while generating, etc? |
Beta Was this translation helpful? Give feedback.
-
Hi there,
I'm in a process of choosing a technology for our next project. A this point I'm trying to find out, if Nuxt could help us here or if it's not worth the cost and we should stick to Vue. The major area in which Nuxt could help us would be a one of the hydration modes (I'm still a bit lost here so the naming can be incorrect), if it would work as described below.
Enviro/restrictions:
Requirements:
<head>part of the page (canonical tags, title, etc) based on requested URL<h1>based on requested URL('Rechtsanwalt' and 'Berlin' on the left side of the image below)
Expectation/questions
I would like to find a way to add some file with a list of URLs or even better: a function generating all wished URLs (language + some params), and let Nuxt build and cache them in every build. We are speaking here about mostly static content, but translated and a bunch of so called Skeleton elements which would be exchanged in a hydration process (check image section).
Another thing is the amount of such pages - it would be at least hundreds of them if not several thousands. Would the cost of building and caching such amount be astronomical?
Image
Sample URL here:
https://domain.com/de/legal/lawyer-berlinPlease share your insights, if you have some experience with similar approach.
Beta Was this translation helpful? Give feedback.
All reactions