I have you finished my first real project and I laughed it. However, the loading speed of the CSS and js takes some seconds. Both files are hosted on AWS, however, I do not think that is the reason for the speed problem. The thing is that the files are like 3MB I do not know if that is too much, I tried to minify them, but still, it takes some time. By the way, you should know that I bought my HTML templates, rich means that the CSS was not written by me. Any recommendations, I would really appreciate it.
Related
I'm working on a web project that uses webgl content generated with unity. When trying to load the required js files the browser freezes for around 30 seconds. The main js file has 35MB size unzipped so this seems to be the cause.
I want to avoid this freeze if possible but I couldn't manage to do it using WebWorkers since the script needs access to UI. My other possible solution is to try to split the js file into smaller ones but I don't know how to do it. Do you have any suggestions?
If you add async to your script tag like this <script async src="app.min.js"></script> it will not block rendering anymore. Also caching the script in the browser or delivering it from a CDN can help reduce the download time.
35MB are, however, way too much for a website. Are you sure there isn't a lot of unused stuff like libraries in it?
We recently wrote an article with web performance best practices, with explanations to critical rendering path and other fronted concerns here
35 MB just for the JS file seems ridiculous. It could be that the entire build is probably of that size (textures, media, etc.). Have a look here on how to reduce the build size.
Though 35 MB is wayyyy to much for a JS file, you can start by following pointers:
Create utilities and reuse the code. This can be at any level. Be it generic component (HTML generating code) or validation logic, if it can be configured using arguments, make a function and use it.
If you have Hard-coded JSON in your js, move them to .josn files and load them only when they are required.
Split files based on sections in view. In SPAs, there are cases when a section is not visible. For such cases, don't load such files. Spread your code base from 1 file to 100s of file.
If you have a lot of event listeners, move them to different file. You can have section_event.js, section_data.json, section_utils.js and section_index.js. If there involves lot of data parsing, you can even have section_parser.js
Basic Idea is to split code into multiple files. Then, make code more reusable. You can even look into loading libraries to reduce your load.
Also, load a resource only when required. SPA have stages. Load concerned files when they are needed. Split download from 1 time to partial, on-demand approach. Also look into webpack or grunt or gulp to minify js.
My website uses about 10 third party javascript libraries like jQuery, jQuery UI, prefixfree, a few jQuery plugins and also my own javascript code. Currently I pull the external libraries from CDNs like Google CDN and cloudflare. I was wondering what is a better approach:
Pulling the external libraries from CDNs (like I do today).
Combining all the files to a single js and a single css file and storing them locally.
Any opinions are welcome as long as they are explained.
Thanks :)
The value of a CDN lies in the likelihood of the user having already visited another site calling that same file from that CDN, and becomes increasingly valuable depending on the size of the file. The likelihood of this being the case increases with the ubiquity of the file being requested and the popularity of the CDN.
With this in mind, pulling a relatively large and popular file from a popular CDN makes absolute sense. jQuery, and, to a lesser degree, jQuery UI, fit this bill.
Meanwhile, concatenating files makes sense for smaller files which are not likely to change much — your commonly used plugins will fit this bill, but your core application-specific code probably doesn't: it might change from week to week, and if you're concatenating it with all your other files, you'd have to force the user to download everything all over again.
The HTML5 boilerplate does a pretty good job of providing a generic solution for this:
Modernizr is loaded from local in the head: it's very small and
differs quite a lot from instance to instance, so it doesn't make
sense to source it from a CDN and it won't hurt the user too much to
load it from your server. It's put in the head because CSS may be
making use of it, so you want it's effects to be known before the
body renders. Everything else goes at the bottom, to stop your
heavier scripts blocking rendering while they load and execute.
jQuery from the CDN, since almost everyone uses it and it's quite heavy. The user will probably already have this cached before they
visit your site, in which case they'll load it from cache instantly.
All your smaller 3rd party dependencies and code snippets that aren't likely to change much get concatenating into a plugins.js
file loaded from your own server. This will get cached with a
distant expiry header the first time the user visits and loaded from
cache on subsequent visits.
Your core code goes in main.js, with a closer expiry header to account for the fact that your application logic may change from
week to week or month to month. This way when you've fixe a bug or
introduced new functionality when the user visits a fortnight from
now, this can get loaded fresh while all the content above can be
brought in from cache.
For your other major libraries, you should look at them individually and ask yourself whether they should follow jQuery's lead, be loaded individually from your own server, or get concatenated. An example of how you might come to those decisions:
Angular is incredibly popular, and very large. Get it from the CDN.
Twitter Bootstrap is on a similar level of popularity, but you've got a relatively slim selection of its components, and if the user doesn't already have it it might not be worth getting them to download the full thing. Having said that, the way it fits into the rest of your code is pretty intrinsic, and you're not likely to be changing it without rebuilding the whole site — so you may want to keep it hosted locally but keep it's files separate from your main plugins.js. This way you can always update your plugins.js with Bootstrap extensions without forcing the user to download all of Bootstrap core.
But there's no imperative — your mileage may vary.
In my project each page has a bunch of dependent Javascript and Css. Whilst developing I just dumped this code right into the page but now I'm looking to clean it up...
it appears that the general approach out there is to package all the Javascript/CSS for an application into two big files that get minimised.
This approach has the benefit that it reduces bandwidth since all the front-end code gets pulled in just once from the server... however, I'm concerned I will be increasing the memory footprint of the application by defining a whole ton of functions for each page that I don't actually need - which is why I had them on a per-page basis to begin with.
is that something anyone else cares about or is there some way to manage this issue?
yes, I have thought of doing conditional function creation since I need to run code conditionally for each page anyway - though that starts to get a bit hackish in my view.
also, is there much cost to defining a whole ton of Css that is never used?
Serving the javascript/CSS in one big hit for the application, allows the browser to cache all it needs for all your pages. If the standard use case for your site is that users will stay and navigate around for a while then this is a good option to use.
If, however, you wish your landing page to load quickly, since there is a chance that the user will navigate away, consider only serving the CSS/javascript required for this page.
In terms of a performance overhead of a large CSS file - there will be none that is noticeable. All modern browsers are highly optimised for applying styles.
As for your javascript - try not to use conditional function creation, conditional namespace creation is acceptable and required, but your functions should be declared only in one place.
The biggest thing you can do for bandwidth is make sure your server is compressing output. Any static document type should be compressed (html, js, css, etc.).
For instance the jQuery Core goes from approx. 90KB to 30KB only because of the compressed output the server is sending to browsers.
If you take into account the compression, then you have to create some mammoth custom JS includes to really need to split-up your JS files.
I really like minifying and obfuscating my code because I can put my documentation right into the un-minified version and then the minification process removes all the comments for the production environment.
One approach would be to have all the shared javascript minified and compressed into one file and served out on each page. Then the page-specific javascript can be compressed/minified to its own files (although I would consider putting any very common page's javascript into the main javascript file).
I've always been in the habit of compressing/minifying all of the CSS into one file, rather than separate files for each page. This is because some of the page-specific files can be very small, and ideally we share as much css across the site as possible.
Like Jasper mentioned the most important thing would be to make sure that your sever is GZIPing the static resources (such as javascript and css).
If you have a lot of javascript code you can take a look on asynchronous loading of js files.
Some large project like ExtJs or Qooxdoo have build in loaders to load only required code, but here is a lot of libs which simplify this, and you can use in your project (e.g. head.js, LAB.js).
Thanks to them you can build application which loads only necessary files, not whole javascript code which in case of big apps can be a heavy stuff for browser.
I have a website that's using the extjs librar. Exactly I just need grid, ajax and tree component.
My project is used nationally, and to avoid problems due to low bandwith in the some regions, I must to make it as light as possible.
When I use the developer tools in chrome, my site is too heavy. Especially when loading ext-all.js. It take 3,9 minutes to load(#512kbps), (even when I remove my own images and css from the website).
Is there a way to compress it? Or to just load the tree, grid and ajax components?
I was googling.. and I got this
<script type="text/javascript" src="js/ext-all.js?compression=gzip"></script>
but, it didn't help much.
This is the page that shows you how to build custom versions of ext-js. http://www.sencha.com/learn/Tutorial:Building_Ext_From_Source
They had a link to an online builder that would customize the download but it's been taken down. The link mentioned still points to good resources like JsBuilder, the tool they use to generate ext-all.js and the other packages in the distribution. Just open the ext.jsb to see how it works
You'll need to figure out the dependencies on your own though, good luck!
I'd estimate that at 512k, the extjs load should be around 30 s - 1 minute.
If you're looking at a 4 minute load time, your time is probably spent somewhere other than the download of the library. Are you sure it's the size of your download, or even extjs that is the problem? Could it be that your webserver is under heavy load, or that you're dealing with a latency issue?
As far as reducing the size of the library - there isn't much more you can do. The library is provided in minified format, and stripping it further is not recommended. Zipping it up only means you'll have to unzip at the other end once downloaded, and doesn't buy you that much load time with a library that's already very small.
I need a tool which can minify, optimize and munge many files of those possible types
HTML (minify only)
JavaScript (minify, optimize and munge)
CSS (minify)
The final result should be one HTML file only with all JavaScript and CSS embedded or in the worst scenario 3 files respectively for HTML, JS, and CSS.
I am aware of tools like YUI Compressor etc. What I currently have not found is the type of compressor which will work on all those file types and merge them in one huge file only.
If you're not using gzip yet, start using it already and we can close this thing out ;)
My suggestion would be to put all of the JavaScrpt inside a <script> in the header, and put all of the CSS in a <style> tag as well. Then optimize to the best of your ability and then minimize it on your own. No software will ever be able to handle every case. If you are trying to minimize the file size then just remove the newlines and non-necessary spaces.
I also found this, which should work on your file with all 3 in it.
Also be aware that if you start removing optional tags you could run into some problems. Some browsers don't cooperate as well as they are supposed to.
Gad, consider the drawbacks to minifying CSS. If you don't have a system where you edit normal/minify/ then deploy it can make later editing of CSS rather dicey.
I went through this whole argument on a big UI refresh project for an international bank. One site in particular was doing 1million+ visitors/day and bandwidth numbers were insane despite all our efforts to keep it minimal (every little bit adds up on a site that heavily trafficked) Upon business analysis by a large team of very talented minds, it was determined that we would take several steps, but NOT css minifying due to the added time it would take engineers to undo the minifying before fixing, minifying and redeploying for simple CSS tweaks. The numbers showed that even with a 5gb/day bandwidth improvement, it was still cheaper to not pay a UI engineer for the extra time.
We don't know your site's specifics, but there aren't terribly many that have to worry about the traffic my example uses. Run your site in Firebug's new speed analyzer and see what the real benefit could be from minifying.....now multiply that by your traffic. Usually, that number isn't too scary. Spend your time doing image sprites, combining css and js into respective files (better than mashing into individual php files due to caching benefits) to limit http requests, and ensuring that caching is properly setup. Run gzip compression. If after those steps you're not good, then take the site to a new level.
Keep it simple....it makes a huge difference in the update and maintenance portions of the site's lifecycle. With the time and headache saved, you can help us out with our questions :)
As far as I know there isn't such a tool. If you use PHP on the server side, however, you can try PHP Speedy (not actively developed, but works) or Minify for automated minification, caching and gzipping (HTML, CSS, JS).
edit: kangax's HTML minifier (as Badger suggested) only does HTML minification.
you can use jsCompressor to compress and minify multiple JavaScript files and CSS Compressor to compress/minify multiple Css files into one file.
and to optimize your HTML files you may send post request of your code to Google Clouser server which sends response with optimized Html code.
http://prettydiff.com/?m=minify will do exactly what you need, except that it only minify JavaScript and not obfuscate it.
I suggest you look at the build script that's included in the html5 Boilerplate: http://html5boilerplate.com/. With some minimal tweaking it'll do what you're looking to do.