CLI option to reset cache but not storage APIs #2599
Comments
|
For a little more insight into the issue, what exact steps do you take to run Lighthouse today and which pages are you hoping to audit with a clean cache? Current breakdown as I understand it, but perhaps your case differs
We'd also be interested to have your input in #1418 for any patterns in your use case that might not have been identified yet :) |
|
Hi @patrickhulce, Recurring visits with empty cacheYour breakdown is pretty much what I'm trying to do :)
Current manual workflowCurrently I do the following:
Ideal automated workflowIn order to automate this process, setting the localstorage and cookie values somehow as recommended in #1418 would be necessary. This is especially the case, since on mobile the cookie agreement renders fullscreen, which renders the lighthouse report's screenshots rather pointless. Should I comment that localstorage part in #1418? It's feels more like a separate issue to me. Best, and thanks :) |
|
how do we feel about |
|
Oooh I like that @wardpeet, might be a bit confusing what the intention is though we'll have to make it clear that you're asking to keep the storages that you list there. Double negative getting confusing 😆 @gruppjo for complicated cases where you need to setup multiple storages in a particular way I'm not sure we'll get to a place where Lighthouse will have that functionality baked in, your best bet for now might be creating a custom gatherer that sets up your requirements in the |
|
@patrickhulce we could also do the other way around |
|
The more common case I imagine will be "just keep localStorage" or "just keep cookies", so I think your first proposal makes sense just might need some explaining |
|
@wardpeet - On by default & explicitly disabling certain storage reset options feels less confusing given the default of nuking everything out of the box, which in most cases is completely reasonable when benchmarking performance. I'd say making the opt-out an explicit action would be the right way to go. |
|
so we should probably go for |
|
FWIW we prefer the API proposed here: #2599 (comment) |
|
This is probably a good first contribution? |
|
I have also been looking for this feature (please clear my cache but not my localStorage) not only in the command line, but also using it programmatically in node. For instance, the website I am testing has a page-gate, asking which country user is from and age of user (for compliance reasons for cough cough medicinal herbs...). In order to bypass this modal, which is launched on every public page of the site, I need to have 4 localStorage variables set in the browser. I can successfully see it working when using the command line to launch chrome-debug like so Problem is that I am seeing a 30-40 point drop in performance from the page-gate modal, and I can't be completely sure it isn't due to cache. Hence I want to be able to have the solution above to the CLI. Also I want to be able to perform this programmatically, because I wrote a script that performs this test across different hosting providers (heroku, netlify, AWS, etc) and wrote a script to test them a dozen-or-two times each and average all the scores (throwing out outliers). Having this test automated so we can reliably see averages, and have it run in our CI/CD process is pretty crucial to measuring the performance we all want to achieve. I can see this is pretty old of an issue, but wondering if it is getting any traction? |
|
For programmatic setup prior to Lighthouse you're going to want to look at #3837 and #1418 @timothyjoh. tl;dr use puppeteer and/or a custom gatherer in Lighthouse. It just hasn't seen enough interest from external parties to receive priority over other ongoing efforts, but we like the idea. |
|
Thanks for the quick response, and these potential solutions, I will experiment over the week and update if I find anything relevant. |
Update src/firebase/index.ts to export getFirebase, getAuth, getFirestore, and getFunctions functions that load the corresponding Firebase modules asynchronously. This lets webpack create separate chunks for each piece of Firebase, reducing the app entrypoint from 1.12 MiB to 593 KiB. It also improves Lighthouse measurements for the login page on a simulated 3G network with 4x CPU slowdown: First Contentful Paint: 3.1s -> 2.4s Time to Interactive: 3.5s -> 3.0s First Meaningful Paint: 3.2s -> 2.4s First CPU Idle: 3.3s -> 2.9s I'd expected an improvement here, since the login page doesn't depend on Firestore. It's harder to tell if there's a benefit on the other pages. They all require login, which means that "Clear Storage" needs to be unchecked, which I think means that the cache is preserved, so download time doesn't get measured. See GoogleChrome/lighthouse#2599 for more discussion of this. It stands to reason that there would be less benefit there in any case, though, since all of those pages require both the auth and Firestore modules to be loaded before they can do anything meaningful.
Update src/firebase/index.ts to export getFirebase, getAuth, getFirestore, getFunctions, and getFirebaseUI functions that load the corresponding Firebase modules asynchronously. This lets webpack create separate chunks for each piece of Firebase, reducing the app entrypoint from 1.12 MiB to 593 KiB. It also improves Lighthouse measurements for the login page on a simulated 3G network with 4x CPU slowdown: First Contentful Paint: 3.1s -> 2.4s Time to Interactive: 3.5s -> 3.0s First Meaningful Paint: 3.2s -> 2.4s First CPU Idle: 3.3s -> 2.9s I'd expected an improvement here, since the login page doesn't depend on Firestore. It's harder to tell if there's a benefit on the other pages. They all require login, which means that "Clear Storage" needs to be unchecked in Chrome's Dev Tools Audit tab, which I think means that the cache is preserved, so download time doesn't get measured. See GoogleChrome/lighthouse#2599 for more discussion of this. It stands to reason that there would be less benefit there, though, since all of those pages require both the auth and Firestore modules to be loaded before they can do anything meaningful.
Update src/firebase/index.ts to export getFirebase, getAuth, getFirestore, getFunctions, and getFirebaseUI functions that load the corresponding Firebase modules asynchronously. This lets webpack create separate chunks for each piece of Firebase, reducing the app entrypoint from 1.12 MiB to 593 KiB. It also improves Lighthouse measurements for the login page on a simulated 3G network with 4x CPU slowdown: First Contentful Paint: 3.1s -> 2.4s Time to Interactive: 3.5s -> 3.0s First Meaningful Paint: 3.2s -> 2.4s First CPU Idle: 3.3s -> 2.9s I'd expected an improvement here, since the login page doesn't depend on Firestore. It's harder to tell if there's a benefit on the other pages. They all require login, which means that "Clear Storage" needs to be unchecked in Chrome's Dev Tools Audit tab, which I think means that the cache is preserved, so download time doesn't get measured. See GoogleChrome/lighthouse#2599 for more discussion of this. It stands to reason that there would be less benefit there, though, since all of those pages require both the auth and Firestore modules to be loaded before they can do anything meaningful.
Update src/firebase/index.ts to export getFirebase, getAuth, getFirestore, getFunctions, and getFirebaseUI functions that load the corresponding Firebase modules asynchronously. This lets webpack create separate chunks for each piece of Firebase, reducing the app entrypoint from 1.12 MiB to 593 KiB. It also improves Lighthouse measurements for the login page on a simulated 3G network with 4x CPU slowdown: First Contentful Paint: 3.1s -> 2.4s Time to Interactive: 3.5s -> 3.0s First Meaningful Paint: 3.2s -> 2.4s First CPU Idle: 3.3s -> 2.9s I'd expected an improvement here, since the login page doesn't depend on Firestore. It's harder to tell if there's a benefit on the other pages. They all require login, which means that "Clear Storage" needs to be unchecked in Chrome's Dev Tools Audit tab, which I think means that the cache is preserved, so download time doesn't get measured. See GoogleChrome/lighthouse#2599 for more discussion of this. It stands to reason that there would be less benefit there, though, since all of those pages require both the auth and Firestore modules to be loaded before they can do anything meaningful.
|
@patrickhulce I would like to ask that how to utilize this option i.e. "--disable-storage-reset" in node programming using node library of lighthouse! |
|
@InfobyteTarun you can use the lighthouse(url, {disableStorageReset: true})
// OR
lighthouse(url, flags, {extends: 'lighthouse:default', settings: {disableStorageReset: true}})
// DISCLAIMER: untested and written from memory, refer to docs for actual working codesee https://github.com/GoogleChrome/lighthouse/tree/master/docs for full examples and details |
|
@connorjclark started tinkering with this, it was fairly simple to make it work. I got confused by the tests and didn't manage to find my way there. Would you have some time to help out? |
|
Any news for this issue? |
Hi everyone :)
I've started using lighthouse for one of our large scale Angular 2/4 apps and it's working really nicely. Thank you!
The app has authentication, cookie-layers etc... So I needed to run lighthouse with
chrome-debugand use--disable-storage-resetwhich does [link]:Incidentally I was hoping that
--disable-storage-resetwould only disable a reset for Cookies, localstorage and the other APIs and that the cache on the other hand would still be reset before every run.That behavior is the one I'm most interested in since it's a very common case that users will access new areas (no content in browser cache) of the app but will have already logged in. Currently I can't test that.
So I'd recommend another CLI option that does just that.
What do you think?
Best, Jon
The text was updated successfully, but these errors were encountered: