Hello StackOverflow 😀​
I'm having a strange problem with a react app when switching tabs in chrome (the app is already loaded). example : (Link to video if the gif is too low quality)
You can see there is a small white flash before it shows the site itself (something like 0.2 sec), the thing is my app is a little heavier I guess and it's sometimes 0.5-0.75 sec of white screen flash like that which is annoying customers.
Some of them describe it: 'the web page being blank for a 0.5 sec every time we go to another tab in the web browser and we get back to your app.'
I have seen some sites that have the same issue, for example, instacart.com, some of them have 0.1-sec white flash, and some of them have longer flash.
My question is how can I improve this? and what is related to this?
Most of the questions here are related to some stuff that is in react-native, but my app is react web.
I have read about FOUC but I'm not really sure if it's the issue.
btw I don't think it's related to the power of the computer (I'm getting this on a ryzen9 PC and M1 pro mac with 32 GB ram).
Thanks for help.
Also, this problem seems to only exist in chrome, in firefox it doesn't have any white flash. I guess it's related to this (see the first answer). How can I improve it?
The reason may vary. There are several ways to assess and solve performance issue(or flickering issue) with your web app.
Here's what comes to my mind:
Environment check before troubleshooting an web app
I'm getting this on a ryzen9 PC and M1 pro mac with 32 GB ram
The machine spec only holds some portion of performance assessment. It may or may not matter. because,
OS can slow down the performance due to its update issue. what OS are you using?
Web browser can cause the slowness as well. what internet browser are you using? and what version of browser is it? are you using any specific plugin or extension that may cause trouble?
So when assessing or QAing an web app, it is necessary to describe every little detail. When I was developing a Vue web app back in 2019 in a startup, there actually have been some real performance issues in production deployed environment that are bound to specific version of browser; not just that, one time I had a chrome extension causing a crash for my web app as well. Always make the reproducible environment clear unless it is exact which code section is causing the problem.
Once made the details clear, try to reproduce the problem. Does it reproduce in different browser, different machine, different OS? if not, environment is clearly not an issue.
Finding Problem with (any) Web App
If these little details are not causing the problem, it's time to get metrics inside browser.
I had no choice but to skip the environment assessment because the setting isn't clear in the question. But please do not skip that part; it is crucial. The problem might be fixable in current environment but it can remain in different environment.
Somebody already mentioned React devtool profiling in comment but I also recommend these tools:
Chrome Performance Tab
Chrome Lighthouse(previously Chrome Audit Tab)
Please try run a performance check with these tools first.
I've run a performance recording from Chrome Performance Tab and limited the scope to the flashing moment - and a slight moment afterwards.
(screenshots inside red lines are indicating white screen flashing moment)
Most Probable Reasons at the Moment
according to Chrome Performance Tab + Lighthouse audit, these problems are existing in that flashing moment.
treeshaking/code splitting is not used properly: whopping 40000 lines of code in a one file!(content.js) it should served in smaller chunks, so that the codes not important at first rendering must be loaded only when needed. check your code splitting setting first.
lighthouse also highlighted unused codes in a big chunk of single file are the biggest reason for performance dragging in your site before FCP(First Contentful Paint).
too many third party scripts: every third party code is casually lying around in the page with <script /> tag, without any performance tweaks. there are far too many third party libs running. they are not blocking the main thread as they are in async mode, but loading too many of them in parallel is definitely slowing the app. try load third party libs only when needed by inserting them dynamically.
this is most probable reason to my eyes but we need to dive deeper before drawing any conclusions.
Is it possible that this is related to Hardware Acceleration? I usually turn this off in my browsers, and I do not experience what you're explaining on the site you provided (I'm running Chrome on a Macbook Pro 2020 13" intel).
Perhaps turning Hardware Acceleration off will fix the issue?
You said that the issue only appears in Chrome, do you have any extensions that could affect the page when switching tabs? I'm thinking any extensions that reads or edits the page in any form or way.
I guess you have already tried this, but if not: could re-installing chrome and testing the sites with a fresh install (no extensions, no profile logged in...) work?
So in the end the solution was pretty crazy, we had a picture with the logo of our company in the navbar (which is appearing on each page of the app).
The problem with the picture was - whopping 35,000 px width and 5,000 px height.
You couldn't see it because it was inside a div with a fixed height and width.
The way I found that - opened dev tools, and started to delete the divs.
for example, we have:
<div id="root">
<div>1</div>
<div>2</div>
</div>
So I delete div 1, then check if the problem is still there. if the problem is still there I go delete div 2. And continue like that till you find something crazy like a 32,000px picture.
Very 'old school' but it is what it is (:
Related
My Angular 2 Application is slow to respond (1-5 seconds) to key input, button clicks, tabbing across inputs, etc. only when Chrome Developer Tools is open. Material 2 animations also become slow and choppy.
I've been developing this application for three months, and use Chrome DevTools every day. This issue cropped up seemingly overnight.
What I know:
I stashed all pending application changes to revert my application to a time when this was not a problem. The issue persisted.
Chrome DevTools doesn't seem to slow down any other application (ie. google inbox, google maps) in the same browser session.
Maddeningly, when I run the DevTools' Timeline "Record" to try to gain visibility into the issue, the issue disappears and the page reacts at normal speed again! I assume this is the best clue that I have, but I don't know the internal workings of DevTools well enough to know how "Timeline Record" changes things.
I've restarted Chrome and deleted all cached data.
Nothing of the sort happens in Firefox or IE when I open the Developer tools in those.
Any recommendations on where to look next would be greatly appreciated!
Final answer:
Remove all breakpoints
Even if they're not getting hit this fixed it for me and got performance back to normal.
May be a bigger issue if you have logging breakpoints - so try deleting those first if you're attached to your breakpoints.
Previous answers:
I came up with a workaround - although still not really figured out what is actually wrong.
I also discovered a bunch of tools I didn't even know existed that I'd skipped over before - they're under More tools.
Start by opening the Performance Monitor. This shows a nice CPU graph isolated for your Chrome tab - the Windows task manager is as useless as it ever was.
This is the behavior I got when choosing a date from mat-calendar. No other logic running - just selecting a date. I removed everything from app-component and just put a mat-calendar and it took ten seconds to change the date!
Other controls are generally fine. I could open dialogs, use combo boxes etc. and nice and fast. But selecting a date gave me this nonsense:
I tried emptying local storage, clearing cache, etc. and then I changed port number for my website. I simply changed dev.example.com:44300 to dev.example.com:44301 - in other words Chrome now thought it was a different website.
This is what it looked like after I switched port number.
I also got the same effect using a reverse proxy server - which put my local machine on the internet - so I could try to duplicate the issue from other machines. I could not.
So hope that helps someone - still no clue what's in the cache for this server that is having such a massive impact on performance. But for sure it's not just my code.
Here's a few other things to try:
Test with --aot flag
This didn't make a difference to me, but good to narrow things down.
Add some controls that don't do anything (as a control)
This way you can find if some specific action or control is causing the slow down. You should of course be able to toggle these instantly.
Just toggle them on and off, hide something.
<mat-radio-group>
<mat-radio-button [value]="false">
bloop
</mat-radio-button>
<mat-radio-button [value]="false">
bloop bloop
</mat-radio-button>
</mat-radio-group>
Enable Rendering debugging options
Make sure you aren't re-rendering the whole page constantly
The rendering option above will show this to some extent, but one thing I like to do is just add a random text box - type in it and if the text subsequently disappears you know that control has been rerendered.
<!-- yes, just a standard text box -->
<input type="text"/>
Just hide things with *ngIf="false"
Hide controls (yours and third party) and see if anything is causing problems.
For me I'm currently suspecting mat-calendar is causing issues - but I'm still thoroughly confused as to why enabling 'Record' makes the problem non existent.
I've fixed the issue, but I'll never know what was causing it. Likely a setting that I had accidentally changed.
I deleted the Chrome App and reinstalled, everything is back to normal. I'm going to leave this question open in case anyone else has this problem or wants to contribute.
It is normal for every web app to run slowly with Chrome dev tools opened.
Especially if you have inspect tab open, that it's like a new page opened in the same time + has animations on any block render.
We had this issue today at a colleagues workstation. Turned out that it was a chrome-extension (don't remember, something with "ghost" in its name). So maybe try out using guest-mode and check whether the issue still occurs. If it doesn't, successively reactivate the extensions to see which one is causing the problems. If it still occurs, follow the other proposed approaches.
I am trying to achieve a Digital Signage using Raspbian OS on my Raspberry. I set my r-pi to open in kiosk mode chromium browser and to shows a slideshow od ads and scrolling news within my web application.
I created the ads slideshow using jquery image slideshow and scrolling news with marquee html tag.
The result is jerkily scrolling news.
I think the problem is due to the couple "jquery-marquee" because if I run only jquery or only marquee it works!
Can you give me some ideas?
I thought to only use CSS3 to realize scrolling news and scrolling ads
UPDATE: You can see my work here
From normal browser it works. From chromium v.22 on raspbian-raspberry it is a disaster.
I have already choosen little images (not bigegr than 200kb) but the problem remains.
I utilised jquery image slideshow and jquery.marquee
I hope you can help me to solve this issue.
I just read a bit from http://blogs.wcode.org/2013/09/howto-boot-your-raspberry-pi-into-a-fullscreen-browser-kiosk/ and noticed:
Optional bonus Step 4: Accelerated X11 Server
Currently (Sep 2013), the default X11 server isn’t exactly optimised
for the Raspberry Pi; however, work is afoot and you can install a
work-in-progress version fairly easily. This has worked for us and has
been nice and stable. YMMV.
UPDATE: Comments have suggested possible problems with newer Rasbian
releases. We’ve not verified this either way. You don’t need to
install this, everything will work just fine without it; at the time,
we were trying to squeeze every last ounce of performance from the Pi,
so it seemed pertinent to install this patch.
The blog mentions an accellerated X11 server
https://github.com/simonjhall/fbdev_exa/ , or in particular
https://github.com/simonjhall/fbdev_exa/tree/master/releases/20130401
Maybe following the instructions on that blog link might help.
I'm making an html interface to upload images on a server with Drag & Drop and multiple selection files. I want to display the pictures before sending them to the server. So I first try to use FileReader but I have had some problems like in this post. so I change my way and I decided to use blob:url like ebidel recommends in the post, with window.URL.createObjectURL() and window.URL.revokeObjectURL() to release memory.
But now, I've got another problem, which is similar to this one. I want that a client could upload 200 images at time if he wants. But the browser crashed and the ram used was very high! So I thought that maybe too much images were displayed at the same time, and I set up a system with a waiting queue of files using an array, in order to treat only 10 files at time. But the problem still occurs.
On Google Chrome, if I check chrome://blob-internals/ the files (which are normally already released by window.URL.revokeObjectURL()) are released approximately after a 8 seconds delay. On Firefox I'm not sure but it seems like if the files were not released (I check on about:memory -> images for that)
Is my code which is bad, or is it a problem independent of me? Is there a solution to force the navigators to release immediately the memory? If it can help, this is the part of JavaScripton which the problems occurs: link expired because code was not included in question.
EDIT
This is a kind of own answer + an answer to bennlich (too long text for a comment)
I understood from the answer of user1835582 that I could indeed remove the Blob/File but while the browser needs images it keeps them somewhere in memory (which is logical). So it's the fact to display images (many & heavy) that gave me crashes & slow downs, not the revokeObjectURL method. Moreover, each browser manages the memory by its own way, leading to different behaviors. Here is how I came to this conclusion.
First, let's try that revokeObjectURL works well, with a simple example using the source code of https://developer.mozilla.org/en-US/docs/Using_files_from_web_applications#Example.3A_Using_object_URLs_to_display_images.
Using Chrome you can verify that Blob are well revoked, by checking chrome://blob-internals/ or trying to open displayed images into a new tab that will be blank. Note : to fully release Blob references, add document.getElementById("fileElem").value = "". When I posted my question some years ago, it was about 8 seconds to release blob, now it's almost immediate (probably due to improvements in Chrome & / or to a better computer)
Then, time for a charge test. I did it with a hundred of jpg of ~2.5 Mo each. After that images have been displayed, I scrolled the page. Chrome crashed and Firefox was slow (not tested on others browsers). However, when I commented li.appendChild(img) all went well, even with a huge bunch of images. This shows that problems are not coming from revokeObjectURL method which in fact works properly, but from displaying lot of heavy images. You can also test to create a simple html page with hundreds of heavy images and scroll it => same result (crash / slow down).
Finally to look deeper about images memory management, it's interesting on Firefox to look into about:memory. For example I saw that when the window is active, Firefox uncompresses the images (images -> uncompressed-heap goes up), while raw (images -> raw) is always stable (relative to the the quantity of images loaded). There is a good discussion about memory management here : http://jeff.ecchi.ca/blog/2010/09/19/free-my-memory.
With window.URL.revokeObjectURL() you can only get [Blob] or [File] object. You can not force remove from memory.
Note.
Browsers are not finalized and they can leak from these facilities. If you implement the animation, you have to understand that at your own risk.
This isn't an answer, but I just want to say that, as far as I can tell, this is still an issue in the latest version of Chrome (35). I made a test page that exposes the problem:
http://ecobyte.com/tmp/chromecrash-1a.html
If you select a large number (say, 600) of high resolution photos on your computer and drop them into the box on that page, it will crash Chrome (tried on Windows 7 and Mac OS X 10.8.5).
If you look at the source you can see that sequence of ops is:
createObjectURL
load the img (don't add to DOM!)
revokeObjectURL to free the ref
Lose the img ref
Repeat all steps for next dropped image
Seems like only a single image should be in memory/referenced at any given moment, but eventually this crashes Chrome.
I've built a Javascript-heavy web app and recently tweaked it to work on iPad (it needed tweaks because it allows drawing by moving the mouse around, and onmousedown/onmousemove would not get triggered until finger release).
Now, with the tweaks, the app runs fine on Mobile Safari. I'm seeing a problem, however, where the first time I try to load the app on the iPad, it often crashes Mobile Safari. However, reopening the browser and refreshing the page loads the app perfectly and it's fully usable. After doing some research I found out that the most common cause for Mobile Safari crash is over 6MB of pictures or multiple pictures loaded through Javascript. My app only uses images for icons, so the total image size is actually very small (probably under 100KB total), my JS code, however, is 2.5MB uncompressed and 350KB compressed using gz (which is how I'm sending it to the client).
I've also read that loading images through CSS can avoid crashes due to the image size limit. I figured it was worth a try since it's also possible the crash is due to large number of images, not just total image size. After changing some of my icons to be rendered using CSS background-image property, the crash seemed to have gone. I decided to go a step further and tweak all other icons to render using CSS backgrounds as well. After changing all of my images to be rendered using CSS, all of a sudden the crash seems to be back.
Which leads me to several possible conclusions:
A.) Even the partial CSS fix I made did not actually help but somehow I got extremely lucky and saw no crash while reloading my app and restarting the iPad multiple times (then the crash is likely somewhere with my JS code or other parts of the page)
B.) I introduced some other issue when changing the rest of my icons to load through css (if that's the case, I wouldn't expect reloading the page to fix the issue, but it does)
C.) The crash is due to something in my Javascript unrelated to images (but then why does it load and work correctly after reload)
D.) iPad chokes when trying to render/uncompress that much Javascript at once (I haven't heard of this being an issue, but it's also rare to see a chunk of Javascript this big)
Does anyone know what other issues aside from 6MB image limit can cause Mobile Safari to crash the first time a page is loaded, but not the second?
If it helps, here is the link to my web app (this is the old version that loads images through JS): http://www.grafpad.com/grafpad/canvas/demo (it's written in Pyjamas, which is why there is so much generated Javascript).
Thanks
You need to remember that compared to your desktop the iPad is seriously underpowered. Its particularly limited in memory. I noticed right away that there were many, many script blocks on the page. Without tearing your app apart completely to try and find the culprit you might start by combining, just to see if its just dealing with that many nodes that is causing the crash.
We did an application using rails(2.3.4), ruby(1.8.2), MySQL, JavaScript, jQuery. This is handling minimum 6000 records. We showing those records detail in table. In the beginning Mozilla taking 2m to load the whole page. We did the cache, eager loading, indexes. Now Mozilla taking 25s to load the whole page. But IE-7 taking 1m30s to load the page.
We don't know why IE-7 taking too much of time.
Any one can help us to detect the running time in IE-7 and tell your guidelines to improve performance in IE-7.
Any add-on is available in IE7 to see the AJAX request time taken as like Firebug add on.
Use partial loading. Don't try to load the 6000 records at once, load them in smaller segments, when needed. Even 5 second loading is too long, not to mention the 25 seconds or 1m 30s.
Oh and yeah, IE 7's JS engine just sucks.
From Table Rendering - IE Blog:
When Internet Explorer encounters a table it measures all the content
of the table before rendering so that it knows what the widths of the
columns are to render the content correctly. On the other hand Firefox
uses a different algorithm in that it renders the table contents
progressively before it has all been passed.
You can improve performance by setting the CSS rule table-layout: fixed. The renderer will then calculate the layout based on the first row of the table.
IE7 is slow, there's no real way of getting around that basic fact.
I'm going to answer your second question (about debugging tools for IE7) because I don't think I can give any useful advice on your main point about actually speeding up IE7.
Any add-on is available in IE7 to see the AJAX request time taken as like Firebug add on.
The first thing to try is IE8 or IE9. These browsers have a Developer Tools window (accessible via F12, just like Firebug). It isn't as good as Firebug, but it does do quite a bit, and it is a useful debugging tool. It also has a feature which allows you to switch the browser into IE7-compatibility mode. The idea is that you can test IE7 from the relative comforts of IE8 or IE9.
The down side is that it isn't actually IE7. It's just a pretend ID7, and not a particularly good one at that. It may or may not replicate the speed issues you're having with IE7, and it certainly has known bugs and quirks of its own which don't appear either in a real IE7 or in IE8 in normal mode.
But all that said, it might be good enough for you to run some tests and get some answers.
A second suggestion might be to try Firebug Lite. This is a cut-down version of Firebug which runs as a bookmarklet in any browser (but generally IE). It doesn't have all the features of the full version of Firebug, because there's only so much you can do without writing a browser plug-in, but it does do a surprising amount. If nothing else, it does give you the console functions, which can be a life saver for debugging.
I hope that helps.