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.
Related
I have a personal project designed for the desktop that I previously created in Adobe XD, and now I would like to put it on Behance. To do so, I need to adapt the layout, designed for the desktop, to mobile.
I don't usually design for smaller screens, so I am wondering how much I need to decrease text and element sizes? For example, if I have a text with a font size of 40px, what calculations should I use to decrease the size for mobile? Is there a default percentage to reduce desktop values? Alternatively, are there visual rules that other designers follow?
I always design for Bootstrap, but I'm not sure if I am thinking about mobile the right way.
I've also posted this on the User Experience Stack Exchange forum, but I'm not sure which one is the best for my question.
Thank you for sharing your thoughts and advice.
I have designed mostly for desktops as a traditional web designer, and now I'm trying to migrate to UI/UX.
Modern devices do most of the scale conversion work for you by adequately scaling the viewport to compensate for the smaller screens and often higher resolutions. Depending on the type of application you are designing, the technology is different, but the result is very similar.
For example, if you were implementing the design for the Web, you would likely need to use browser features like media queries to manage your content.
However, because you are focusing on the design of the site, you should not need to worry about the 'how', so you can focus on what to do.
Here are some tips:
Elements and text appear roughly the same size on desktop and mobile if you hold the device at a casual but comfortable distance and compare it to the size it appears on your desktop's screen at an average viewing distance. You can try this by going to a website built for mobile like Apple's.
Because of the similar size but reduced screen dimensions, you need to simplify your design, avoid multiple columns (especially for phones).
Because you see a smaller portion of your design at once on mobile, there is less need for significant visual hierarchy. For example, if you have multiple heading levels with a significant visual size difference on the desktop, you can probably get away with making them closer in size on mobile.
If you want to see what your design looks like on mobile, try emailing the design to your phone, save it to your pictures, and load the image full screen. You may need to zoom the image in a bit so that the left and right of the design are touching the sides of your phone's screen. If your text looks too small or your elements are too large, adjust the design and load it on your phone again. Keep doing this until you get it right.
With a little practice and effort, you will get the hang of Mobile design. And, if you want to take it to the next level, try researching mobile first design. Here is just one of many articles on the subject.
As great as Haxe got with NME/OpenFL the big problem transitioning from AS3 development are assets. As much as Haxe is similar to as3 and OpenFL tries to provide a familiar API the lack of SWF support scares away many developers.
My research on this topic led me to understand that current SWF is rather weak and buggy with many edits necessary to SWF file in order to run it in Haxe.
The question is how do you use SWF animation in OpenFL apps, or if you don't - whats the best solution you've found regarding rendering time, processor time and file size.
Having spent more time on the research and asking other developers I put together a small list of possible alternatives to using SWF assets for animation. Hopefully it will help other developers, who has a similar problem while the SWF animation support is weak.
NOTE: all methods were selected considering three factors important for me: availability on all platforms, performance and file-size of assets. Therefor not all possible methods were included.
Tested on: HTML5, Android, iOS
SWF animation is possible with Haxe/OpenFL, but there are few rules: no tweens - all animations are frame-by-frame. Vector art should be cached as bitmap, saved as bitmap or pre-rendered as bitmap sequence as on some platforms (e.g. neko) vector art is being transformed to raster with ugly bitten edges. Some bugs were reported if representing MovieClip's as graphics or vice versa, but I didn't notice any bugs on HTML5, Flash, iOS, Android releases. Nested animations sometimes might skip frames if looped (didn't see that either, maybe older release of NME/OpenFL did that). I'd say this is a fairly good way to animate content from the concern of file size and platform availability, but it's a headache to edit all the assets to meet requirements of Haxe support. And it's not fun to reuse these assets later, since they're all frame-by-frame animations and it's a mess.
Sprite sheet animations. Primary used for HTML5 targets due to higher rendering performance. This is directly from a openGL standard, so this method should apply for all openGL targets. The idea is to rather have one big file and save time on opening/loading multiple smaller files. The performance is good, works on all tested platforms, but the file size get's quickly out of hand and can be hardly used for animations where object size is changing in size - makes unnecessary large transparent space, rotating the image to best fit the space reduces rendering performance with editing the transformation matrix on run-time.
Frame sequence aka PNG sequence animation. Personal favorite. It works well and fast on all platforms, it's possible to pre-render the the animation (just like any other method above), transform to BitmapData array, stream-load etc. It does take a lot of disk space for the animations, but can be softened by loading the assets before using them (HTML5, SWF) and it doesn't really matter for mobile devices - as even 1-2GB apps are ok for the market. Large advantage that I found for myself is that this type of asset can be used for any other developing standard (C++, Java, cocos2d) and saved as Sprite sheet if needed (e.g. cocos2d, like HTML5 prefers Sprite sheets over anything else as written in the official book COCOS2DX by Roger Engelbert).With this flexibility, good performance is tolerable file size I prefer this method over any other method listed above.
Bone animation - PNG array + property list. Another approach is having separate images of an animated object and every image matrix data for every frame. That way with minimum disk space use it's possible to make thousands of animations. The downsides are: it's harder (not impossible) to have nested animations for more complex animations, constant matrix transformations limit number of active animations on the display list (horrible method for HTML5, other platforms held on well) and little reusability of assets. Usually it's the same good old SWF assets that were exported to this type, so it makes sense to edit the FLA rather then the bone animation itself.
Surely I've missed some great points, there are many ways to animate graphics and some might work for you better than others so feel free to leave comments and criticize, but I still hope this topic was helpful.
This question might be obsolete. I compiled a C++ app in Haxe/OpenFL just 5 minutes ago and had no trouble getting SWF animations (with tweens) to work.
Here's a gif recording:
https://imgflip.com/gif/7l02f
I had an asset called "library.swf" containing that animation, exported as class "Oluv"
This requires the "swf" library which is now free, and can be installed with "haxelib install swf"
In my example, I added this to my application.xml file:
<haxelib name="swf" />
<library id="oluvLib" path="assets/library.swf" type="swf"/>
Then put this in a standard OpenFL template project:
Assets.loadLibrary("oluvLib", swfAssetsLoaded);
private function swfAssetsLoaded(library:AssetLibrary):Void {
var oluv = Assets.getMovieClip("oluvLib:Oluv");
addChild(oluv);
oluv.x = (stage.stageWidth - oluv.width) / 2;
oluv.y = (stage.stageHeight - oluv.height) / 2;
}
Tweens do not seem to work on neko target, but they work fine in C++, and flash (of course).
I asked this question recently: How can I create a CSS border on a diagonal element
Question: Is it more memory intensive or cpu intensive to use image or complex css for a navigation menu?
Question: Cross browser/screen size aside, is the an advantage to one over the other for reasons other than what is mentioned above?
Thank you!
Ultimately, the device needs to display an array of pixels. If you send an image file of those pixels, they are ready for display. If you send complex css for creating those pixels, it will likely take fewer bytes across the network but the processor will need to render the pixel array before it can be displayed.
Whether you should use css or an image depends on a variety of considerations. Here are a few:
Is the thing you need to display always exactly the same size? Then an image file has the advantage of already being rendered. If not, css will give the capability to size efficiently.
Will the user always have a good network connection? If so, there won't be as much of a performance penalty for sending a pre-rendered image and possibly a bunch of media query css to decide which image to load.
Is the thing you are trying to render very large on screen? If so, css might have an advantage over loading a large image file.
Is the css extremely complex, taking lots of code to describe? Then an image file has the cpu advantage of being pre-processed.
Are there animation states or other animation associated with the display item? Then css has the advantage of not having to load multiple potentially large image files. But, if the states have very complex animation taking lots of code and therefore cpu, then the previous guideline will apply.
Second question: If there are cross-browser difficulties with your css, a pre-rendered image will eliminate those. But, if you are building a responsive display object that has very many different display sizes, css will have the advantage of scalability. That said, a basic concept in responsive design would be to provide a few different size versions of an image.
In general, image files cost bandwidth and css/vectors cost cpu.
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.
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!