I'm trying to integrate django-compressor into an existing django project for performance reasons.
I've added {% compress css %} and {% compress js %} tags around the blocks in my root template where all JS and CSS scripts are included by child templates (ie. all other pages on the site extend those blocks in the root template to put their page-specific files). This works perfectly most of the time, but one page has an embedded Google Map with a JS header:
<script type="text/javascript" src="http://maps.googleapis.com/maps/api/js?libraries=weather&key={% include "google_maps_api_key" %}&sensor=false">
This triggers an exception when rendering the page:
Caught UncompressableFileError while rendering: 'http://maps.googleapis.com/maps/api/js?libraries=weather&key=MYAPIKEY&sensor=false' isn't accessible via COMPRESS_URL ('/media/') and can't be compressed
Is there any way to tell django-compressor to skip this script? Is there some way to have it access and compress the remote script?
No, AFAIK this is not possible (without modifying django-compressor quite heavily). The best solution, based on your description, would be to have separate blocks for local, compressable scripts and remote scripts, and have your child templates use those appropriately.
Is it technically possible? Yes... You could download the map to your assets folder and then compress from there.
However, this is against Google's Terms of Use and may create some weird edge cases. Better bet is to move the tag for maps outside of {% compress %} call. Since google maps is already precompressed, and hosted on Google's fast CDN, your webpage will load faster anyway than if you tried to server yourself.
Related
I'm a new player in Meteor, just did some easy examples and I realized that all the script tags are imported in the beginning of the body tag. According to my experience and yahoo's 14 rules, js files should be imported in the end, Why is that? And in what circumstances js files should be imported in the beginning?
In traditional websites, where the HTML is sent as-is from the server, placing external Javascript files near the bottom of the <body> tag speeds up the page rendering and improves user experience because the static page, along with it's included external assets such as images, is loaded and rendered before the scripts finish loading.
In Meteor however, the HTML is built by Javascript in the client's browser, so all the scripts need to be loaded for the page to render anyway. Moreover, usually there is basically nothing other than scripts in the <body> of a Meteor app's HTML source anyway.
I am working on project with larger javascript files.I can add these javascripts in one of the two ways.
1) create a separate class library project and have the javascript files there as embedded resource.Include a reference of the dll into the web project and then include those using scriptmanager as webresource.
2)Have these files in a separate folder and then simply add these files using the script tag and there path.
I am not going to paste the javascripts in my page within the script tag cause they would mess my pages mark up.
So I would like to know which one is better of the above 2 ways.In either of the 2 ways everytime i load the web page i see GET request for the js files.If i create a javascript dll will the browser cache it?
You can't create "javaScript dll". JavaScript is a client-side stuff, dll is server-side. No matter in which project your javaScripts are, it will still be sent to the client and executed there. So it makes no sense to put JS files to another project (especially as resources)
We usually want to minify and bundle the JS files, so the client will do less requests to the server and also to reduce the amount of data to transfer.
For minifying the JS files I would recommend to use Web Essentials extension to VS. It is very handy and can make web programming easier.
Minification will remove all unnecessary characters from the JS file and it will also reduce the length of the identifiers (like method names and variable names).
You can learn about bundling here. It is useful when there are more JS files to load to load all of them at once.
I recently got into RequireJS and am integrating it into my backbone applications.
I noticed when looking at the source code that all individual javascripts are replaced by the bootstrap file, the line that reads:
<script data-main="js/main" src="js/require.js"></script>
And this line prevents me from viewing the attached files.
Does this mean that users are unable to hack their way into my external source code files if I load all scripts through the bootstrap file?
I am mostly concerned because I use a restful api route in my Backbone collections, and want to keep user data safe.
Thanks.
No, it doesn't mean that. It just means that scripts are loaded dynamically. Anybody can still download your JS files or look at them with any web debugging tool
Many third-party website tracking tools and widgets (e.g. Google Analytics, Piwik) require you to copy-and-paste Javascript code into the bottom of your site, right before the closing body tag.
If your website is Django based, what's the standard way of adding this type of code to to the site?
Do you:
paste it directly into base.html
create a {% block extra_js %}{% endblock %} right before the closing body tag in base.html and stick it in there and/or another template
create a new Django app (assuming there's no existing one yet or none that meets your needs)
or do something else?
And if you're a consultant dealing with inexperienced clients and you do option 3, do you advise your clients to take the same approach when they're adding to the project code themselves?
Directly into base.html if the code is the same for all.
If necessary, wrap it in a block tag so that you can override (to remove or replace) in templates that inherit the base.html.
Recommended to use EXISTING APPS or CREATE a new APP.
say for google analytics i will use http://code.google.com/p/django-google-analytics/
This way is easy for Maintaining the App.
A separate app is a another overhead.
If you want to use it on all pages, follow your point 1.
If you don't want that in all pages, put that in in a block and inherit wherever necessary.
I am building two ASP.NET MVC sites. There is a certain amount of content I wish to be able to share between the two sites. I created a class library and was able to share a large portion of what I needed too. However I would really like to know how I could share contents such as images and JavaScript files, so I do not have to duplicate them between both web sites.
I would be very grateful if anyone has any good ideas on this.
You could use a CDN (content delivery network) for shared files.
<script src="http://shared.yourdomain/stuff.js" type="text/javascript"></script>
It's the same trick that SO employs, it's good for load time too as the browser will only open 2 connections per domain. Using a CDN means that you can add another 2 connections per CDN used. That can include sub domains on your own site. So you could have js.yourdomain and img.yourdomain and they're all counted as different.
If you have a common assembly you may consider embedding your content as web resources. More info about web resources can be found here.
For javascript you can directly give url as src of JavaScript.
e.g.
<script src="some_url_path_/global.js" type="text/javascript"></script>
To share a class I recommend to use web services rather to allow access to class file source.
Javascript files and images can be hosted in a common location - for standard javascript files (jquery library etc.) it's a good idea to use a CDN as Kieron points out - you get a lot of benefits there.
For other content files you can just put them on a common url that is accessed by both sites - e.g. with 2 sites on different urls:
http://site1.somedomain.com/default.aspx
http://site2.somedomain.com/default.aspx
they can both use content from a common location like:
http://commoncontent.somedomain.com/images/bigimage1.jpg
http://commoncontent.somedomain.com/scripts/customjavascript1.js
The same thing works with virtual directories instead of a fqdn too of course.