I am planning to use some auto in my css. However, I was wondering if using that auto keyword instead of explicitly declaring pixels make the site download or display slower by any means.
No, using the auto keyword in css does not generally have an impact on the performance of a website.
It is generally more important to consider the overall size and number of resources (such as images and fonts) on your website, as well as the efficiency of your HTML, CSS, and JavaScript code, when optimizing the performance of your website.
Related
I'm planning to write a common component library with Vue.js 2.0 and hope the library can work on multiple platforms. This question is about the best practices when it comes to a component's style.
On the PC / browser, We usually write CSS for fixed-width or flow layout with px. On a mobile platform (webview or browser), We usually write the CSS for flexible layout with vw / rem.
I see, some components only suit either one ( PC or mobile platform ), but still some components are common and versatility, such as Button, GridView, InputField and so on.
For example, there is a Button component that has a default padding style. In order to better adaptability, should I set the padding value by what unit? px? rem? For the goal, what is the best practice to do the things?
In fact, this question is not only related to Vue, but it's relevant for any frameworks that allows developing components, such as: React, Angular, Ember, etc.
I suggest that you stop thinking of browser / PC layout and mobile apps as being different. As it looks, you can't be sure what form factor's going to come next for both of them. That's true even for platforms that have been proven to be consistent, such as iPhone / iOS.
Responsive web design is the same in both environments, your layouts should be 'prepared' for a change in form factor.
Responsive web design is not different from React to Angular or anything in between. The only thing that differs is how CSS actually gets in your app.
No matter what you're designing for, you should:
Respond to the needs of the users and the devices they're using. The layout changes based on the size and capabilities of the device.
The basic principles are: Adapt, respond, and overcome.
Technical perspective
In Vue the way to go is: isolate components, including styles -> use scoped styles whenever possible <style scoped></style>.
Then (not specific to Vue), use fluid layouts however you want; some people choose %, some use vh / vw or em / rem. As long as it's fluid, you'll probably be fine. Many choose vh / vw for containers and use percentages afterwards, but there's no default pattern. With percentages, some people find it easier to mix in calc(), which can be a useful responsive tool.
Regarding your button example, it's probably a good idea to use rem or em as a default. However, for some components it might make sense to use px - don't be afraid to mix and match. This can save you a lot of code and there's no golden rule about it.
Your breakpoints shouldn't be shaped after devices, instead figure out where your content can be presented better. This way you'll build a more future-proof layout, which can turn out to be a nightmare to maintain.
Choose whatever makes you feel comfortable.
It's up to you to combine your tools and get the CSS to work for you / follow certain RWD patterns.
Wrap up
That being said, here are some patterns you can follow when building your responsive apps:
Mostly Fluid
Column Drop
Layout Shifter
Tiny Tweaks
Off Canvas
There's a course I encourage you to take if still in doubt.
In this course you'll learn the fundamentals of responsive web design with Google's Pete LePage! You'll create your own responsive web page that works well on any device - phone, tablet, desktop or anything in between. It might feel a bit slow in the beginning, but you'll learn a lot by the end of it.
Will an imageless design (using CSS to generate icons) load faster than a traditional image based design?
NOTE: I completely understand the flexibility of being able to change an icon's colour, size etc. will a few changes to the CSS file is much more efficient, but I am unsure about the loading time.
Background:
I am looking into completing a project for a client that is an imageless design using CSS to generate the page icons, which was a project requirement to decrease loading time on mobile devices. Normally, I would just slice out the icons in an image sprite and not worry about the load time seeing the browser would only have to load and cache on image.
Thanks!
Yes, if site icons can be generated entirely in (relatively efficient) CSS, this will load faster than images. The rub is that most icons are far too complex to be generated using CSS, and the CSS might in some edge cases become so complex that the maintenance issues associated with maintaining complex code across browsers might outweigh the benefits. But in general, if you can do it in CSS without having to bend over backwards, it would be optimisation—and in the scenario you describe might well be worthwhile optimisation.
I don't think the question is whether or not it's faster, but whether or not it's a good idea at all. I wouldn't sacrifice the flexibility of using images by making everything into pure CSS. You guarantee cross-browser compatibility with images, something that CSS3 cannot. Plus images are easier to maintain.
Think it in this way .. the size of css icon(the size of the code required to produce an icon) is an advantage and the other major advantage is the server hits. for ever image icon there is a hit which means there is a waiting time, downloading time, and rendering time, though its only in milliseconds the waiting time and downloading time are directly proportional to your server load.
In that case a css3 icon will not only save time and band-width but also reduce your server hits as the css file downloads only once and its contains all the style declarations for the entire site.
The advantages are enormous to choose a css icon. But there are some cases where a css icon is not suffecient, so its up to the developer to choose from a css icon or an image based on the requirements.
Our application at work uses the ExtJS (Sencha) framework for the UI. The problem I have with the framework is the amount of HTML that is output by the framework.
I have noticed that the areas of the system that are reported as being slow by users have a ton of CSS calculation calls. I measured this in Google's Speedtracer and some pages take 8seconds to load. 80% of the time is dedicated purely to CSS calculations. Before trying to alter the way the framework works, is there anyway to delay CSS calculation of a page, or are these calculations done when the objects are rendered?
I have been searching for ways to do this, and maybe my "google-fu" is terrible, but I haven't found anything concrete on how to achieve something like this.
EDIT: After speaking a colleague, he pointed me in the direction of calling .suspendEvents() on the grid before loading any data and .resumeEvents() afterwards, this alone has saved 300ms of loading time :O This is reducing the number .getStyle calls detected by Firebug. I am yet to test this difference with Google SpeedTracer
It's hard to say what's causing your performance problem without knowing exactly what your app is doing. CSS will have some impact but not much, it's more likely that some JavaScript in your app is causing excessive reflows while the page is rendering.
Summary of stubornella's article (the second link)
Reflow is the process by which elements in a web page get laid out according to the style rules. A reflow is computationally expensive but it is usually possible to draw a static HTML page in a single reflow as long as the rendering of any later elements doesn't effect elements that have already been drawn. Things which are likely to lead to multiple reflows and some work arounds:
Dynamically adding CSS classes to elements - change classes as low in the dom tree as possible to limit the impact
Adding multiple DOM elements - create an invisible structure and add it in a single operation instead
Adding multiple inline styles to visible elements - better to create a class with all the styles, then apply the class
Applying animations to relatively positioned elements - better to animate position: fixed or position: absolute elements as they won't impact anything else
Fine grained animations - moving an element 3px at a time may be more smooth than moving it 1px at a time because you avoid two reflows
Tables are one of the few cases where the rendering of an element later in the DOM can change how an earlier element should be rendered - if you must use tables, use table-layout: fixed
We have also been struggling with the overhead of using extJS - although the framework is very comprehensive, the performance hit (especially with IE6) has been a big limitation. Here are some of the steps we took to optimize the framework:
Streamline the library to only include the packages that are used on your site. This means customizing the jsb2 file and rolling your own extJS deployment.
In our performance testing we've identified the CSS to be the biggest offender. A benefit of using a custom build of extJS is the reduction of unused CSS selectors. To further optimize the CSS, we used Google's Page Speed to identify the CSS selectors that are inefficient to refactor/remove them. Pay particular attention to:
Pseudo :hover selector
Universal * key with descendant selectors
The resulting ext "lite" should yield significant performance gains, particularly in IE6. Although the Secha team are making continuous performance improvements with every release, the overhead of loading the entire framework is too expensive to ignore.
Hope this helps...
Smartoptimizer is really awesome, have you tried any of those types of gzip code compression type tools?
https://github.com/farhadi/SmartOptimizer
In what scenarios CSS sprites would be good to use and when not? Is it time saver or only server request saver?
I think bandwidth use will be same because image is same like ong big image but it's in a parts?
When and where use of css sprite is a time saving(in work) option ?
For navigation it's good for rollover pre-loading effect but not good for images disabled people?
What are other good usage which can save our time once and in future (if changes comes in design) both?
Edit: Sprites is only for css background so should we use images in background as much as possible to save sever request, is it good idea?
Update:
To implement takes more time then regular method and mostly client do not much worry about some slowness like http request. My question is can we save time in site making process and future maintenance of website using css sprite. or regular method is enough.
In nutshell my question is: “can CSS sprites save our designer and xhtml css coder time (I'm not talking about server request)?”
It reduces the number of HTTP requests which will enhance site performance.
CSS Sprites are the preferred method
for reducing the number of image
requests. Combine your background
images into a single image and use the
CSS background-image and
background-position properties to
display the desired image segment.
In Minimize HTTP Requests
CSS sprites are a time saver because it is a server request saver, as server requests are notably time-consuming. Using CSS sprites usually decreases your webpages' load/render time dramatically. There are times when they cannot be used, such as with background images repeating in two dimensions, but when you can use them, it's almost always worth the effort.
Of course you shouldn't sprite groups of images that are very big, especially if they're not very likely to be shown. Don't sprite an entire photo gallery into one big image, for instance =)
Other measures which amount to pretty much the same thing would be minifying, compressing and combining your scripts and styles into only one js file and one css file.
EDIT
With regards to your clarification, i'd say no, CSS sprites will always mean more work, never less, compared to just using the separate images as they are. I still wholeheartedly endorse their use, tho =)
CSS sprites are best used for elements that have a fixed width and height. Otherwise, you need large empty spaces in your sprite image, which can (depending on file type) increase the size a bit.
Due to the way different file formats compress images, sometimes a CSS sprite image will have a noticeably smaller file size than the total file size of separate images. That’s a nice bonus.
As mentioned, sprites reduce the HTTP request overhead, which can help load time. I’ve never seen any numbers on the magnitude of this effect.
Sprites will add a bit of time for your CSS developers. It shouldn’t affect your designers. But bear in mind that your developers code the site up once; the benefits of sprites apply every time someone looks at the site.
It will only reduce the number of requests but that will benefit both the server and the client. The server will not need to handle as many requests. The client, because it is limited in the number of parallel requests that it can make, will render faster as many of it's previous "requests" for the image will be served from its cache, allowing it to make the requests that it does need more expediently.
Using sprites reduces the number of requests and thus also the network overhead. Loading a few sprite image is faster and uses less bandwidth even if the image data is the same (or even a bit more) than the individual images.
It needs a bit more work and some planning to combine the individual images into sprite collection images, so the development time is somewhat longer. The difference is less if you have it in the plan to start with rather than combining the separate images afterwards.
Any scenario where you have several same size background images that replace each other (or complement each other) is ideal for sprites.
As long as you have something like a dynamic photoshop PSD file in the back, then the designer's maintenance won't be an issue. But if it is a static file like PNG/GIF, then maintenance will take more time as you cannot control the individual images separately anymore.
Overall, sprites is a great idea. Use it for fixed width & height images that are less likely to be updated frequently.
Sprites are always good to use. They help speed up the loading of web pages and prevent the blinking effect on navigation hovering.
Having asked this question How to reach CSS zen?, I now understand that the issues I have are mostly related to positioning. I've found some articles telling that CSS is not always good enough as a layout system.
http://echochamber.me/viewtopic.php?f=11&t=40154
http://www.flownet.com/ron/css-rant.html
http://blog.workaround.org/2009/03/17/dont-abuse-css-for-page-layout/
Do you as CSS designers limit yourselves upfront to designs that CSS can handle? Should I avoid things that seems perfectly easy are in fact difficult to do with CSS?
Of course you limit yourself. As a designer, you should always think about the medium you're working with. If I were designing a magazine ad, I wouldn't be thinking about animations or video. There are certain rules you must adhere to, and it doesn't make sense to ignore that.
But of course, rules were always meant to be broken.
Why?
If you are "designing", why would you limit yourself based on a the limitation of one technology? When you design your site, you should always try to achieve the most usuable interface for the user.
If you do limit yourself, then you are just asking for the site to not be used, and then what's the point of creating it?
I don't limit myself upfront to any designs that CSS can handle (within reason of course), just figure out your design and there will be someway that you can get it looking right using CSS, but it might involve a lot of hair pulling, especially if IE6 is involved!
When implementing a web design (assuming I've got an image/drawing of what the site will look like) I always follow these steps:
I look at the design and determine what components it has. Examples are navigation areas, headers, content areas, and so on.
I implement (X)HTML that can represent the content areas without really taking the design into account (there are certain things such as content order that I use the design to determine.)
I start making the CSS and images needed for the site to look the same way it did in the original design document. Depending on the complexity of the design, I might come up short of elements to use for styling the page, and may end up adding elements that don't really make sense for the content. I try to avoid it as much as possible, though, and I try to create the elements in a way that isn't obtrusive to the content.
As you can see, I never limit the design to the capabilities of CSS. CSS comes last. Now, depending on the complexity of the design, it might not look exactly like it did in the original design document, but the goal is always to make it as identical as possible, while still maintaining clean HTML so that the design can easily be updated in the future.
Most layouts I find can be done with CSS. There are a very few exceptions (normally to do with verically centering text).
For me the main factor which limits my designs is a reluctance to use huge background images. If an effect can't be done by combining/repeating a few tiny bg images I tend to reject or tweak it. Eg a diagonal gradient on a box with curved corners which could be any height might fall into this category using CSS2.1
Almost every painter limits themselves to paint on canvas, almost every sculptor makes 3D shapes from stone or clay or metal...
But there's also the few who dream new dreams and create new things. Some flop, some shine.
Should you limit yourself based on what CSS can do with layouts? Not completely. I say dream big.
Once you've got your dream design, either figure out how to create it, find a technology other than CSS that can do it, or go start inventing!
You can do absolutely almost anything using CSS 2.1 as far as layout. Its a complete pain in the ass that has no reason to ever exist, but you can do rounded corners (using background images), gradient backgrounds (more background images) and all kinds of other bloated crap you don't need all together and still not completely destroy the semantics of your HTML.
Doing all that garbage and still attempting to be standards compliant reduces usability, because its the designers who need round corners and other frivolous crap and not the users. Usability tests have confirmed this. Sites that are bloated to accommodate presentation and usability at the cost of semantics and efficient fail in usability tests compared to their competition. I work for a website that gets several million visitors a day and I have seen the results of our usability tests.
CSS provides a very good way to create an overall design that easily can be changed by small changes in one CSS file, and instantly applies the design changes to all your pages. Of course there are things that are tricky to do with CSS, and in those cases you might want to do it in other ways, but even if your layout is mainly based on CSS, doesn't mean that you can't do some special parts using other technology! You can mix!
So you don't limit yourself when you go for CSS. You just make use of a powerful technology that can be used in perfect harmony along with others!