I have a design I'm creating in CSS, and it has started to sort of, er, lazy scroll. By that I mean the scrollbar lags a bit when you are scrolling. What are common causes of this so that I can debug it from my site?
EDIT:
The document has very little content (not even a paragraph), so not much at all. No flash, two images.
EDIT:
I feel so stupid. Improperly formatted background: property was causing the issue. Thanks nonetheless, everyone.
It's likely to be due to heavy processing requirements via css.
(CSS does affect scrolling in every browser) I have seen this scenario many times (the worst case is with SVG). It usually hits browsers like Chrome hard because of it's AA.
There was a great website that detailed the heaviest to the safest properties to use in regards to CSS effects, sorry I don't have the link. Though from my experience I would say to consider:
Gradients: The more you feature or the larger the area they cover the more exponential the rendering calculations. Abusing stops and additional colors also adds to the mayhem.
Border-Radius: Is usually clipping off its internal content whatever it may be. I've noticed differences when excluded.
Opacity can be the main issue if coupled with other css effects. In certain scenarios I've found great improvements when removing opacity or reducing it's usage. As it's not just transparency it's driving it's also for some browsers anti-aliasing text.
Images: The way images can affect scrolling should be obvious, though I've discovered re-sizing imaged from it's native resolution can become a more noticeable factor.
Use of properties such as background-size:; draws huge power in certain situations, a workaround could be to scrap the div, replace with < img > and overlay with a blank div
containing text/ content.
Animations transitions & translations are obvious power eaters if abused, especially animation that loops continuously or re-sizes to the browser via percentages.
Bare in mind someone on a low spec celeron PC will have a terrible experience on a site that lags on your reasonably/ high powered PC/ mac
Related
This is going to be difficult to ask because I cannot for the life of me produce a standalone example despite my best efforts, so I'm going to have to hope that someone is already familiar with this problem. Also, this issue doesn't seem to occur with system fonts, but does with fonts like Inter.
I'm using the Inter font on my website. It looks great but there is an issue where sometimes the text is rendered as bolder than it should be (it also sometimes momentarily flashes bolder during hover events). Eventually I figured out that I can fix this issue by applying the backface-visibility: hidden attribute on elements afflicted with this issue.
It seems random as to what elements it affects. The vast majority of the website works fine, but occasionally I'll find a tag that has this issue and I have to slap a backface-visibility: hidden attribute on it to fix it. Also, this doesn't happen on all browsers and operating systems. The issue is non-existent on Mac devices from what I've seen. On Windows it will sometimes appear while hovering over elements, etc.
Alright, so why not just apply this CSS rule to the root document so it applies to every element? Performance.
Apparently this rule forces some sort of GPU acceleration of some sort? I'm not entirely too clear on the details but the FPS on my website tanked when I applied this globally. However, there is still the issue where the few remaining tags it is on can cause FPS performance issues if there is enough of that element.
So my question: what is causing this, and is there a performant fix? I cannot simply apply backface-visibility: hidden to every element because it destroys the performance of my website, but even applying it to the few random elements that pops up causes performance issues. What is causing some elements to randomly have this weird bolded text effect?
I found this post which seeems to reference the flickering and the use of backface-visiblity hidden and its corresponding performance issues, but no solution as of yet.
Edit: After performing additional research, it seems that it's not just backface-visibility: hidden which fixes it, but any CSS property that elicits hardware acceleration. So, putting transform: translateZ(0); onto the element also fixes it, but also has the performance issues. What is still needed to know is why this graphical flickering happens with fonts like Inter but not system fonts, and only on some operating systems and browsers. Also, there seems to be some interaction with hover events that cause absolutely positioned elements to become visible causing later elements on the page to flicker.
I think you add this code
-webkit-transform: translate3d(0, 0, 0);
to the flickering elements, and thus rendering them in 3D on page load, they no longer had to switch.
This is the reference article.
The problem has to do with the rendering of those specific elements on the page. The parent elements in which those texts sit should be even numbers large (same even numbers).
Just make sure total height remains EVEN and adjust margins and paddings accordingly.
So I am making this horizontal scroll site which has a ton of images. I planned on using svgs for the entire site, but with only 20-30 svg images of medium to high complexity used in the page, and chrome already seems to be showing som jank and high paint times for scroll (and firefox is even worse, though safari seems to do a lot better).
Scroll timeline
View the site (scroll works on mac only, windows users can use arrow keys)
My question is, if I were to use pngs instead of svgs, would it reduce the paint times and hence the jank? Why is the browser struggling with only around 20 odd svg images?
As was my doubt, the problem turned out to be something completely different. Browsers are more than capable of handling multiple vector images. But what they aren't good at (and understandably so) is at redrawing those images very often.
Problem
My long horizontal scroll site was quite wide (30,000px). I had a background-color property applied to one of lower z-index'ed div's to represent the sky throughout the scroll site. I didn't want the sky to stretch the entire 30,000px since it essentially didn't change much, and hence gave it viewport width and height, with:
position:fixed;
Not a very smart move. Turns out that this property was causing my document layer to be repainted on every frame. Initially I though it was normal for browsers to do so on scroll, since Robby Leonardi's site, which I used as reference also repainted every frame.
Solution
Thanks to this article by one of the chrome dev tools developers, I set aside conventional wisdom, and make the sky layer
position:absolute;
and stretched it the entire site width, and boom! The paint rectangles were gone. And the scroll performance was smoother than butter.
Other solutions I tried
Hiding elements not near the viewport to make painting lighter, as suggested by #philipp, but didn't yeild any appreciable difference. Also, it felt super-hacky, and it wasn't targeting the root cause of the problem.
I tried modularizing my site into scenes and using translateZ(0) hack on each scene so that only the smaller scenes get repainted instead of the document. This actually helped quite a bit, and scroll was decent. Then,
I gave all the svg images their own layer by using translateZ(0). I started getting FPS of around 60 now, but again, this wasn't the right way of doing things.
I once had a similar thing. The SVG was 10 or more times as wide as the one shown above, it contained ~20k elements and was about 3MB in size. The only Thing what brought back performance (since it was a jump and run game) was an algorithm which was able to find all elements whose bounding box overlapped the viewport. With this I could use display: none; to hide everything what is invisible.
That reduced the amout of visible elements to ~150 per frame and the game ran again fluently.
I used a balanced binary tree (avl tree) and a one dimensional range query, since the height of the viewport was always the same as the image.
Good luck!
[EDIT]
Forgot to leave something like an anwer. From my Experience are large/huge SVG Graphics a bottleneck in rendering, especially if there is a lot of scripting happening. If you do not need any Interactivity with the elements from the Graphic, so nothing than a large Background Image, I would recommend to use a Tile map, based on PNG images, that is the standard way in Jump'n'Run games with huges »worlds«, so you can gain perfomance in two Points:
Rendering is faster,
You can »lazy ajax load« tiles, depending on visibility, to prevent users to download the »whole world« at startup.
Additinally you could use something like PIXI.js to render with WebGL, what will push the performance drastically and with it comes support for Tilemaps and Spritesheets.
If you insist on the advantages of Vector Grafics (Scaling, Interactivity) than you need to find a way to hide as much elements as possible to keep the frame rate high.
This might be a poor question for this exchange but is it worth styling for zoomed out browsers? For instance, I can zoom chrome out to 25% and my navigation breaks, should I accommodate for this or will 99% of cases be fine without the extra effort in styling? What case would I run into problems like that?
25%? I wouldn't worry about it unless you have a use case for your page where your users will be that far out.
Now, 75%-125%, you might consider it. Usually your page will work fine at other zoom levels. If it doesn't, it's likely because you have hard-coded something you shouldn't have. (For instance, you might assume that text on a certain line will never wrap. That isn't a good assumption. Different devices use different fonts, which could cause text to wrap in some cases.) In those cases, make sure to only set the sizes to specific values when needed. Let the page flow as much as possible.
Probably not.
A good responsive design and sticky footer might work around this issue. That said, how many people zoom out this far?
See Marshall Roch's comment towards the bottom of that link - he says a small percentage have 1 zoom level off normal on facebook. So to zoom all the way to 25% seems quite extreme. I suspect any users who DID use that zoom level would be used to sites looking weird.
I'm a newbie in html5/CSS3/jquery, and I'm making this (not finished yet):
http://catherinearnould.sio4.net/autres/kat/
The problem is that, because of the large canvas with particles, the animations are not as fluid as it could.
So if you're bored, don't hesitate to have a look at my code and give me some advice to improve the fluidity ^^
Many thanks!
For one using RequestAnimationFrame() instead of setTimeout() is likely to make things smoother. See Paul Irish his blog post requestAnimationFrame for smart animating.
The big performance hits are most likely caused by live calculated/rendered CSS attributes such as transparency, shadows and rounded corners.
Also be aware of that changes to DOM elements which cause reflow is costly (such as animations), see http://code.google.com/speed/articles/reflow.html.
I see a big difference just after running this:
$('*').css({backgroundColor:'transparent', opacity:1, boxShadow:'none'});
If you can, replace all (semi-)transparent and rounded graphics with equivalent png images.
You could also think of using css3 transition for some of your animation and removing and adding new classes to the elements to changes their styles rather than doing it with javascript(jQuery). Use jQuery as a fallback for older-browsers and IE.
http://www.w3.org/TR/css3-transitions/
http://net.tutsplus.com/tutorials/html-css-techniques/css-fundametals-css-3-transitions/
This gives the browser the power to do the rendering, and in some cases like in the iOS you can get hardware accelerated for the rendering.
For the canvas element, I have little experience with that, but I'm interested in that effect you're creating. But I think the massive canvas animation at the start is a bit much, there is so much going on already, maybe there is no need for that effect? Just my opinion as a user.
Bit of background
I've been producing a Flash-driven webcomic for three years now, incorporating some basic animation, a synced soundtrack and zoom-drag page viewing. The recent Flash-bashing, my desire to reach iHandhelds and my preference for open versus proprietary means that I want to make the move to HTML5 techniques this year. In the long-term, I think the writing's on the wall for Adobe's product, and I'm not entirely convinced that's a bad thing.
I'm relatively comfortably with both CSS and HTML, having worked a little in web design before. However, JavaScript is a foreign country to me, and I simply wanted to get some advice as to
whether what I want to achieve can be accomplished consistently across all browsers and
what the best techniques/approaches to the problem would be.
Any advice, even general principles, are very welcome. I've already sought out several HTML5 tutorials and introductions, which lead me to believe that the canvas element will be foundational to my plan; however while all the individual problems I face have been answered by many blogposts and guides, combining the various solutions into a single entity is something I'm not currently able to figure out, as I'm not certain of the limitations of the new HTML5 tags, or of best practice.
If I'm successful in achieving what I'm after, I'm going to post the full code online with an explanation of all the elements. Webcomics might not be a huge domain, but having a resource that did this would have made my life a lot easier - hopefully it'll help someone else in a similar position.
What I'm after
Here's a diagram giving the basics of the design requirements. I'll explain the elements, and the desired extras, below.
(Perhaps the simplest way to demonstrate what I'm after would be for interested folks head over to my website and see how my comic currently works. This isn't a plug - it would simply give the quickest insight.)
At core, I'm after a viewer that will:
display text (SVG image) in a canvas element above an raster image the page's panel art
both images should be zoom-and-draggable in sync but should ideally fade in separately, with the raster image coming first, followed by the SVG image
I'm guessing that the best way to accomplish this would be to layer two canvas elements one above the other using z-index, with the SVG file in the uppermost element. These could then be nested, as in the diagram, within a div element that would carry the zoom-drag function. Is this a reasonable approach, or are there more efficient options?
The next and previous buttons are self-explanatory. Would it best to have each page (bearing in mind some will involve animation and music) on a separate page, or to have all pages within a chapter on a single page, with the buttons making them visible progressively? I imagine this would have a great impact on loading speeds.
Finally, I'd like to have the viewer capable of displaying fullscreen if the reader desires. I imagine this could be accomplished by using Javascript to make the canvas elements and their surrounding div switch between different CSS giving a px-defined size and 100% height and width. Is this a good approach? Is it possible to apply the size change to the div element only and have the canvas elements automatically follow suit, possibly by defining their size via % in CSS?
Desired extras
At various points in the comic I make use of basic animation techniques - simple movements of layered raster images across the viewing pane. This would be simple to accomplish, I imagine, using Javascript; am I correct in thinking that applying overflow:hidden to the wrapping div will prevent images larger than the viewing area from spilling outside the viewer area?
I also want to synchronise audio with some of these animations. I understand that synchronising canvas events with the audio would be the best way to do this on, permitting both to begin activity only upon page loading or next button click.
That's about everything. As said, any advice at whatever level would be greatly appreciated, even if it's 'yes' or 'no' to the various questions I've asked. At root, it would also be good to know if HTML5 is the best option for what I'm after or whether (with gritted teeth) I should stick to Flash for now and go after handhelds using Adobe AIR.