My project's creative designer and I have had some amicable disagreements as far as whether it is better to use slices of his comp or rely on the browser's rendering engine to create certain aspects of the user experience.
One specific example is with a horizontal "bar" that runs the entire width of the widget. He created a really snazzy gradient that involves several stops of different colors and opacities, and he feels that the small size of the image is preferable or at least comparable to the added lines of CSS code needed to generate the gradient natively.
We're already using CSS sprite technique to reduce the number of return trips from the server so that's not an issue for us. Right now it's simply the pro's and con's of using sliced up imagery versus rendering with CSS and HTML.
Is there a definitive rule as to how large an image needs to be to be the "worse" option of the two?
UPDATE: Since a few people have mentioned the complexity of the gradient as a factor I'm going to present it here:
-webkit-gradient(linear, left top, left bottom, color-stop(50%, rgb(0,0,0)), to(rgba(0,0,0,0.9)));
Very complex! ;-)
Measure it! Not the answer you like I think, but it really depends how complex the CSS will be and therefore how long it takes to be rendered.
In most cases it'll be the render time (CSS version) vs. request overhead and transmission time (image version). You will most probably see the big numbers here. Since you're already using image sprites you're reducing the request overhead to a minimum.
Browser compatibility should also be something you should be aware of. Here images will often win over CSS when it comes to gradients and something like that.
Some very complex CSS3-site to demonstrate what I mean: http://lea.verou.me/css3patterns/
This is a VERY nice case study, but incredible slow. It lags when loading. It lags even more when scrolling. And I am sure it is much slower than a solution using an image sprite for all of that.
Don't treat me wrong! I love CSS, but images are fine too. Sometimes even finer.
Summary
Measure it! When you do not have the time to measure, then estimate how complex the css would be. When it tends to get complex, then use images. When you've compatibility issues, then use images.
In general, if it can be done with CSS, definitely skip the image. If for no other reason it's easier to maintain.
HOWEVER, a complex gradient is likely where I'd give in and throw in an image. Having recently implemented some CSS gradients, it is a bit of a mess right now.
Ultimately, Fabian Barney has the correct answer. If it's an issue of performance, you need to measure things. In the grand scheme of things, this is likely low on the performance issues to dwell on.
i think CSS is more reusable. Imagine you have to repeat the same image over and over again in the same web document. Lots of HTTP requests there. But that's my opinion, please correct me if I'm wrong I think CSS is way more expressive and flexibly stylish.
However, there are things you have to watch out for. Stuff like browser specific prefixing kill pages with too much CSS.
Related
Okay so i have used Figma before, although it was long ago, i didnt have this problem. I am in a team of developers. we arent very good in designing so we paid a designer to do the design for us. Everything was all good till i started coding the landing page. The dimensions i got from Figma for basically everything is way too big and so unrealistic. I mean it told me that the height of the Navbar is 135px, 135?????? thats way too big for a Navbar. I have to scale it down myself and use trial and error method till it looks somewhat like the design. Normally i wouldnt complain if i was programming for myself but its not a personal project and i am on a deadline so the fact that i have to manually use trial and error method to make the designs match instead is just adding so much time that i didnt account for. Is this a fault of the designer or figma itself? is there a way to scale down the dimensions to make it browser-size ?
The first thing to understand is that if your screen has a higher resolution, it may look smaller or larger.
Second, your designer did his designs on a different scale.
You will have to make a system of scales. If he gave you the height as 135px and you think 80px is actually the correct value, your scale is 0.6 and all values should be passed as height x 0.6. Same way for the width.
The easiest way is for the designer to resize his design to the correct size. This will have only one drawback and that's he will have to edit multiple elements in each page individually and it can take hours. However, it's his mistake.
As browsers are finally starting to agree on CSS3, many web developers are rubbing their hands in excitement over their new, image-less web designs. They're clean. They're scaleable. They're powerful.
With border-radii, box-shadows, font-faces and the like, now we can convert our designer's beautiful design into lines of code, instead of packing our pages with img tags.
Two related questions:
Is there a point when the stylesheet(s) get so large that they actually [negatively] affect performance to a noticeable degree?
In a web application with lots of icons (in the range of 16px to 48px size), how noticeable would the performance boost be by using an icon font?
Is there a point when the stylesheet(s) get so large that they actually [negatively] affect performance to a noticeable degree?
It's just common sense really. If your stylesheet(s) become quite large then that will have just as negative an effect as having lots of images. In general terms a stylesheet (with lots of CSS3 and fancy bits) will be faster to download than a load of images.
I'd recommend taking it case-by-case and deciding whether CSS or images provides the better solution taking into account download speeds, browser support requirements, desktop vs mobile and so on.
In a web application with lots of icons (in the range of 16px to 48px size), how noticeable would the performance boost be by using an icon font?
Unless you were talking about hundreds/thousands of icons then there really isn't going to be a hugely noticeable difference in performance. Remember with icon fonts you're also probably having the user download some custom fonts.
Again it's really a case of using what is best for the current project.
I don't think there is a definitive answer to your question but hopefully what I've said clears it up a little for you.
I don't think there is a "point", and performance is not related so much to the size as it's related to the style rules themselves. The main issues I've seen are related to CSS gradients (especially radial gradients). This was a year or so back, but I remember testing some mobile devices with some mixture of gradients and on (webkit) mobile devices, the web page's display was notably lagging. Removing the gradients and adding images removed the lag. Now, for all I know, most devices now may have newer webkit display engines which might fix that issue, but I do think it's still a valid point to consider.
The size of the CSS files does affect performance in a few cases. If the CSS is especially large, it will cause some issues. But as someone else mentioned, it is text, so its probably pretty small file. But if that CSS is split across many files, that becomes a bigger issue. I have seen some sites with 10-20 css files, all located on a single server. Depending on the browser, it can only open 2-6 (maybe 8) connections at a time to each server. If you have 10 css files, plus another 10 js, plus 100 other assets, thats going to take a relatively long time to open and close the various connections. One way to solve this is to concatenate the CSS files as part of your development process. Some tools that do this that I like are Yeoman or Codekit. Those tools will also automatically minify the CSS as well making the one file they generate that much smaller.
Using an icon font is good because they are scalable and use a single file. As you zoom in on a page, the icons continue to look great, while the pngs you might use look terrible. The icon font is also one file, so for the same reason as above, its one file versus 10s-100s. If you do need to use PNG files for some parts that are not icons, look into using sprites, often referred to as CSS Sprites. This is a technique for combining several images into a single png file, which can then be used on the site with some creative CSS.
The whole point of CSS is that the styles cascade upon one another. Extremely large style sheets would lead me to believe the CSS is not written properly and therefore not cascading down. That being said, I suppose its possible have large properly cascading style sheets in which case I would recommend using a minifier to eliminate white space and compress your code to make the load time faster.
As for the icons are concerned, you could possible create a sprite (a collection of multiple images) and then use CSS positioning to only show the icon you needed. In this way the server would fetch only one large image instead of a lot of smaller images. Granted it, the one image is larger than the others, but nothing kills load time and slows a page's performance than a ton of fetch requests by a server for images.
I'm using webkit-transform: translate3d and a few other properties pretty extensively on a mobile app for iPhone because its hardware accelerated. With about 98% of the features in place, performance is great. I'm aware of not trying to do too much at once.
I'm successfully simulating swiping in a very excellent, native way. What I've noticed now is that when I add the last 2% of features I'm seeing some image redrawing issues in the that is being animated while swiping. After you swipe through all 4 images and they load, then performance is perfectly smooth again. However, when this section is hidden and shown, the same thing happens.
What I hypothesize is happening is there's an internal buffer being hit and it has to reload each time.
So this with that background, the general question is what kinds of performance optimizations have other developers been making for -webkit-transform? I'm not necessarily asking about my particular situation, but rather what wider range of optimizations have people figured out for their individual needs?
Hopefully if this question gets some answers, it can be a resource for other folks asking the same question down the road.
It's a fairly well known thing, but making sure the element you transform is using 3d transforms where possible helps a lot on devices that hardware acccelerate transforms (iOS at the moment).
The easiest way to do that is to add:
transform: translate3d(0,0,0);
with the appropriate prefixes to the css of the element in question, then just animate it as normal, either by using 2d or 3d transforms.
It might sound a bit weird but i had a similar issue and i solved it by using -webkit-perspective: 1000.
Don't know how this acts in favor of the transitions, but in my case it did.
I'm in the process of starting to build a strategy game (think warcraft) for the web. I've been doing research on HTML5 Canvas and CSS3 sprites and still can't decide which technology to use.
The game won't be completed for another 6 months.
Any advice would be appreciated.
As you probably hear so frequently... "It Depends..." ™
My suggestion would be consider the feel of the application you're after. If you are trying to build a very graphically rich, mostly-images application, then I would use Canvas. However if you are trying to animate some graphics, but have the page remain and behave more "Web-like", mixed with other HTML content, I'd give CSS3 a try.
Two additional points:
Currently, Canvas is better supported than CSS3 animation/sprites.
If you use Canvas you're going to be implementing your own render loop and animation code (or making use of a 3rd partly library). Your code create animation by compositing the various layers of each frame, applying movement, and repeating. You can't simply say "move this image a little to the right". You'll have to do that yourself.
The EA web game "Lords of Ultima", as dull as it is, is an excellent example of a WarCraft-styled (well, it's more city building as there are no visible units) overworld, with animations and everything, built on a pure HTML and CSS sprite base. It looks and performs well and I think the square block box-model nature of HTML suits that kind of tile based design, especially since a lot of the image processing (embed an <img> or a <div> with a background, change background-position for animation) and click/mouse handling is done for you in simple html.
If you do go canvas you have to manage that yourself which will greatly increase the complexity and dev time. You'll have more control of minor elements and improved performance, but then you'll also lose (if it's at all important), greater backwards compatibility with older browsers. So it depends on how complex your design is and what kind of performance you need.
Use Canvas. If you use CSS sprites to build a game, then you are going to make a lots of <div>'s which performs operations on the DOM, which may slow down and also have a lots of focus and compatibility problems.
It may pay off to trade the development time for performance on <canvas>, by the assumption of "A code will be maintained forever".
I think CSS3 sprite system takes more time to develop, because you need to handle browser compatibility.
Browsers like IE 8 (8 or 9?) are using GPU to accelerate graphics, which lets you get the free lunch of Moore's Law.
There's pros and cons to both. Currently, Canvas is better supported then is CSS3, but you said that your game won't be done for another 6 months, by then the support for CSS3 could be much much better. There's also a lot of other variables here, such as: What browser will the game be viewed on? How advanced are the graphics you need to animate? etc... I would say that canvas would be better for support of the current generation of browsers and for gaming graphics, however CSS3 would be quicker, but wouldn't even come close to the support or graphics handling. But it doesn't seem like your in a rush to get it done.
Basically:
Canvas: Graphics, current support in users browser
CSS3: Speed of development
Ether will work. But for now I would use Canvas. However, 6 months in the tech world is an eternity, things could be a lot different then.
I am working at an app that causes lots of browser reflows. Performance is a key issue here. From the performance point of view Is it better to use a CSS3 gradient or an image gradient for some DOM elements? Does a page that uses CSS text shadows and gradients will have a slower reflow as a page that uses images to achieve those visual effects?
Also, are there any reflow tests out there I can use?
For drawing, CSS gradients and shadows do task the CPU more than images. Performance used to be pretty bad, these days they are acceptable. If you have a ton of gradients/shadows, you should just implement them and do the tests in your real-world setting. If you just have a few, I wouldn't worry about it.
It depends a lot on how the browser renders it, but for the most part those things will render slower. In addition, you'll have a less pixel-perfect display in older browsers. However, this also serves to segment your audience, as generally those with updated browsers also have updated computers. So, it's a trade-off that can work in your favor to essentially serve a stripped down version of your site to those that wouldn't be able to handle it. It's not guaranteed, but I've found it usually balances out pretty well.
Overall, real-world testing is the way to go. Build it, see if it works, and fix performance issues once you find them. I wouldn't hesitate just because there's a chance it might not work. If it works just fine and you don't try it, you'll never know!