I am going through tutorials and articles on how to achieve 60FPS for web animations. I am working on the web performance on a site and was wondering whether 60FPS is valid on the idle page too?
Eg:- While scrolling page I see theres some drop on the frame rate due to some long running script which was triggered on scroll events.
I might sound too noob here, but wanted to understand from others where all the 60FPS is expected.
So I wanted to understand more whether a good performing site should always achieve 60FPS even on idle state too?
I googled around and mostly found 60FPS was measured for Web Animations only.
From https://developers.google.com/web/fundamentals/performance/rendering (emphasis my own):
60fps and Device Refresh Rates
Most devices today refresh their screens 60 times a second. If there’s an animation or transition running, or the user is scrolling the pages, the browser needs to match the device’s refresh rate and put up 1 new picture, or frame, for each of those screen refreshes.
Related
I am building a video rendering engine and am stuck on a problem. I would like to determine the rate at which to take the screenshots.
Currently, I am setting the rate to be 25 fps. From that, I can determine the total screenshots, as an example, a 10-second video would be 250 screenshots.
for (let i = 0; i < 250; i++ {
//... i / 25 fps is what I set the HTML 5 video to be
//... this means every 0.04s or 40ms a screenshot is taken
}
The problem is that in my editor a user may combine a 25 fps video with a 30 fps video. I have found the 30 fps video will at times be choppy because the natual rate would be i / 30 which means it needs a screenshot every 0.033s or 33ms.
I am trying to come up with ways to combat this from being an issue. I would like to inform myself more around solving this problem.
As for solutions with my existing knowledge I can only think of two.
make sure every video that gets added to the editor gets re-encoded with 25fps, this could still cause issues and be problematic, since removing frames could cause jank, and adding frames is impossible.
have a variable frame rate while taking the screenshots so that when the video in view is 30fps I can change the rate of the screenshot mechanism. This poses problems when layers on top use an animation frame rate of 25 fps, or if it's next to a video side by side with a frame rate of 25.
Both solutions I can think of arent the best. So I would like to ask the folks who understand this problem the most and would like to share some of that knowledge.
Lastly, it seems the browser does a good job of handling this which tells me it's possible. Here is a screen recording of the app https://share.getcloudapp.com/KouwpkwE the first run was a bit sluggish but the second one showcases the video in the background using a frame rate of 30, then the lottie animation on top using a frame rate of 25.
When trying to capture this frame by frame at a fixed 25 I run into issues. Any techniques to solve this?
Thanks
Chrome introduced splash-screens as a PWA feature to make it look and feel more like native apps. It generates the splash-screen from name, icon and bg_color in the web app manifest. More details here:
https://developers.google.com/web/updates/2015/10/splashscreen
https://developers.google.com/web/tools/lighthouse/audits/custom-splash-screen
While all of that is fine, there is no proper documentation on how long Chrome decides to keep the splash-screen visible.
Ideally I'd imagine that it should be till the point something is meaningful painted on the screen (just the above-the-fold stuff) but in my experience it seems like Chrome keeps this splash-screen for a quite long time (might as well be till page load?)
This is pretty bad for people browsing my website from slow connections - previously at least they could see something working and happening on the screen, now they just see a static image (splash-screen with icon and name) - they don't know how long it will take to open the web app, can easily get bored and drop-off. This is very risky.
Can I control when the splash-screen goes away or even disable it altogether?
You can register an event of DOMContentLoaded, which is the first event fired, even before your other stuff like images, css and all are still getting loaded. Using this, you can fade out / remove the splash screen even (may be) before when your first paint happens (depending on your site requirements/implementation). Check out an example here, where he tries to add an animation to the fading of the splash screen rather than a simple transition. You can definitely try removing the splash screen earlier on similar grounds.
P.S.: Couldn't find anything to disable/time out splash screen. Hence the work around!
It seems that your first page is taking too long to be ready (first paint), maybe you have:
A big HTML file
Loading stylesheets synchronously
Javascript take long time to settle
Check these things see if resolving each one could help.
You can see other PWA apps, like twitter how they are loading pretty much fast in webAPK and learn from them using chrome dev-tool on your desktop.
I've found lots of information about measuring load time for pages and quite a bit about profiling FPS performance of interactive applications, but this is something slightly different than that.
Say I have a chart rendered in SVG and every click I make causes the chart to render slightly differently. I want to get a sense of the complete time elapsed between the click and the point in time that the pixels on the screen actually change. Is there a way to do this?
Measuring the Javascript time is straight forward but that doesn't take into consideration any of the time the browser spends doing any layout, flow, paint, etc.
I know that Chrome timeline view shows a ton of good information about this, which is great for digging into issues but not so great for taking measurements because the tool itself affects performance and, more importantly, it's Chrome only. I was hoping there was a browser independent technique that might work. Something akin to how the Navigation Performance API works for page load times.
you may consider using capturing hdmi capturing hardware (just google for it) or a high speed camera to create a video, which could be analyzed offline.
http://www.webpagetest.org/ supports capturing using software only, but I guess it would be too slow for what you want to measure.
I was having an issue with Chromium redrawing a page, and I noticed in the timeline that Recalculate Style was firing at what I think is a really high rate:
Note that this event is firing at this rate (5000 or so per 30 seconds) the whole time the page is open--idle or not. I'm curious if this is normal, but my question is:
What causes/fires events that the Chrome Timeline doesn't display a stack for?
This question is related, but not exactly the answer I'm looking for because I know what Recalculate Style means, I just don't know what is causing it.
Sometimes when I Inspect Element in Google Chrome I find that I have some large frames, but they are filled with white space. Anyone know what often causes such large amounts of empty space? I have seen timers cause issues with extending the frames length but in the example below I am unsure why a frame would be so large.
Would love some help minimizing these
This is documented here, see the 'About clear or light-gray frames' section. 'Clear frames' in question are described there as
Idle time between display refresh cycles.
According to this video, clear bar indicates browser waiting for a CPU or a GPU. There is nothing that developers can do to fix this when working on a 'standard' website.
I found some interesting relations and i hope it will save time for someone (I spent lot of time before figure out all of this)
Most important - chrome devtools cost a lot. A mean A LOT, even if it says nothing about it. For example:
"Screenshots" in performance monitor increases frametime from 16ms to 66ms in my case and just fills it with empty space in timeline - without screenshots and with screenshots. (Now i see long operations on GPU with screenshots, but there's no any info about what exactly particular operation did)
Things in "rendering" tools like "paint flashing" or "fps meter" greatly increase painting operations time. Just be sure that you disabled all of this before analyze performance!
Very strange things happens with "other" segment(Grey color on timeline). It suppose to be devtools cost itself, but sometimes it can randomly be around zero with lot of calculations or be on 100% wile idle. My advice - there's new "performance monitor" tool in new chrome versions (Not simple "performance"). It is better to toggle it on and keep an eye on "CPU usage" timeline. If you see unexpected behavior of gray curve just reload page or whole chrome - it may save lot of time for you.
Some extensions may cause random effects on timeline. It better to disable it too.
Actually any thing in tools or extensions may ruin your measuring. Toggle all of it off before start search out issues in you code, dom, or styles