Let's say I have a website with following pages:
www.server.com/index.php
www.server.com/anotherPage.php
www.server.com/css/style_for_index.css
www.server.com/css/style_for_anotherPage.css
Assuming, I am visiting www.server.com/index.php:
When using .appcache manifest in the <HTML> tag, I understand that every associated file of this page is automatically cached anyway.
But if I wanted to load, at the same time, www.server.com/anotherPage.php, then I would also have to load www.server.com/css/style_for_anotherPage.css in the CACHE section of the manifest.appcache file.
What I don't understand is if I would also have to include the background-images from www.server.com/css/style_for_anotherPage.css into the manifest.appcache file.
I understand that every associated file of this page is automatically cached anyway.
This is incorrect.
You need to explicitly mention any resource you want to be cached, except for the so-called master entries. Master entries are the HTML files that include a manifest attribute in their <html> element. So also any images, scripts, stylesheets referenced by these files.
Obviously, you need to also include any files referenced by your css or javascript files, if you want them to be available offline.
Related
I am using Magnolia CMS 5.3.4, the STK, and freemarker (FTL) template scripts.
Some components I have defined relies on specific javascript files. Right now, what I do is that I include these javascript files in the main.ftl template script. I am looking for a way to get them included only if the specific component is present on the page.
I tried to use the jsFiles property in Template Definitions, but it seems it works only for page template definition.
The jsFiles property indeed works only for pages not for components. This is because Magnolia wants to include those files in header already, rather than loading them in middle of the body when component gets rendered.
As a general practice I would anyway recommend combining your js files into one (look at for example plugin loader in resources on how this is done) and set longer time for caching such file so that browser downloads all the script just once for the whole site rather then page by page. The bigger js file you are sending over the more overhead you are cutting off from requesting separate files and better the compression of content for transport will work.
HTH,
Jan
Recently we have experienced the problem of browsers caching the css files, so that when we move code to another web server we get unexpected and unwanted results.
Having read various solutions it occurred to me that the css file could be included in the template. Rather than write
<link href="/static/css/parentx.css" rel="stylesheet" type="text/css">
we could put
<style>{% include "static/css/parent.css" %}</style>
which would embed the css in the html. It has the added benefit of reducing the number of calls back to the server for the css file but the disadvantage of not caching the css at all and not allowing the web server to provide the static files. However, these files are quite small, typically about 12K.
I propose this as a temporary measure as I have just discovered the existence of asset management plugins that look to do a better job.
I have never seen the use of the 'include' template command to get css (and javascript) files so perhaps there is a drawback of which I am unaware?
Not caching the CSS file at all will slow page loading though it's unnecessary.
Cache your CSS as long as possible and necessary and when you need to invalidate cache, a sure way is to load another file, I mean the same file with another name. It could be parent1391234565.css or parent-v003.css or parent130307.css or parent-4e6ca1437f2d.css. If you told browsers to download parent-v002.css, you're pretty certain they don't have parent-v003.css in their cache!
When I clear my theme registry Drupal runs off and builds out a nice consolidated css file, but it does this for different node/page types so that I get several instances of said file existing. I mentioned this in another question I asked (and answered), but my question is, how does Drupal deduce what css files it needs to add to the consolidated version? There must be numerous different places that control what modules appear on a particular node, so what constitutes a rule for another css file being built?
Well that wasn't an easy chain of functions to follow but I think I've got there...
Every time a page is 'refreshed' (i.e. built from scratch, not served from cache) all CSS files added with drupal_add_css() during that page build are aggregated and saved to a single file that is returned as the <link> tag for that page.
The following line in drupal_add_css() decides what the aggregated CSS file's name will be:
$filename = 'css_'. md5(serialize($types) . $query_string) .'.css';
$types in this context is an array of all of the CSS files added using drupal_add_css() during the current page build. The filename for the aggregated CSS contains a serialised string of $types, which essentially means that any other page that adds the same CSS files as that one will receive exactly the same file name and thus load the same CSS file.
So basically, the aggregation function is run for every single page build so all CSS added to that page will be aggregated every time. If certain pages happen to use the same modules then they will automatically be served the same CSS file as defined in the PHP snippet above. When you combine that with page caching you get the results you find in the HTML source on the different pages.
Hope that makes sense!
I am building up a website using MVC architecture. It takes a lot of css with it. I require atleast 20 css files to store within it each associated with some unique views. I want to know where can I store the css files? Either in a single root css directory or shall I store it with a particular view. Also linking these files within the common template file would be tedious enough. I mean it would show up 20 different tags. Is there any alternative way to do this? Please help. I am using codeigniter framework by the way.
What I do is store it all in a css folder inside the public folder (the one that houses your index.php file). I also have a helper method that generates the actual link tags, so in the template files, I just have something like:
<?= stylesheet('sheet1','sheet2','sheet3') ?>
The helper method that calls would then make the links (and assumes that they're in the public/css directory).
That cleans up the raw template files, though it does still make multiple tags in the files themselves. I use partial views, so there's a master view that has the main CSS file(s) that are used on every page (or almost every page), then add in on each template the ones that are unique to the view.
If you have 20 CSS files, you might want to go through and see what you can tidy up and make more generic. Any place where you have more than one of the same styles (even across files) is up for the chopping block. Any extra files should be relatively small and provide only overrides for the exception pages (and if you can genericize those more, so you use a file for more than one page, then that's even better).
I would recommend you to combine all the CSS files in a single file. Its easier to maintain and you will have only one request to the server. Having so many css files will only increase the loading time of your page. Also gzip the css files to increase the page speed.
In VS 2008, I have an ASP.NET content page having one master page. I would like to add JavaScript functions for client side validation etc. for this page. My questions are:
Should I write these scripts in a separate .js file, or embedded within the .aspx file.
Does this choice affect the performance of the website?
Are there any rules for writing a JavaScript file?
I would say, you should create javascripts functions into separate .js file and link them up inside the the master page or .ASPX where it's needed.
Imagine you "copy and paste" the javascripts functions in each of the .ASPX, then when that .ASPX file is loaded, it will take longer to render that page since it needs to render also the javascript functions. If you maintain it into separate .js file, the browser will only download once if it's newer or not exist before.
You can also cache those .js files, so that the browsers won't reload it everytime.
The other advantage is when you need to make some changes in the .js files, you just need it to modify it centrally at one file, rather than do a "Find and Replace" through numerous .ASPX
You should consider the power of caching, if the JavaScript functions are likely to be used on several pages a user will visit. In this case you should put them in (if possible) one external .js file. With this the file will only get fetched once from the server and then stays in the browser cache. Your HTML pages get smaller (significantly for larger JS libs).
If the functions (typically validation rules) only apply to one single page only, an external JavaScript file would lead to an extra HTTP request that leads to a short blocking in the user's experience of your page. Here it's better to embed the JS in the HTML file.
See Yahoo!'s tips on this for more detailed hints.
Cheers,
It depends on your use. If its a page specific functionality then try and implement it in the page itself. If it is used by many pages then put that inside a js file.
Does it affect the performance of
website?
Yes, it can. If you have a js file with thousands of lines of code and in a page you have to call only one function inside the js file. If you refer the file for this one there should be a bandwidth wastage in downloading the entire file. For this case you can write the function inside the same page itself.
On the other side browser can cache a js file. So for subsequent requests if the file is present in the cache it won't be downloaded again. But in the case of JavaScript being written in the page itself, every time the page loads all of its contents will be downloaded.