I am facing performance issues with Tabs Panel for IE9 (and above) if I even open just 2-3 tabs with HTML document of size varying from 1MB to 20MB. Then on switching between tabs it’s taking around 3-4 seconds (when page has only tab panel) and around 5-6 seconds (when page has a lot of other extjs components) on IE-11. The response is almost 1-2 secs on IE8 which is very surprising.
I also tried with different hideMode options (Display, offsets, visibility, asclass) but with not much benefit although hideMode='asclass' is comparatively fast than other options.
I also created a sample page to confirm if it is really document size issue or extjs component issue. Created simple tabs (with divs) without any JS library and just changed their css z-index (instead of css display or css visibility) and they were switching instantly (on all IE versions). Trying the same solution on a separate page for ExtJS doesn't help on IE11 (somewhat faster on IE8). So it seems to be ExtJS specific issue.
Has anyone else ever faced this issue? Any comments or solutions would be greatly appreciated.
You can use the profiler for IE to see whether any scripts related to ExtJS 4.2.1 take a long time to load. If you discover such a script, you can then proceed to making a bug report for this library.
Here's some detailed information of how to do JavaScript profiling in IE.
Profiling JavaScript performance
Related
I am using Masonry 4.2.2 (current version) by David DeSandro that is bundled with WordPress.
When I put images into it that have "srcset" and "sizes", it loads the proper size, BUT ALSO the maximum version -> a lot of wasted data. Happens in both Firefox and Chrome.
I made a simple set of two test pages (= deleted almost everything else), so it is simple to compare that behaviour:
1)
https://www.pastel.cz/temp/test_gallery_simple.php
Masonry initialization commented out, in Inspector I can confirm that only single size is loaded. For my browser window around 2 MB is transferred.
2)
https://www.pastel.cz/temp/test_gallery_masonry.php
Everything identical, only this time Masonry is properly initialized at the end. A lot of new image versions are loaded, for me it is over 7 MB of downloaded data.
Is there a way to Am I doing something wrong here? Or should I report it as a bug? Thank you for any pointers.
Known issue
I think I found the answer, it is a known bug of imagesLoaded - a library that is used together with masonry to react on lazy loaded images. The bug is open from 2015, probably not many people noticed the behaviour :)
https://github.com/desandro/imagesloaded/issues/175
Workaround
Anyway, since I specify the image sizes in advance in the HTML and thus the grid can be fully constructed during the init phase without loading the actual images, it seems that I can disable the imagesLoaded library and the issue vanishes.
I am currently building a site. When I refresh the page (as seen below), the two boxes with the brown outline start out at what seems to be 100% width, but then they re-size after about 1-2 seconds, and there is a small gap on the right hand side.
I'm pretty sure this isn't happening via the CSS, as there is a delay and I've looked through it all myself and can't find anything.
I am using Google Chrome's Developer Tools - is there any way that I can view any related JavaScript being ran on refresh that may be affecting these elements?
You can use a chrome extension to quickly turn off javascript. If the problem dissappears, you know that javascript is causing the problem. If the problem is still there, then it is a CSS issue (which I think is the case, but we can't solve that for you as you didn't provide the code).
here is a link to the javascript switcher extension:
https://chrome.google.com/webstore/detail/quick-javascript-switcher/geddoclleiomckbhadiaipdggiiccfje
I am using handsontable 0.18.0 version in my application. In the handsontable we are loading collection of data in tree view form, We can expands their childs. If we expand the childs and update any particular cell, we are facing performance issue (it takes almost 20-30 secs) in IE browser, but in chrome it is 3-6 seconds. Without expanding nodes it will take around 3-5 Secs., only.
Can anyone suggest how to overcome this issue?
Thanks in advance.
One of the issues with IE is the way the virtual rendering occurs. The reason chrome and other browsers are so fast is that Handson uses this type of rendering to only show the rows in your viewport. It is a known issue which is why if you look at the compatibility table, it says IE is known to have "Limited ability to handle large amounts of data".
The solution would be to upgrade your browser or try to implement a type of virtual rendering yourself. The latter can be daunting but the only solution, unfortunately.
On this website (tested in close-to-latest
Opera, Firefox and Google Chromium on Mageia Linux 3 Cauldron and on Firefox on my Arch Linux VM), the expanders/[+] signs of the navigation menu on the left get shifted a little
upwards and downwards when the sub-menu is expanded/collapsed. That's not the case if the expander in question the last one in the sub-tree (for example, under "Humour" →
"Recommendations").
Why and how can it be avoided? Is it because of the different character in the text? I tried setting it to monospace - it did not help.
It works fine here, but the CSS and generated
DOM are different.
(Note: this is my permanent site while this is the
temporary/testing one. They look mostly the same now, but do not use exactly the same markup, CSS and JS.)
The problem is that I'm trying to make jqTree look more like what I had in the old
jQuery Treeview, and it won't cooperate. I spent an entire day on it yesterday,
and while I fixed many problems, I still have this one.
I tried using Firefox's Firebug, Opera's Dragonfly, and the equivalent tool in Google
Chromium has, but I lack the necessary skills to understand what goes wrong.
It appears that the jQuery Treeview authors tried to optimise performance by using a single image with a different background-position which makes it hard to debug, and I didn't get rid of it yet.
Any pinpoint to the problem, and/or a fix will be appreciated.
I have a problem where Mobile Safari crashes when loading and manipulating the DOM with jQuery when the pages get too big.
I get the same problem on both iPhone and iPad.
What are the best way to troubleshoot mobile pages to find the error? Are there any known problems that might crash Mobile Safari?
I actually found the problem. It wasn't with JS as I thought, but with the CSS. I added class to make a CSS transition to fade in some elements. For anonymous users these elements had display: none; and probably never ran the opacity transition.
The strange thing is that the transitions was on exactly two elements. So why would this only crash on long threads with 100+ comments?
So the bottom line is: -webkit-transition crashed the page on mobile safari.
Had the same issue, for me it was -webkit-transform: translateZ(0); that caused the crash of Safari.
I know this question has been successfully answered but I just wanted to put my five cents in too as I have been banging my head against the wall over this one quite a few times:
As most answers have pointed out already it usually comes down to memory issues. Almost anything can be the last bit that finally tips over the "memory pile" much like a translateZ or anything else.
However in my experience it has nothing to do with the actual CSS (or JS) command in specific. It just happens to be that the last transition was one too much.
What tends to help me a lot is to keep anything that is not visible at this time under display: none. This might sound primitive but actually does the trick. It's a simple way to tell the renderer of the browser that you don't need this element at this time and therefore releases memory. This allows you to create mile long vertical scrollers with all sorts of 3d effects as long as you hide elements that you are not using at this time.
The main issue with any iOS app is memory usage. So, it is likely that your pages are using too much memory.
Mobile Safari use some clever technique so that not the whole page has to reside in memory at any given time, only a portion of it. Maybe you could check if anything in your page defeats this mechanism or makes it less effective.
In any case, to give more up to the point suggestions, more information about your page would be really great.
By the way, you could have some hints from the crash log that the device store. Check to see if you can find it under Settings:
General
About
Diagnostics & Usage
Diagnostics & Usage Data
If it's a memory problem, you should find something like "signal (0)"; not sure if this can only mean "killed due to memory usage", but I usually take this for granted when I found a signal (0).
Otherwise, it might tell you what is wrong...
Hope this helps.
There are both memory limits and Javascript execution time limits, though it's a little fuzzy as to how you may actually hit those. Common reports come in that a page with a size greater than 10MB will have issues, and Javascript execution is limited to 10 seconds.
See Apple's documentation for more info.
I recently had an issue with mobile safari crashing on web-app pages containing a lot of images (30+ were enough) and a few transformations for the menu. After a lot of trial and error, I settled with a solution similar to what LinkedIn does, but for infinite scrolling using angularjs. I used requestAnimFrame and two expanding/shrinking divs (with js style attributes) on the top and bottom of the list to remove all image containers (with other stuff overlayed on top) except for a few ones which are close to the viewport. Scrolling performance (native, no js) is fine and memory consumption is in check.
I had a similar problem, the web page worked like a charm on android devices and crashed on IOS (iphone and simulator).
After a lot of research (using also the ios_webkit_debug_proxy) I found that the problem was connected to the jQuery ready event.
Adding a little timeout solved the problem. My application was also using iframes.
$(document).ready(function () {
window.setTimeout(function () { ready(); }, 10);
});