-
-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Address #27 - Dedupe in-flight requests and add 2 minute stylesheet caching #35
Conversation
cq-prolyfill.js
Outdated
CACHE[href] = response || ''; | ||
setTimeout(function() { delete CACHE[href]; }, CACHE_MAX_AGE); | ||
|
||
IN_FLIGHT[href].forEach((cb) => cb(CACHE[href])); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No arrow functions here 🦀
Thank you for this pull request!
Nothing to be sorry about, I guess I have to update the I modified your code a little bit in PR #36, combined I’m not sure if the 2 minute cache timeout is actually necessary. Can you imagine a case where it is needed? |
@ausi VS no expiry? I think it might be useful for something like dynamically updated stylesheets, but at least in the case I'm thinking of (webpack dev server), the URL actually changes. Context: we are using cq-prolyfill on a fairly large website with a lot of dynamically injected links to stylesheets. Right now reevaluate() is re-fetching and parsing a pretty huge number of stylesheets, enough that we noticed it in network graphs haha. |
Thank you for reviewing and cleaning up the code, and for adding supporting tests. @developit covered the use case here - upon page loads we are seeing a single stylesheet being requested about 20~ times over the course of roughly 4 seconds. The caching is something I usually include as standard for repeated AJAX requests in order to avoid network calls as much as possible. I just tried it out without caching, and I still saw repeated requests for the same stylesheet. 1 second after the first de-duplicated request had returned, a repeated request for the same stylesheet was made. So because of that, I think we need at least a short cache here to solve #27. Maybe the expire time could come down to 30 seconds? |
I think we could remove the expiration completely, meaning cache it for the whole lifetime of the page. |
Agreed - at first I had though you were asking about reducing the cache time @ausi, but it makes sense to cache infinitely - it's in-memory, and any network call to the same URL in that same context is going to get the same stylesheet anyway. At least for our use-case, in-memory caching without expiry should cover all needs. |
Then I agree too there's no need for an expiration. I also thought @ausi was looking for a shorter cache time. |
Great! I updated #36. After the BrowserStack API starts working again and the tests pass in all browsers, I will merge it. |
Thanks for the quick follow up and the cool project! |
To address the duplicated requests, I added deduplication and caching to
loadExternal
.Using the awesome minimal test case from @Frxnz, I saw 3 XHR requests for each stylesheet. Here is a fixed test case showing only 1 request by
loadExternal
for each stylesheet.I was unable to run your test suite because I could not find the
replace
package on Arch Linux, sorry. :)