Lazy load uncommon CFG_GLPI values #21528
Open
+94
−5
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Checklist before requesting a review
Description
One of a few possible optimizations to improve GLPI performance. I only consider this a short-term optimization when there are better ways to handle this and it is not a substantial optimization on its own.
Dumping the entire safe CFG_GLPI array in a JS script on the page is excessive.
We only really use the "root_doc" config in most places.
Even in plugins as far as I can see, there are very few non-"root_doc" uses of this variable.
Instead of dumping the entire config, I replaced it with a proxy to transparently lazy-load missing values.
This would be a synchronous call but it was necessary to not break existing code and the need to fetch additional configs should only rarely come up.
I believe the faster initial page loads would be worth it.
Tested in production env.
Seeing approximately 8kb (compressed size) less transferred per page and approximately 30ms less page download times.
Seeing "Time to DOM interactive" and "Time to DOM complete" metrics a 100-200ms lower on average but this can vary a lot.
Minor performance improvements and data usage reductions should be seen across the entire app for initial page loads.