Cache `discussions.json` with the service worker
Problem to solve
The loading speeds of the issue and MR pages start to suffer when there's a lot of discussion within them.
A lot of this is down to the fetching of the discussions.json
file that keeps all the data of all the comments, discussions, and activities.
Regular caching could cause problems for us as these discussions are regularly changing.
Target audience
This will impact anyone who uses issues or Merge requests, but will mainly help the users that look at the same ones frequently:
-
Parker, Product Manager, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#parker-product-manager
-
Delaney, Development Team Lead, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#delaney-development-team-lead
Also, but not as much:
- Sasha, Software Developer, https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas#sasha-software-developer
Further details
We added a service worker in gitlab-ce!23578 but haven't utilised the most powerful aspect of it yet, caching.
We could cache the discussions.json
for issues/MRs so they're all set and ready when you re-visit that page.
We'd have to make a subsequent call to check for new comments but it would omprove initial loading speeds.
This is simple enough for the service worker but requires our cache management to be spot on so we're not showing outdated data.
Proposal
Use the existing service worker to cache any discussions files that are requested by the user. On subsequent visits, we can serve the discussions file from the cache initially then wait for the request to complete and use and cache the updated one.
See this video for a better explanation (includes audio)
Screen_Recording_2019-02-27_at_16.22.29
Permissions and Security
We might have to look into the security implications of storing discussions on the user's machine. I'm pretty sure it's all secure and fine, but we should be certain.
Documentation
We shouldn't need documentation as (if done correctly) no one will notice this has happened other than the speed increase.
What does success look like, and how can we measure that?
Success is if we get a speed boost in loading speeds for secondary visits of MRs / issues. I'm not sure how well our performance metrics will measure this so this might be something we need to look into