So everyone knows the pros of having a single CSS file for a webpage.
Only one HTTP request is needed to fetch it
Once stored in cache, all webpages using it will be blessed
But I think there's a great pro of having multiple CSS files
All CSS files will be downloaded parallely, thus less time...
So If I have 500KB of code of CSS and internet speed of 50KBps (yes, i live in a poor country :-/ )...
method A will take (10+x)secs # where x is the time for HTTP request
method B should take (1+x)secs # if I divide it into 10 files
Am I wrong, If I say "Method B is much better" ?
First of all, I would recommend that you use a CSS Minifier, like http://cssminifier.com/.
Regarding your speed test, in your case maybe is really faster to use multiple files, but try it and test your page at Google's PageSpeed Insights
Specially if your target is your own country, and if you know that the internet is slow all over there.
From Here
It's not about bandwidth speed but number of http requests, this makes
a lot of sense for a mobile connection.
However the approach of having different css files to keep the project
modular is solid, as it helps you keeping your css organized the way
you want it without having all the code in one file only. Then you can
benefit of css preprocessors / minifiers to concatenate and compress
all your css files in a single one for production
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
For a big single page web application using ASP.net, MVC5 and Angular JS I'm looking to serve dynamic generated stylesheets. The application will have an big amount of users (> 1000s) that individually can set about 10 variables. These include a few colors and logos. These colors and logos will be used in the less stylesheet to generate lots of classes/styles. The stylesheet is compiled from a lot of files, about 50 .less files.
I'm planning to use the following approach:
On loading index.html, after user login, I call an ASP action to load the stylesheet <link href="Give/Me/My/Dynamic/Stylesheet/For/User/12122312">
The controller action will do its magic and gets the 10 user variables from the database
The server will than use .dotless to compile the less to css
Server returns string
This approach will work, but I'm afraid the performance will be not so good. My questions:
Is dotless the fastest way to compile less?
How long will the databasecall + compiling take?
Is this the way other application do this?
I'm looking if there's a way to cache the css request - maybe check if there has been a change since the last time the css was compiled.
What will not work:
Compile the less to css and then change the variables in the css (saves a compile every time). Some of the colors in the stylesheet will be based upon on of the variables. (eg lighten(#333, 0.3) etc).
Use a static stylesheet and then override these in the head of the HTML doc. There will be a whole lotta custom styles involved!
Some other thoughts:
This solution seems to do the same, but compiles on build:
This solution saves the variables to a static file and uses that for compiling. This saves a database call, but the directory gets crowded with lots of users.
Your planned approach sounds fine. As far as your specific questions go:
Is dotless the fastest way to compile less?
"Fastest" is relative and debatable. The only way to know would be to run this and any available alternatives on your production machine using some sort of benchmarking. Even then, outside factors such as how much load the server is getting, how many requests are being handled simultaneously, etc. can affect those benchmarks. For example, maybe one solution is "faster" handling an ideal scenario, but has a large overhead that causes it to run much slower than another solution when the server is actually being taxed. Overall, it's impossible for anyone to give you any sort of definite answer to this, and really, it's probably too early to even be that concerned about the question. If it becomes a problem in production, then you can start investigating alternatives.
How long will the databasecall + compiling take?
Also completely impossible for anyone to give a definitive answer to. There's way too many variables involved in that relatively simple question. What database are you using? What version? What are the specs of the server it's running on. What else is running on that server? How have you configured the database server? What kind of query are you running? How many tables are involved? What's the size of the resultset being returned? What type of network infrastructure is in place? What's your latency? How capable is your network infrastructure at handling load? There's probably more questions I could ask if I though long enough and that's just about the database call portion. I don't expect answers to those questions; I'm merely trying to point out 1) there's no way anyone can answer that for you and 2) you're going to have to do a lot of research to come up with those answers yourself.
Is this the way other application do this?
This is highly speculative. First, it assumes this is somewhat common, when it's probably anything but. In my 20-some-odd years of doing web development, I've yet to encounter a scenario where I needed a dynamic stylesheet. Granted, for a large part of those years stylesheets didn't even exist or at least weren't heavily used yet and just because I haven't had a need doesn't mean there's not still a perfectly valid business-case for this. I understand the desire to want to find an accepted pattern or best practice to follow, but the sample set here is probably so small that no such thing exists. Trust your gut. Build things in a way that makes sense. Then test, refine and refactor. That's really the best advice I can give you.
I'm looking if there's a way to cache the css request - maybe check if there has been a change since the last time the css was compiled.
This one is pretty easy. Just make sure to set the appropriate response headers before returning your response. Expires is really your go-to here. If the stylesheet virtually never changes for the user, then you can set a far future Expires header and the client's browser should cache it requiring all this infrastructure to not have to do its thing again for a while. If the change-ability is variable (any time the user updates a setting, they need a new version, and this can happen at a whim), then you can still use a far-future Expires header and employ a cache-busting querystring param that will force the browser to get a fresh copy. A good choice might be adding the last modified date for the settings when rendering the link for the stylesheet. If the user hasn't modified anything, then the date won't change and the original cached version will be used. But if the date has changed, it will look like a new URL to the browser, and it will be fetched fresh.
Since web fonts have some ins-and-outs pertaining to cross-domain hosting, being a developer who provides code for a multitude of clients that want to use such web fonts to leverage their aesthetic quality, can be challenging especially when trying to detail the technical steps of hosting a file and making sure the URL path is pointing to it properly.
Recently, I have come across a webfont that uses a
data:application/font-woff;charset=utf-8;base64, "longHash"
nomenclature and I am not familiar with this.
One great benefit of this is that it seems that this doesn't have the cross-domain pitfalls of using a URL for a font, example here:
http://jsfiddle.net/9336yqkL/1/
If you look at the link you can see that it's a series of alphanumerical characters quite long in length where the URL path typically is.
I wonder, how does one create a path like this?
Help is always appreciated!
Base64 is an encoding scheme for binary. You can use a decoder to get the binary contents of the alphanumerical text that comes after base64,. The entire process is called Data URI Scheme and has a list of pros and cons for using it. http://en.wikipedia.org/wiki/Data_URI_scheme#Advantages_and_disadvantages
This is a real question...
Is there a way to use less.js as it could generate static css files, those files that will be cached and reprocessed on demand and not on the fly ?
That means generate css cached files to avoid on the fly generation and leverage performance benefits of static files, but keeping the flexibility of writing in less.
This is more way interesting when using css framework like bootstrap, with the need of reusing less variables.
This is supposed to be used in a production environment (we don't own nor control) by webdesigners who are not able to install anything on the server side.
Thanks a lot for any answer !
You need some sort of compiler like this: http://wearekiss.com/simpless
I have a question about storing site configuration data.
We have a platform for web applications. The idea is that different clients can have their data hosted and displayed on their own site which sits on top of this platform. Each site has a configuration which determines which panels relevant to the client appear on which pages.
The system was originally designed to keep all the configuration data for each site in a database. When the site is loaded all the configuration data is loaded into a SiteConfiguration object, and the clients panels are generated based on the content of this object. This works, but I find it very difficult to work with to apply change requests or add new sites because there is so much data to sift through and it's difficult maintain a mental model of the site and its configuration.
Recently I've been tasked with developing a subset of some of the sites to be generated as PDF documents for printing. I decided to take a different approach to how I would define the configuration in that instead of storing configuration data in the database, I wrote XML files to contain the data. I find it much easier to work with because instead of reading meaningless rows of data which are related to other meaningless rows of data, I have meaningful documents with semantic, readable information with the relationships defined by visually understandable element nesting.
So now with these 2 approaches to storing site configuration data, I'd like to get the opinions of people more experienced in dealing with this issue on dealing with these two approaches. What is the best way of storing site configuration data? Is there a better way than the two ways I outlined here?
note: StackOverflow is telling me the question appears to be subjective and is likely to be closed. I'm not trying to be subjective. I'd like to know how best to approach this issue next time and if people with industry experience on this could provide some input.
if the information is needed for per client specific configuration it is probably best done in a database with an admin tool written for it so that non technical people can also manage it. Also it's easier that way when you need versioning/history on it. XML isn't always the best on that part. Also XML is harder to maintain in the end (for non technical people).
Do you read out the XML every time from disk (performance hit) or do you keep it cached in memory? Either solution you choose, caching makes a big difference in the end for performance.
Grz, Kris.
You're using ASP.NET so what's wrong with web.config for your basic settings (if it's per project deploy), then as you've said, custom XML or database configuration settings for anything more complicated (or if you have multiple users/clients with the same project deploy)?
I'd only use custom XML documents for something like a "site layout document" where things won't change that often and you're going to have lots of semi-meaningless data (e.g. 23553123). And layout should be handled by css as much as possible anyway.
For our team XML is a good choice (app.config or web.config or custom configuration file, it depends), but sometimes it is better to design configuration API to make configurations in code. For example modern IoC containers has in-code configuration APIs with fluent interfaces. This approach can give benefits if you need to configure many similar to each other entities or want to achive good human readability. But this doesn't works if non-programmers need to make configurations.
I'm in the process of taking a couple of separate asp.net applications, and combining them.
One problem is rationalizing the CSS between the two app - app1 has two css files, while app2 has about 8 of them. Much of the CSS between the two apps is the same, but there are some differences. I'm looking for a tool to compare all the elements of each app, and show what's missing, what's different, etc. Ideally the output would be 3 files: Common, app1 and app2, but I won't be that fussy if it can just show me the differences between the two apps.
Does such a tool exist?
If you hate downloading tools, there's an online version of css comparer here http://www.alanhart.co.uk/tools/compare-css.php
It provides a comparison of css class files between two files
I don't know of a stand-alone tool tailored for this specific purpose. There's a PHP class called "CSS Comparer", but I have no idea how easy it is to use. The screenshot on that page looks promising though.
Personally, I would probably just concatenate all the files together, so that you have one file for each app, and then run a diff on them. To make it even easier, you could run both files through something like CSSTidy or do some imaginative file processing with search/replace and sorting. That could get all the declarations in the same order in both files, so the diff would be clearer.
Combine all of these files into a single file and give it a run through a CSS optimizer or compressor. An optimizer should see all of your duplicate selectors and weed them out.
I'd recommend YUI's compressor, but there are plenty of web-based compressors/optimizers available, too. Here's one and another. YMMV with them, but a good Google search can turn up a bunch more.
Normally I'd recommend diff. Since you explicitly write that you are looking for something "not diff based", maybe you could describe why diff does not help you.
Then others might be able to propose something different.