Restrict Angular SSR to paths in the sitemap #3682
Conversation
Because Angular SSR is not very efficient, after discussion with the Google Scholar team we realized a compromise would be to only use SSR for pages in the DSpace sitemap.
alanorth
added
bug
high priority
performance / caching
|
Tests are failing because CI is checking for SSR on
The first option is probably the best because https://demo.dspace.org/entities/person/3b087e38-cd6b-4d85-9409-99a9f6f03425?spc.page=1&query=search With entity search pages we have many combinations of pages depending on filters and number of items similar to Perhaps this requires a re-think. What about inverting the logic and enabling SSR for everything, but disabling it on certain paths? |
|
|
@alanorth : Thank you so much for getting this PR created! I was just asking someone to do this in yesterday's Developers Meeting. Regarding the failing tests, I'd recommend adding One other suggestion. I think it'd be better to make these paths configurable instead of hardcoding them in the (You'd have to update the existing Then in the code use I'd argue that there also should be a way to enable SSR for everything (to retain current behavior). Perhaps that's the default behavior if this Overall, I do like this PR & support adding it quickly. I just want to add more flexibility to the configuration, as there's a chance that different sites will want to add additional paths (or keep the default behavior of SSR enabled for every path). |
You're welcome. I saw the meeting notes and was surprised that there wasn't already a PR, since I've been using versions of this patch for a few months already.
Yes, agreed.
Oh good idea, I didn't know about |
References
Description
Only enable Angular SSR for paths in the DSpace sitemap. This is a compromise after analyzing high CPU usage in DSpace 7+ and discussion with the Google Scholar team. We do not need to be wasting CPU and memory to generate and store SSR pages in the cache for request paths that are not "primary" DSpace objects, for example search and browse—these request paths contain data derived from the primary objects themselves and bots can spend endless time crawling them.
This solution was originally proposed by @vitorsilverio in #3110 (comment). I have opted to include the list of SSR paths as a
constinstead of including them from another file because it is cleaner.Some notes:
inlineCriticalCssbecause it improves the user experience. We disabled it in DSpace 7.6.2 and 8.1 because it made SSR perform even more poorlyInstructions for Reviewers
Please add a more detailed description of the changes made by your PR. At a minimum, providing a bulleted list of changes in your PR is helpful to reviewers.
List of changes in this PR:
Include guidance for how to test or review your PR.
Try browsing the repository to see if all pages work as expected.
Checklist
This checklist provides a reminder of what we are going to look for when reviewing your PR. You do not need to complete this checklist prior creating your PR (draft PRs are always welcome).
However, reviewers may request that you complete any actions in this list if you have not done so. If you are unsure about an item in the checklist, don't hesitate to ask. We're here to help!
mainbranch of code (unless it is a backport or is fixing an issue specific to an older branch).npm run lintnpm run check-circ-deps)package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.