As part of my job I maintain/develop an internal web application. It has relatively few users and just isn't that big. I've got a global CSS file that contains some re-used styles, but 90% of my page-specific styles really really ARE page-specific; they are things like pseudo-column widths (a lot of my output is just non-tabular enough to make tables a poor choice). I have taken to just throwing a <style> block at the top of these pages.
I know this is frowned upon, but every time I read about the reasons for separate CSS files the only one that really stands out is caching. In this case that doesn't matter; it is WAY down on the list of things I would do if I needed to speed up the application. Are there any other reasons, or can I stop feeling guilty?
every time I read about the reasons for separate CSS files the only one that really stands out is caching
Really?
Every time I read about their usage, the fact that you can change something in a CSS file and all pages that include it will have the change is the most important reason to use them.
Having your CSS centralized is a good thing even if your specific pages have different specific rules. It helps you unify the basic CSS structure across the site and when looking for how a specific effect was achieved it will be easy to locate.
These are all worthy reasons to use CSS files, well above any caching/performance reasons.
I face a similar problem, in that most of my styles are very much page-specific. However, my site is far from small, so I had to find a solution.
What I ended up doing was creating a folder css/pages, and naming each CSS file the same as the page that uses it. Then, my PHP "template" can just check if(file_exists("css/pages/".basename($_SERVER['PHP_SELF']))) and add the relevant <link/> tag, resulting in minimal effort on my part.
Just because your site is small is not a valid reason to disregard efficiency, although I have to say I'm a bit of an efficiency nerd so I'll probably be more pedantic over that :p
Ultimately, there's nothing "wrong" with just putting page-specific CSS directly in the page, just make sure that anything that is used on more than one page is in a file so you don't have to repeat yourself.
In my opinion if your app only contain a few web pages(3-5 pages) then you can go ahead define it at the top of the web pages. If your app is going to grow into more that 3-5 web pages then global CSS will help with maintainability and scalability.
Makes for cleaner mark-up, quicker load. Really applies to template and dynamic development. Don't be afraid to use it. It's not like you're going over to the dark side.
Related
I've been playing around with Filament's Critical CSS (https://github.com/filamentgroup/grunt-criticalcss) and have a question about it's usage.
As I've been using the tool, it generates a "critical" sheet for every page I point it at so that I can inline those files into my HTML via a <style> tag in the <head>. This all makes sense.
However, once the user visits any of my sites pages, they'll have the main sheet fully cached. At this point does it make sense to stop inlining the CSS, as the user already has the CSS loaded, and instead link to it via a traditional tag?
If you're certain that the user has the stylesheet cached this would be a valid approach, assuming that parsing a cached stylesheet or inline styling of critical css will take the same amount of time.
You however can't be certain that it exists in the users cache. As the critical css also exists in the stylesheet this isn't a problem, but it will make rendering the page slower.
The only way to know when it might be useful is to parse your access logs, try to find how often the stylesheet is also requested when a specific page is requested by a specific user. Using that you can create a probabilistic model on when it's useful to inline critical css. This seems like too much work for a small gain. I'm guessing that using inline critical css is most useful for landing pages or pages that go viral.
Yes, Inline CSS usually now is only needed when you want it to take complete precedence over an external style-sheet you do not control of a .JS file that makes unwanted changes which overwrites your style-sheet as well. Doing this also helps with performance, band-width, etc., etc.
I am going to answer here as it is best to do so instead of in comments.
The problem that you're having is strange in the matter that you are wanting to cover all possible bases with two separate, but tied issues.
Firstly, your performance gains. Since you want to have higher performance doing inline styles is the technically correct answer. There are some minor gains because you are not doing a request. All requests that go out take time and depending on the time it takes for the server to communicate each request you will see a possible performance drop. This is why some requests that are much larger are considered excessive and Google generally informs you to sprite the image or some other form of connection.
The other part is you want ease of accessibility and want to be able to update quickly which is what would be provided by an actual CSS file. You would need to at some point call this CSS file so that it can be cached into the browser as you expect. You can do some cookie checks and depending if the user has been to the site or not they will have a specific call, but here is the major issue:
At some point you HAVE to actually load it. You will have to make the call. Whether it be on the first load or the last at some point for it to be cached it actually has to be retrieved. You will spend a ton of time checking each variable if they don't have it they will need to have the style sheet loaded. If you are already required to load it at some point then it comes down to never really needing to do inline styles. And if you have inline styles you never really need to load it.
You could potentially do a PHP include of the file and have it pull in that way. You would just include the file between a style declaration and it would populate the CSS that way. I wouldn't say that is the best way to do it, but it is possible. It can be done. I still stand by saying inline is not the right way to go. Technically yes it can help. Reality... no. I have not seen it be beneficial ever in my time. If someone wants to show me one that is fine, but I doubt I will use this practice unless it is last resort.
Keep in mind this final thought. Most cases inline styles are styles that are meant to be final styles; ones that end overwrite original external style sheets that we as developers can not edit ourselves (or do not want to change for other reasons).
Google is great and they provide great research, but research is meant to be considered and not always used exactly as they write. It is to provide insight. Not usually a guide into the way.
They're are already plenty of questions about many css files vs one and the solution is to use one because of fewer http request. That's not what I am asking :P
I generally would use two css files. One for the entire site and one for the specific page overwrites.
My thinking behind it is that it will speed up the css since there isn't as many css selectors that need to be evaluated for every element on the page.
Requiring the client to download one more cachable css file seems like it would be worth speeding up the browsers rendering. Especially for larger sites or sites that need lots of custom css for each page.
On the other hand the page files will have additional media queries.
What do you think is the best solutions?
While a technically correct answer would require inside information on your server's performance, your visitors' behaviour and what kind of site you're designing, I'd like to explain my basic reasoning wether to use one or many CSS documents.
For any small, basic site I'll stick to one CSS document, no questions asked. However once a site becomes more complex there may be scenarios where it's reasonable to use more documents.
If a site has several pages with very different CSS and/or markup, or one-off-type pages such as a campaign landing page, or several very different types of content such as a forum or a blog or similar, then I think it makes sense to split up your stylesheets in many documents.
The structure of said stylesheets would, again, depend on the type of site you're designing. Global rules such as normalizing/resetting CSS, general structure and media queries could be in one document, while keeping page-specific rules in another.
This makes sense to me since your visitors can cache the basic structure which should be used on every page anyways, without having to download all the CSS needed for your blog or campaign page until they actually visit it.
I agree that if you have big site with different type of pages your should split your css into different files. However I think that this should not be made based on pages. It should be made on components. When you design CSS you have to split your pages into modules. A module should contain its styles and its media queries. I found that putting the media queries in different file leads to slow development. You may even end up with something like CSS constructor. I.e. a tool which selects the specific modules, combine them in a file and server it like that. You still have only one file, but its content is different.
For CSS optimization check out this tool http://bem.info/tools/csso/
With regards to mobile websites on smartphones;
Assuming that:
HTML code is rarely a huge amount of data
Compressed JS files are not so heavy
Images are often loaded via CSS (at least could always)
It's the same sequence (PHP + SQL = HTML) on server-side.
It seems way faster to do this way and quite easy to maintain.
And even if:
It's not graceful at all (hide Useless elements instead of generating a sharp and beautiful HTML code)
Useless code is loaded and treated.
Best practices for mobiles websites don't recommend to do this way.
Is it a good idea to rely only on different CSS to create a mobile version of a website? (Actually on different header templates, in order not to load useless JS)
It's probably a bad idea to serve HTML with elements that you know will be useless to your users.
Small amounts of kb make a difference on mobile download speed.
It means your CSS and Javscript need to be more complicated.
You users might see the content if the CSS or JS are slow loading.
It will take more processing power (I think CSS styles will still be applied to the hidden elements).
It's likely to be easier to manage on the server
But to answer the question "Is it a good idea to rely only on different CSS to create a mobile version of a website?";
Yes if you want your mobile users to have the same content as your large screen users. Which you probably should as this is normally what the users want.
No if you want to serve them different content.
Speaking for Belgium, I know a lot of people are still on Edge instead of 3G and loading a webpage takes some time. If we would have to load pages made your way, we would indeed be loading a lot of useless code, giving us quite a bad experience.
I'd suggest you stop being lazy and write your mobile websites the way they should be written. Think of your visitors and user experience; it honestly isn't that much of an effort.
I think you basically answered your own question already. Like BoltClock said, do what you want, but I sure wouldn't recommend doing things your way.
I have a more general design question relating to css and websites. I know that it is good computer science to normalize code as much as possible and avoid duplication. So it would stand to reason to me, at least in theory that one would do the same when organizing stylesheets for a website.
So when I started on my most recent website I started out with this same philosophy. It worked ok for my first few pages and while I was only testing in firefox...
However as my site grew and as I added pages, multiple layouts (and browsers) I found this philosophy broke down really quickly. Ultimately over time I have moved to the following approach:
I have a very limited top level css file for each master page layout in my site, it contains classes for well known styles across that layout as well as css for the master page.
I keep specific css styles for each page.
I keep specific css styles for embeddable page elements / controls
I ended up taking this route so that I could trust that changes on one page wouldn't accidentally break other pages in the site resulting in a lot of regression bugs.
What do other people do when approaching this? Is this a good / bad approach... I do see cons to this approach, some pages are very similar so making a significant change means changing more css code, I also feel that the pro's outweigh this on a daily basis.
What do other developers think about this philosophy? Good? Bad? Just curious really...
To me its one of those situations where I weighed the difference between my ideals (I try to keep very tight code), and the frustration of changing requirements on one page breaking 20 other pages because I changed a div width by a few pixels (upsetting a float on another page for instance).
Thanks for your input
Just like any other type of code, if you are duplicating your CSS code all over the place, you are asking for trouble. Maintenance is going to get harder and harder for you as time goes on.
The best way to not have issues with a change on one page affecting other pages detrimentally is to have a style guide that drives your UI layout and design. If your style guide defintes the HTML and CSS classes to use for a given design element, then they will all always be displayed the same across all pages. If a specific page's element needs to be changed, you change the HTML to use a different class and then build new CSS for that class (and add it to your style guide for reuse). The style guide also allows you to make sure that your HTML is uniform across all developers working on the site, which means even less of a chance of CSS changes causing problems as you do more development.
Another point you need to remember with CSS is that every one of those .css files you create and reference on a page is an HTTP request. If every page and control has its own CSS file, you are really hurting your users' experience on the site by bogging down the total request download time for every single page request. It also makes it less likely for their browser to cache the .css files because the cache has a limited amount of space, so if you keep filling it with more and more .css files, they are going to get dumped from the cache more quickly. Yes, you can combine .css files programmatically in a handler so your page only makes one request per page, but then you have additional server overhead and the caching issue still remains (unless you have a single request for all .css files on your site, which defeats the purpose of what you're trying to do here anyways).
I want to start using modular CSS, but I'm having trouble figuring out the best way to implement it. I was thinking I could just use a bridging technique, where I have one in my HTML and then #import statements for each module. While I like the simplicity of that method, I'm concerned about the negative effects it has on performance, since the #import-ed stylesheets will download later and not necessarily in parallel. So I want to know if there are any other popular techniques for implementing modular CSS. I don't really want to do multiple tags because PageSpeed and Yslow complain about so many stylesheets (although I know it is actually more efficient than #import). Ideally I would like to combine the stylesheets into one on the server, so the browser only every requests one stylesheet.
Using server side includes to assemble your "modules" into one style sheet on the server side is definitely recommended here. So is having some sort of cache on the server so it doesn't have to do the assembly on every request. There are lots of technologies available for this but your message doesn't include anything about your software stack.
Check out the Compass CSS Framework. It supports modular CSS through mixins and makes CSS a lot more pleasant to work with in general by adding variables, arithmetic, and including style frameworks such as Blueprint.
Just be extremely careful how you do this. Caching is your friend, and if you opt to deliver purpose-delivered, server-side generated CSS pages, you'll lose the benefit of caching. It's the classic chicken and egg problem. Do you preload and cache all your CSS and take the hit up front, or custom load each page and incur a hit on every page change? Only you know what's best.
Don't go too overboard on this. I've worked in huge shops where a minor minification change resulted in a 5 gig/day improvement (with millions of uniques)...but most sites I've worked on wouldn't see much if any gain at all. If you've got time on your hands, go nuts. Otherwise, proportion your response based on the need. Those optimizers report on ideal conditions, and we all know that isn't the case in real life. Try runnig the optimizer on some major sites sometime (don't miss trying to validate them either) Makes for good web-geek fun.