A website I'm currently designing displays and works perfectly in all mac browsers, and Windows Firefox, Chrome and IE 8.
I'm having major problems in IE 7 though. Whilst the CSS is pretty much there (a few tweaks needed), the site is maxing out my CPU at 100% rendering the site almost unusable and giving me scripting errors and javascript functionality is not working.
I don't even know where to start trying to find out what's maxing out the CPU, or how to get more info on the scripting messages - it tells me the line the problem is on but it doesn't tell me what file.
I'd like to provide a link but the client has asked me not to.
Any help would be greatly appreciated.
Thank you
Most likely, this issue is caused by ie's poor png rendering capabilities. In the situation that I have experienced, we were using jquery ui 1.8.7 to render modal dialogs and seeing the memory usage spike by 6-8 mega every time a dialog box was opened. It turns out that the culprit was the opacity and alpha CSS settings in the default jquery styles. See this post for a possible partial fix.
Other things to note include:
There seem to be many fixes that attempt to address this issue.
Jquery 1.8.16 has a partial fix where the large memory jump will only happen when the first dialog box is opened.
We have also experimented by setting a single pixel png as the modal background and this rendering of a single pixel caused the memory used by IE to spike 80 megs and caused a temporary spike in CPU usage.
One other peculiar observation was that if we set the modal value of the jquery dialog to false and created our own modal background by appending a div whose background was set to a semi-transparent png, the memory leak seemed to be smaller.
The short of it was to stop using transparent pngs and the opacity and alpha settings foe rendering in IE.
Related
I built a calendar component using Adobe's #react-aria & #react-stately hooks that I want to use within a Dialog on mobile (which is built using #radix-ui/react-dialog). The problem is that whenever the user selects a range, the whole dialog "jumps" a bit, almost like it zooms in, which causes part of the content to go off-screen to the right (despite having fixed positioning with right: 0 property). This is reproducible both in Chrome Device Mode (under 450px in width) and when testing on actual phones (in Chrome but not in Safari). This is how it looks:
After scouring the internet for a solution, I cannot figure out what's causing this. I found no styling that could affect this or code that could be the problem. The only thing I found that fixes it completely is adding the user-scalable="no" parameter to the content of the <meta name="viewport"> and I don't want to do this because of accessibility. My best guess after looking at the source code of both libraries is that it has something to do with both of them doing a lot of stuff under the hood to keep things like focus in check but I'm stuck.
Here's a codesandbox sample of my setup, where the issue can be observed (the app needs to be opened in a new window and then put into Chrome Device Mode to reproduce it!).
Any hints that might help me track down the issue are appreciated.
I am trying to build a Wordpress website using a theme I purchased, unfortunately the maker of the theme doesn't seem to respond to any support requests.
After creating a few pages I noticed that performance is much worse on Safari compared to any other browser. I tested this on a few computers and few versions of macOS.
Example page is https://sochacki.info/proj/nepal-manaslu-circuit/
I realise that photos on the website are quite big (4000px each), but that is exactly what I want. I am happy with how quickly the pages load and how the galleries work, in Chrome, Firefox or Opera. When you click on a picture it loads PhotoSwipe JavaScript gallery so you can see them in full size, and then you can also click in top right corner to go full screen as well, or to leave the PhotoSwipe viewer. Switching between photos, going full screen or leaving PhotoSwipe are instant.
However when I load the same page in Safari, any action after clicking on a photo is slow. Switching between photos, going full screen, leaving full screen. It all takes a second or a few seconds. I can also see in Activity Monitor that CPU is used way more in Safari.
I tried a couple of things:
the theme I am using uses a custom plugin made by the same author to create these galleries, place photos and it includes PhotoSwipe files inside. Those files were one version behind (4.1.2 instead of latest 4.1.3) so I updated them, but the performance issues are the same.
I installed some other gallery plugins which use PhotoSwipe to display photos, and they did not have the performance issues, so I am not blaming it on PhotoSwipe, probably some other part of the plugin is causing the issues.
I have no real experience with JS or web development, are there any tools that could help me find what is causing the slow performance?
I checked the website speed - as I can see the Theme-Loading-time is okay. But as you already mentioned the Photo-sizes are really unfortunate as we can see in google page insights (https://developers.google.com/speed/pagespeed/insights/?hl=de&url=https%3A%2F%2Fsochacki.info%2Fproj%2Fnepal-manaslu-circuit%2F)
Try to resize the Photo-sizes in normal view (not the HeightxWidth > the kB)
I'm developing a BI dashboard for a business app using the JavaScript Kendo UI version v2014.1.416, but I'm having a problem with some visuals in IE11.
I want to point out that due to real-world constraints, running IE11 is for all intents and purposes set in stone. The Kendo version number is somewhat easier to deal with, but still no picnic.
Specifically, I use the kendo.fx.flip() function to display a flip card. The card flips ok, but the "back of the card" is rendered before the flip animation starts. In contrast, the same effect in Chrome and Firefox plays out as it should, i.e., the back is shown halfway(-ish) through the animation.
I had a look at the API reference page for the flip effect, at http://docs.telerik.com/kendo-ui/api/javascript/effects/flip. As it turns out, the reference page example exhibits the same behavior in IE11.
I'm guessing the effect uses the CSS3 flip function under the hood (haven't looked yet though) and this seems to be somewhat of a general problem given the amount of questions regarding flip in IE.
My question is twofold:
1) Is there a way to "fix" the animation specifically for IE, using the provided version of Kendo and/or using regular CSS?
2) Is this effect fixed for IE in later Kendo versions, in spite of the behavior on the API reference page?
I could only get this to look nice by setting a large no-repeat fixed background image on both 'sides' (made out of a simple white png).
I'm facing this problem only in chrome. When I scroll up and down, I'm facing lag. This only happens in Chrome browser and I have the latest version. Website is based on PHP framework. Could anyone please identify the problem? Is there a problem with the website or the browser? Here is the website link: http://airfuz.com
Thanks in advance.
I would say that one cause is the massive image in the center. (the guy with the google glass) - this image is more than 5000px X 3400px+ but scaled down to around 500px. Which is together with other large images on the page. http://airfuz.com/Images/2014/05/man-wearing-google-glass.jpg
when i remove that image, it scrolls much smoother...
Consider using a php thumbnailing script (like timthumb or phpthumb) to actually serve images close to the size they will be shown. This will also benefit the load times of the site.
Your website has too large assets that simultaneously loads. Maybe that is the cause of the problem. Here's why I've concluded with this answer:
When the website's assets are loading, the scrolling lags. (Tested with Chrome & Firefox)
After the website has fully loaded, my Google Chrome shows less lag. While on the other hand, Firefox showed me no difference at all.
You could shrink down some assets, I think that will, somehow, lessen the lag.
And I noticed something about your website, you are using the HTML5 Doctype. However you are also using HTML4 Mark-up Tags (I saw the <center> tag). Well, this might not affect the problem but this will affect HTML5 Validity. =)
Well, hope I helped somehow.
Google Chrome notorious bug Issue 753053
The issue discussed in this question happened to me with a production site, but in addition to Firefox, we saw it in IE.
This is how it should look, with all three fading to different pictures intermittently:
We got these screenshots from clients:
Abmormally small images:
Weird sized images:
We were able to reproduce it reliably with Firefox with a hard refresh (ctrl-f5), but the only one in our office that could reproduce it in IE was running IE8 on Windows 7, and then not reliably. The client was using IE7, I believe on XP.
I fixed it by setting up the slideshow in $(window).load() instead of $(document).ready(), but I never figured out why it was so hard to reproduce in IE. Management is unsettled by the fact that we could not reliably reproduce it in IE or explain why it happened, and I've been asked to investigate.
Does anyone have an idea? Does the same issue discussed in the linked question apply to IE in certain circumstances? All I can say at this point is "we can't always pin down things like this."
UPDATE: I was able to make it happen reliably in IE by not setting the src attributes in the slideshows until after I set up the slideshow in Javascript. I think this proves it was indeed the same timing issue, just happening more rarely because IE is a different rendering engine. Management is still curious what other circumstances intervened, but I'm confident now that it was indeed a timing issue in all browsers, and our production site is safe from further issues.
Also, I asked the same question on jQuery forums here and was told to explicitly set image sizes in the img elements. This also fixed the issue.
It's explained in the link you posted. It's a timing issue. Sometime the cycle starts early, sometimes not. And 'sometimes' may just be 'almost never' in some browsers.
Starting the cycle in document.ready ensures that all images have been loaded before the cycle starts so the dimensions are properly detected.
It can very well depend on CPU speed, network latency, browser, OS and whatnot.
The reason it's so hard to reproduce consistently is because the environment is very complex, and the results depend on things you don't see right away.
I know this is late in the game, but I, too very recently experienced this problem. It drove me nuts. The solution is, in fact to use the $(window).load event method to start the cycle plugin--it guarantees that all associated page-load activity (including any downloads associated with ANY child elements) is complete before it fires. It works in all of the 'big five' browsers.
In my case, I am displaying images of different sizes and aspect ratios, and populating the image list automatically by using a server-side script to populate a variable containing dynamically created tags for all the image types in a designated directory that I tell it to include. Consequently, I can't include the image width and height in the tags, because I don't know what they are. In order to get around this, at the client side I use cycle's onbefore: to fire a script that dynamically looks at the image being processed and then sets the slideshow container to a width and height matching the photo's native width and height. I display a "Loading xx photos..." message with an animated GIF loader graphic so that the user knows something is going on while the images are downloaded.
The slideshow(s) in question reside in an area on the hangmanhills.org website that is restricted to Hangman Hills Residents' Association members only, so I can't show you the end product.