This question is a little related to:
Are unused CSS images downloaded?
Let's say I have a CMS that allows the user to pick how the page looks.
Internally the selections are very small CSS files (4-5 lines).
If browsers do not load unused background images, I could safely put all these styles inside the main CSS file, and switch them with a body class. This saves me lots of code that should handle css file switching. Right?
It would always be safe to combine the files. It is considered best practice by today's standards. It is quite common to minify and bundle the js and css files together to reduce requests to the server.
As stated in the post you mention, the browser shouldn't download them until the selector is actually valid, even then the image should only be downloaded one time and should return 304 Not Modified so the browser knows not to download it again.
Anytime you load a css file or change properties on elements, the css is parsed and re-renders the necessary styling.
NOTE: I feel obligated to make sure you take order of selectivity into account when bundling your css files.
Related
We have a ASP.NET/HTML5 web application. To make sure that after every release, new js and css files are used, we add a parameter to the urls
http://myapp.com/public/app.js?rdyyyymmdd
http://myapp.com/public/app.css?rdyyyymmdd
But what about image cache which is causing issues. Images are added using <img> tag as well as they are being added though css (background-image) property.
Now, it is not feasible to add timestamps in css files to all the images. We have hundreds of css files each referencing some images.
So how does one fix this issue?
You could still use a datestamp or GUID. Just add a script to your deployment process which looks for image urls in your compiled css using regex and changes their query string.
Personally I've used Python to do something kind of similar, but I'm sure Grunt / Gulp would be a good candidate if you use them.
Is this an anti-pattern?
For JavaScript and/or CSS code that is repeated between two template files in a Django project, we put that code into a common resource. That resource can then be loaded by a separate request from the client (as is the case with static .js and .css files) or placed in a template file and loaded into the templates that use it server-side, thus avoiding the extra requests that result from creating additional .js or .css files (or increasing the size of existing .js or .css files).
Current practice where I work prefers that latter approach, while I prefer the former. I see the following problems with loading template files on the server side instead of creating additional static files or adding to existing static files:
The number of requests we avoid by loading resource files on the server is insignificant due to caching.
The size of the templates is increased with code that could be cached, meaning that more data is sent over the wire.
This practice spreads CSS and JavaScript code across the project in files that are marked as html templates in spite of their complete lack of actual html text.
When the common code becomes commonly used in more than two pages on our site, we may need to create additional static files (or add to existing ones) anyway.
It is generally a good practice to keep JavaScript separated from the DOM; server-loaded resource files don't do much to encourage this practice.
So, is this an anti-pattern we should avoid, or is it a best practice, and why?
My 2 cents on the issue
Performance wise:
If the JS is important for your landing page rendering, inline it as template.
Otherwise I would generally vote for your way (external JS file) maybe using async, and of course putting the link at the end of the page.
But it some cases like small size scripts, the inline approach can make sense.
I want to make a single server call for css and JS file for to optimize the speed. So can any one suggest me Is this good to merge css and JS with our custom css and JS. And also i override Bootstrap css class in custom css It will create any problem???
well, no problem should happen. putting codes and rules in different files is to manage them in better way.
the point is don't forget to place bootstrap css rules above your own rules. this way your customized rules will override bootstraps.
I suggest you use UglifyCSS and UglifyJS. You can also use an asset management framework for PHP like Assetic that uses these tools easily.
The CSS cascading order is very important, the last declared is more relevant.
You can definitely combine them. Just be sure to do so in the same order you would load them if loading separate files.
Afterwards, minify them using any number of minifiers (just google it), and even gzip them for even smaller files.
Assuming you've done the same with your images and icons (i.e. spriting them) you'll have very few http requests.
Although it is always recommended to put JavaScript and CSS code into appropriate files (as .js and .css), most of major websites (like Amazon, facebook, etc.) put a significant part of their JavaScript and CSS code directly within the main HTML page.
Where is the best choice?
Place your .js in multiple files, then package, minify and gzip that into one file.
Keep your HTML into multiple seperate files.
Place your .css in multiple files, then package, minify and gzip that into one file.
Then you simply send one css file and one js file to the client to be cached.
You do not inline them with your HTML.
If you inline them then any change to the css or html or js forces to user to download all three again.
The main reason major websites have js & cs in their files, is because major websites code rot. Major companies don't uphold standards and best practices, they just hack it until it works then say "why waste money on our website, it works doesn't it?".
Don't look at examples of live websites, because 99% of all examples on the internet show bad practices.
Also for the love of god, Separation of concerns please. You should never ever use inline javascript or inline css in html pages.
http://developer.yahoo.com/performance/rules.html#external
Yahoo (even though they have many inline styles and scripts), recommends making them external. I believe google page speed used to (or still does?) do the same as well.
It's really a logical thing to have them separate. There are so many benefits to keeping CSS and JS separate to the HTML. Things like logical code management, caching of those pages, lower page size (would you rather a ~200ms request for a 400kb cached resource, or a 4000ms delay from having to download that data on every page?), SEO options (less crap for google to look through when scripts/styles are external), easier to minify external scripts (online tools etc), can load them synchronously from different servers....
That should be your primary objective in any website. All styles that make up your whole website should be in the one file (or files for each page, then merged and minified when updated), the same for javascript.
In the real world (not doing a project for yourself, doing one for a client or stakeholder that wants results), the only time where it doesn't make sense to load in another javascript resource or another stylesheet (and thus use inline styles/javascript) is if there's some kind of dynamic information that is on a kind of per-user, per-session or per-time-period that can't be accomplished as simply any other way. Example: when my website has a promotion, we dump a script tag with a small JSON object of information. Because we don't minify and merge multiple files, it makes more sense to just include it in the page. Sure there are other ways to do this, but it costs $20 to do that, whereas it could cost > $100 to do it another way.
Perhaps Amazon/Facebook/Google etc use so much inline code is so their servers aren't taxed so much. I'm not too sure on the benchmarking between requesting a 1MB file in one hit or requesting 10 100KB files (presuming 1MB/10 = 100KB for examples' sake), but what would be faster? Potentially the 1MB file, BUT smaller requests can be loaded synchronously, meaning each one of those 10 requests could come from a separate server/domain potentially, thus reducing overall load time.
Further, google homepages for example seem to dump a JSON array of information for the widgets, presumably because it compiles all that information from various sources, minifies it, caches it, then puts in on the page, then the javascript functions build the layout (client side processing power rather than server-side).
An interesting investigation might be whether they include various .css files regardless of the style blocks you're also seeing. Perhaps it's overhead or perhaps it's convenience.
I've found that while working with different styles of interface developer (and content deployers) that convenience/authority often wins in the face of deadlines and "getting the job done". In a project of a large scale there could be factors involved like "No, you ain't touching our stylesheets", or perhaps if there isn't a stylesheet using an http request already then convenience has won a battle against good practice.
If your css and javascript code is for a global usage, then it is best to put them into appropriate files.
Otherwise, if the code is used just by a certain page, like the home page, put them directly into html is acceptable, and is good for maintenance.
Our team keeps it all seperate. All resources like this goes into a folder called _Content.
CSS goes into _Content/css/xxx.js
JS goes into _Content/js/lib/xxx.js (For all the library packages)
Custom page events and functions get called from the page, but are put into a main JS file in _Content/js/Main.js
Images will go into the same place under _Content/images/xxx.x
This is just how we lay it out as it keeps the HTML markup as it should be, for markup.
I think putting css and js into the main html makes the page loads fast.
Usually, the javascripts of the main page is heavier than other pages. For example, we put jQuery slideshow in the main page which is not used in other pages. Is it necessary to create different s for the main and individual pages to include only in-action javacript files?
Or all javascript files read on the first page will be cached for browsing the website, and in loading an indivitual page, browser will not read the javascript of slideshow?
Another form of this question is: if I put slideshow on each individual page, will the browser load the slideshow javascript file each time, or it will read from its cache (saved on the visitor's computer)?
like florian h says most browsers will cache the content (unless development tools are being used).
if you only use the slideshow javascript on one page I would recommend putting it in a separate file. There is a downside to this, most often the http requests take the longest time with loading a file.
So if you for example have one javascript file of 1mb and you need all the javascript on most pages its better then using 4 smaller files of 250kb each. Because your browser needs to do 4 separate requests.
Ofcourse this maybe is a difference of a couple of milliseconds of performance profit, so you might want to choose to do it in separate files anyway to increase maintainability.
Allmost all browsers will cache the javascript files, so you shouldn't create different versions for sub pages.
But if you have very large JS files it's of course reasonable to only include those that you actually need.
All files are cached in the browser based on the path to the file.
If you include an javascript from one page, the file will be cached and it won't be downloaded again when you surf other pages.
Unless you want it to ;)
Yes, js files will be cached (if not said otherwise).
But, js files must be processed and may include initialization logic that you do not need. Also every script tag that loads external js will block any other "http thread", meaning images, css files... will stop loading untill js file is loaded, otherwise you will have several parallel (at same time) resources loading.
I would have different scripts for different pages.
For your case it might be an issue and it might not be. You should make few test for you case and see whether do you have performance issues. If not than convenience of not having different scripts for different pages might be better.