I'm using jQuery .scrollTop to scroll image within a div. It works great in Firefox - scrolling is very smooth and fast. In IE 8 scrolling is very slow and glitchy - image scrolls once in about a second - two seconds. Image size is on average between 2000 * 2000 and 4000 * 4000 pixels.
Is there a way to improve this for IE 8?
Performance in IE 7 is slightly better, but still not good enough.
Thank you
Edit: I believe that an issue is in how scrolling is implemented in IE 7 and 8. I have enabled both scroll bars (overflow-x and overflow-y), and I have tried scrolling an image using these scroll bars. Issue is exactly the same. I've tried running this on a fairly underpowered PC - pentium dual core few years old with 2 GB of RAM as well as Core i7 desktop with 2.8GHz CPU 1600Mhz RAM and the results are nearly identical. FireFox scrolls a lot faster, however its CPU usage on average is 10% higher than IE CPU usage. This leaves me puzzled...surely Microsoft would have addressed this issue by now?
Another thing that I have found slightly odd is that scrolling ran faster on a Core 2 Duo laptop. I'm wondering whether this has anything to do with graphics card drivers...does IE 7/8 even make a use of GPU?
Excuse me if any of this sounds silly, but I'm really interested in solving this problem...IE can't be that bad..
jQuery's .scrollTop() is notoriously slow in ie, and if the markup is even slightly complex or large, you'll never get it to perform well.
The solution is to not use the jQuery .scrollTop() function, but build your own based on the native properties .scrollHeight and .scrollTop.
The reason is the way ie computes offsets, which is the base of jquery's .scrollTop() slowness - you have to walk up the DOM tree and calculate offsets for every parent in ie.
jQuery does this the best it can, but you will always be able to do it faster since you know the markup in advance and can optimize this - you can even do the offset calculations in advance most of the time and just use a constant as modifier.
All that said, this might not be jQuery's fault - it can simply be a problem with ie's rendering pipeline - depending on how you made your marklup and styling of it, a scroll might force ie to completely rerender/repaint the page for every pixel you scroll, and that will slow it all down to a crawl.
Related
I am building a website for me and I care about performance, speed, user experience and a lot more. When I started I didn't know much and I made an initial design using adobe xd. Then using webexport plugin I got a html file that has 2k+ lines of codes for scale to fit any screen and proportional resize of everything. I think I made a 1080p standard artboard but somehow it was way too big like 3554px by 2216px. So the webpage is now that big and scaling is running on it. I don't think it's too big for a browser to handle. Things were good before chrome 97 or 96 update. After that chrome and any browser running on chromium just can't scale my webpage fast enough to fit the screen. I see big divs getting smaller and it takes kinda like 500 ms to settle with decent setup. A lot of variables can affect the performance like if the machine(pc) and network is slow the scaling takes couple of seconds which is too much.
Is there any way to hint the browser to do the scaling first then make the page visible? The older version of chrome was doing it right. I can make the page visible after 600 ms using setTimeout function but doesn't seem what I want.
CSS
will-change: transform;
Tried this but it has bad effect like blurry text on my content. I don't know why it's pushing the browser to it's limit sometimes, maybe I can better optimize my page but these browsers should be more powerful (safari is the worst - can even render the webpage)
This is the home page
https://elomymelo.com/
You should see big page fitting inside the screen and it'll probable take 200 ms pretty fast
proportional resize on window also works
This is a heavy article page
https://elomymelo.com/oneplus%20nord%20review.html
I tried to hide the scaling effect in this page but not satisfied because browsers mess up sometimes. I need the javascript scaling done much faster like visitors will not see that weird transition.
to be honest, i'm a little bit desperate.
After my Google Chrome Browser updated – from i think Version 39 to 41 – one of my clients websites is absolutely disfigured in Chrome.
You can see it here:
http://prinovis-media-day.com/
If you scroll down, all the »parallax« elements are flickering.
I've checked it on my macbook on Version 39 — it's absolutely fine in Version 39.
Basically, what i'm doing to create this effect is very simple:
$("window").scroll(function(){
var move_value = Math.round(scroll_top * 0.3);
var opacity_value = *some other value*;
$(".parallax-container__content").css({
'opacity': opacity_value,
'padding-top': move_value +'px'
});
});
Does anyone know whats the matter? It worked like a charm before this update...
Thanks a lot in advance, i really appreciate any answer!
Moving my comments to be an answer:
You could always cache the $(".parallax-container__content") element
in a variable so that it is not retrieving it on every time the scroll
event is fired, and that goes for the opacity value too (unless that
is dynamically changing depending on scroll_tp. Doing this might cause
the script to speed up and help the jank that is happening
If it is still really noticeable, then you could use feature detection
to detect if CSS transforms are supported in the browser and user
'transform: translate' instead of changing the 'top' value. If it is
not supported, then just revert back to changing the 'top'. Changing
the 'top' causes a repaint in the browser while 'translate' does not.
This repaint is quite expensive to the browser and can cause jank on
certain machines. modernizr.com can help you out with feature
detection, but it is potentially overkill for just helping out in the
this situation.
Have a look at this for detecting cetain styles are supported: http://lea.verou.me/2009/02/check-if-a-css-property-is-supported/
this is the easiest way to check (remember to account for vendor prefixes).
I'm running an animation using Kineticjs using the Animation module. Now I noticed there quite a big performance difference between Chrome and Firefox. Looking at the framerate I found the following results.
Chrome Firefox
avg: 50 50
min: 33 20
max: 56 75
As you can see, the variability of the framerate for FireFox is a lot bigger. The animation in Chrome is smooth (at least smooth enough), but the animation in Firefox is choppy every second or so, this happens when the framerate is very high or low.
Especially the high framerate spikes seem to ruin the appearance of a smooth animation.
Has anybody else experienced this behaviour? And is there a way to smooth the framerate out a bit more in Firefox?
This could be due to browser tab architecture differences, such as the fact that currently Google Chrome uses a separate process for each tab, so slow or bad code in one tab is far less able to affect code in another tab. With Firefox tabs are run in the same process, so slow code on one tab can affect other tabs.
This could also be due to browser performance differences, meaning the implementation of DOM and Javascript APIs that you are using.
is there a way to smooth the framerate out a bit more in Firefox?
You should try to find some causes for the difference in the framerate, process of elimination is probably the best path.
Try using the browsers with only one tab, and go through the list of apis used to see if there are performance differences for those.
I just finished a website: http://www.basenharald.nl and all is good in IE9, chrome and firefox.
It does not support browsers < IE8, but that is planned.
However the website is really really slow in IE8 and for some reason some people encounter that the scrolling divs do not work (not all IE8 users).
Any help on these issues would be greatly appreciated since i cannot locate the problems.
Because IE8 just renders these animations VERY poorly. Also slow PC's will have issues with the animations.
You should detect IE8 (and lower) and disable those effects, because they are not functionally necessary
First of all well done on a good looking site. I have used Developer Toolbar in Chrome to detect the following problem. Your site uses or reference a page called daddy-shoutbox.php. This code in this page or calling code to this page is causing a infinite loop or continues call. From my results I could see that that page takes on aggregate about 500ms to load.
From the browser perspective I can only assume that IE8 actually shows the symptoms of this loop. My stats showed that the page has made over 130 requests and counting after 2mins.
Not modern browsers and, as douwe said, even slow PCs will be affected.
The parallax animation requires lots of CPU time and the effect is mainly related to the aesthetics of the website.
A good compromise between usability and aesthetics could be achieved by reducing the parallax effect.
I suggest you to remove the effect from the text ( class: contentwrapper). It will save you some CPU time and it will give you a more readable text.
You could even switch to a normal scroll bar. For my experience, customized scrollbars, always give some trouble with the users ;)
If you are happy with the experience on the modern browsers, you could simply discriminate older browsers.
With jquery you can use this
good luck
In Opera 11.52 it doesn't load at all..
It seems that the following setup on jsfiddle only runs smooth in firefox 4.
http://jsfiddle.net/ynytc/39/
Im wondering why?
I thought maybe because of the hardware acceleration in firefox 4,
but without it still runs smooth.
So maybe someone knows why?
edit: compared to chrome,safari,ie8
You're animating over a 10 second period a change in size of only 20 pixels. That means that there's going to be only one integral dimension change every 1/2 second, which is exactly what I see in Chrome. The size of the image can't be set to fractions of a pixel (in all browsers). Firefox 4 seems to allow that, however; that's the only thing I can imagine anyway.
If you change your fiddle like this you'll see that Chrome is running the animation as fast as you could want it to, but the image only shifts when there's a whole integer change in the property value (width and height).
This is an interesting side effect that I hadn't encountered before.
It seems that other browsers can't apply subpixel scaling, so you only have 20 pixels to spread in 10 seconds, coming to a glorius 2 frames per second. The workaround for this would be to apply CSS transitions (if you don't need to support IE).
See example with CSS transitions here:
http://jsfiddle.net/nKfdB/