When running a Lighthouse (e.g. v6) via NPM package, for example:
lighthouse --view --save-assets https://example.com
Getting these numbers in the browser:
Then using Dev Tools > Performance > Load Profile to load the saved trace JSON, getting:
Question
Largest Contentful Paint 2.3s in the report vs 408.0ms in the profile. How to correlate this?
The Lighthouse works as expected.
One would have to check-out the Simulated throttling:
After checked-out clicking View Trace will show the actual data in the Performance panel.
By default Simulated throttling is checked-in, it would run the page without any throttling and then apply throttling manually to the result. In this case clicking View Trace shows the original (unthrottled) data.
Related
I have a progressive web app and I wish to make changes to its manifest file like a change to its start_url, scope, icon, name and short_name. I wish to know, when is it that the updates to the progressive web app take place after making a change to its manifest? I tried the following to force update the web app on Chrome browser:
Launch WebAPK
Close the WebAPK
Modify the Web Manifest
Advance Android's system time by 3 days.
On my device: Settings>System>Date & Time>Set date
Launch WebAPK, wait a few seconds
Run adb shell dumpsys jobscheduler | JOB.*91.*org.chromium.components.background_task_scheduler.BackgroundTaskJobService
Check that the output is not empty
Close the WebAPK
Run adb shell cmd jobscheduler run -f com.android.chrome 91
to force an update
However, I wish to know what is the real criteria for update to the web app after a change to the manifest file is done? Please can someone attach a code snippet supporting the same, which may be specific to how Chrome implements it?
I did a deep dive, to know what exactly is the criteria for update of web app on changes to manifest file and I was able to find the relevant source code in the chromium code base which had the update logic. According to the latest chromium source code changes https://chromium-review.googlesource.com/c/chromium/src/+/1635860 , the update interval is set to 1 day (99% cases, where the apps may update more frequently) and 30 days (1% cases where the apps may update less frequently). Previously, it was set to 3 days ( 99% cases) and 30 days ( 1% cases). Also, there is an official documentation by Google https://developers.google.com/web/fundamentals/integration/webapks#update-webapk which says :
Chrome will periodically compare the locally installed manifest against a copy of the manifest fetched from the network. If any of the properties in the manifest required to add the PWA to the home screen have changed in the network copy, Chrome will request an updated WebAPK, reflecting those new values.
There are a number of rules that govern how these update checks are triggered:
Update checks only happen when a WebAPK is launched. Launching Chrome directly will not a trigger an update check for a given WebAPK.
Chrome checks for updates either every 1 day or every 30 days. Checking for updates every day happens the large majority of the time. It switches to the 30 day interval in unlikely cases where the update server cannot provide an update.
Clearing Chrome's data (via "CLEAR ALL DATA" in Android settings) resets the update timer.
Chrome will only update a WebAPK if the Web Manifest URL does not change. If you change the web page from referencing /manifest.json to reference /manifest2.json, the WebAPK will no longer update. (Don't do this!)
Chrome will only update a WebAPK if the WebAPK is not running. Moving the WebAPK to the background is not sufficient if it keeps running.
Only WebAPKs created by an official version of Chrome (Stable/Beta/Dev/Canary) will be updated. It does not work with Chromium (org.chromium.chrome).
The update check may be delayed until the device is plugged in and has a WiFi connection.
Validated the same already.
The code flow responsible for this update is given by follows :
Whenever, there is an update to the manifest file at the same origin, an update task is scheduled in the background service by the WebApkUpdateTask the link of which is given as follows : https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkUpdateTask.java .
This update task is managed by the WebApkUpdateManager , the link of which is as follows : https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/webapps/WebApkUpdateManager.java?sq=package:chromium&dr=CSs&g=0
The check for updates interval is done by the WebappDataStorage , the link of which is as follows : https://chromium.googlesource.com/chromium/src/+/652f0ba0d8d29ba7508654bf20172d3c83a784fb/chrome/ android/java/src/org/chromium/chrome/browser/webapps/WebappDataStorage.java (https://chromium.googlesource.com/chromium/src/+/652f0ba0d8d29ba7508654bf20172d3c83a784fb/chrome/android/java/src/org/chromium/chrome/browser/webapps/WebappDataStorage.java)
I have an app which downloads 1000 small images and writes them to indexedDb (using localForage). Upon the completion of the download, and the 1000 indexedDb setItems, I look in the devtools and the database is empty. I see the message "Data may be stale". Clicking "Refresh database" makes no difference. If I load a copy of the app in a second window, it sees an empty database. After a minute or so of reloading the 2nd window, the data appears.
Can anybody explain what I'm seeing, and if there any optimisations I can apply to have the data available more quickly?
It means that the indexedDb has detected an data that is not in syn with your present project. Also, be sure to include a break statement if your using a switch statement
Check out this link for more info
Data may be stale
We are working on an automated system for memory performance monitoring.
We start Chrome with proper flags --trace-gc --trace-gc-verbose both on Windows7 and MacOSX High Sierra.
The output is printed and visible on the console. However capturing the output with standard stream redirection does not work:
What do we do:
MacOS X:
./Google\ Chrome --js-flags="--trace-gc --trace-gc-verbose" > log.txt 2>&1
Windows:
chrome --no-sandbox --js-flags="--trace_gc --trace_gc_verbose" > log.txt 2>&1
What gets written into the log file is only a part of what you can see on the screen: all gc-related data is missing in the file although abundant in the terminal window (you can see all the data when you run the app without stream capture at all).
We suppose a new process for V8 is run and it's output is not directed to stdout, though somewhat it gets printed to the console itself.
The V8 C++ code shows no mark of such a strange redirect, pretty clean standard code, in fact one can record gc-output of node --trace-gc script.js without any problem with standard stdout/stderr. It seems Chrome adds the undesired behavior.
Question how to record Chrome gc-related data to a file both on Windows and MacOS X.
Partial, unacceptable solution on POSIX-based systems we can grab all the terminal output with script command. The dump contains all the data we need, but the solution does not cover Windows scenario (we do need tests on Windows) and in fact it does not solve the problem neither explains the reason behind the lacking data, it simply hides the problem away.
I think there are two things worth being pointed out.
The only output that is actually being redirected is Chrome-related. I mean if we redirect stderr to a file we can see the errors in this file, but only Chrome's errors not V8's.
I wanted to use script command as I tried Powershell Start-Transcript, Tee and a few other options. It has turned out (no suprises here) that Windows has no command that can be used to achieve desired effect (AFAIK). So I used Babun (http://babun.github.io/) which is basically preconfigured Cygwin. No GC log has been displayed. Only Chrome's related stuff. I think that V8's logs are not being forwarded to Cygwin.
UPDATE:
This issue may be somehow related with these:
Chrome spawns many processes and from what I can see from logs - GC logs are gathered from child process (different PID than one related with opened terminal window). I do not know how this alone could affect STDOUT redirection. It's just a fact I noticed.
I found out that an application may know if its STOUD is being redirected and handle this situation differently - e. i. using buffers without flushing when STDOUT is being redirected to a file but not if it is printed on the console.
UPDATE:
I have created a following bug: https://bugs.chromium.org/p/chromium/issues/detail?id=865876#c3
It seems like it was noticed and someone is going to take care of it.
UPDATE:
It seems like ChromeDriver can do exactly what we need - http://chromedriver.chromium.org/logging/performance-log
Another workaround would be to run Chrome with --enable-precise-memory-info and the periodically invoke window.performance.memory, but that command does not provide us with nearly as much data as ChromeDriver
I'd like to use Selenium alongside my current Chrome profile, which may or may not be in use. I'd like to be able to launch some Selenium automation that is aware of (for example) any currently set cookies from my current Chrome session. I'd also like my Selenium automation to be able to change cookies that will still persist in my local profile.
Example:
I'd like to be able to manually log into a website (without
Selenium)
I'd like to then launch some Selenium automation that
assumes I'm already logged in (which I would be)
I'd like to then make some type of change through the Selenium automation
I'd like to close out the Selenium automation and see the changes that were made reflected in my original, manually-initiated, session
I know this can technically be achieved by setting user-data-dir in ChromeOptions, however that results in the following errors:
[20644:39092:1124/205239:ERROR:cache_util_win.cc(20)] Unable to move the cache: 0
[20644:39092:1124/205239:ERROR:cache_util.cc(134)] Unable to move cache folder C:\Users\****\AppData\Local\Google\Chrome\User Data\Default\ShaderCache\GPUCache to C:\Users\****\AppData\Local\Google\Chrome\User Data\Default\ShaderCache\old_GPUCache_000
[20644:39092:1124/205239:ERROR:cache_creator.cc(134)] Unable to create cache
[20644:39092:1124/205239:ERROR:shader_disk_cache.cc(585)] Shader Cache Creation failed: -2
Have you reviewed the permissions of the directories listed in the error message? They should share the same group and have write permissions.
This should solve the messages, but your implementation looks to be correct.
I did a todo list app a while ago using github pages. It works alright under safari, but the js just doesn't load under chrome. Why? here is the code: https://github.com/randomor/tododoingdone
What I see in the Chrome console is:
Application Cache Cached event
http://ametopia.com/tododoingdone/border.pngFailed to load resource
http://themes.googleusercontent.com/static/fonts/deliusunicase/v6/b2sKujV3Q48RV2PQ0k1vqiiT6GQZqXe56UwGtNcbg_g.woffFailed to load resource
That reminds me of the question "failed to load resource under Chrome":
It can be cause by an extension (like for instance AdBlock).
Desactivating AdBlock (even all the extensinos) lead to other javascript loading errors:
Those are displayed by the console as "others" (and not "scripts") errors.
That can be the result of some other query failing to return properly and blocking all subsequent scripts:
See for instance "jquery ajax problem in chrome".
Check your resources though, like your images (see "Resizable: Chrome dev tools console shows GET data: undefined (undefined)").