Rails 3.1 loads pages terribly slow in development. It's processing them through the pipeline, one at a time, and takes way too long.
Is it possible to precompile my assets (which I'm not testing right now, so static files are fine) and have Rails not be responsible for serving them? Would that make things faster?
Update: Got a solution.
Richard Hulse has the correct answer to this question. rake assets:precompile will prebuild assets so they are served directly, without the asset pipeline.
But Frexuz's answer solves the problem of slow loading I've been having. Loading the Rails-dev-tweaks gem makes page loading in development markedly faster.
I had the same problem! It could take from 2-4 seconds extra to load a page because of the assets.
Take a look here (a gem): Rails 3.1 is very slow in development-mode because of assets, what to do?
This made serving assets almost instant (server console says 1ms per asset), using the asset pipeline normally.
Yes.
You can run the precompile task (in 3.1.1) and it will just work - the precompile task will give you assets without fingerprints as well as with, which is what you need in development mode. (Fingerprints are not added in dev mode).
Beware that you don't commit these to source control though.
What is more of a concern is the slowness. I have 4 stylesheets and 15 javascript files in my manifests, and it is only a bit slow on the first request.
What do you see in your logs when the assets are accessed? You should be able to see them being compiled on the first hit and each subsequent request should be a 304 not modified.
Also, do your config settings for dev match those in the asset pipeline guide? If you were compressing in dev mode with lots of files, this could be a source of slowness.
Related
Our release bundles are kinda huge (~50MB) and the clients take approx. 1-2 mins to download the update from codepush.
We're mostly just updating the js bundles, is there a way to just delta update the js bundle without re-downloading all image assets?
I've read from here that the server performs files diff, but it doesn't seem to work on my case: Logging RemotePackage.packageSize from checkForUpdate on clients shows the exact size of JS bundle + image assets, despite the fact that I've only changed the JS code.
Is there something I can do about this?
The CodePush backend should only serve the full contents up to the point it finishes creating a diff zip. On the backend your package is downloaded, extracted and analyzed for files that are different. Any new/updated/removed files are reconciled, put into another zip and shipped back up to the backend so users get served that instead of the original one you release. If you are seeing the full download, it's either because the backend is still working to process the diffs or there are differences inside your bundle.
I would try to do a release, wait 10 minutes and check to see if it is still downloading the full bundle. If it does, it'd be best to contact support for a deeper dive. As far as I can tell bundle's are processing correctly with next to no errors and running a quick test myself produced the correct results for me.
'import {ComponentHere} from "angular2"', this one hits the server with so may calls for getting all the required file. Is there any way to decrease the number of calls to server?
//localhost:9739/node_modules/#angular/common/src/directives/core_directives.js.
//localhost:9739/node_modules/#angular/common/src/pipes/uppercase_pipe.js".
//localhost:9739/node_modules/#angular/common/src/forms/directives/control_container.js".
etc..
Consider using a WebPack (https://angular.io/docs/ts/latest/guide/webpack.html) it normally will decreased the number of files sended to client (but they will be obviously bigger)
You can use "SystemJS Builder" (https://github.com/systemjs/builder) and integrate it into something like Gulp to make it part of your build process for bundles. You give it an entry point (your app) and it then looks at your dependency tree to build your bundle(s).
When your bundle is used, systemjs will import from your bundle instead of every little js file. When I tested with angular2, I had over 700 files downloaded in DEV and only 35 in PROD when using the bundle.
Our Rails 3.2 application uses 4 different hosts as CDN. Upon deployment, we have a task that run assets:precompile on these 4 boxes. The problem we're facing is that the assets that are compiled have different fingerprints/digests. My understanding is that the fingerprints/digests are generated from the content of our assets file so they should be the same across different boxes. Does anyone know what the cause might be? Thanks,
I have dug around in the code and can't see why this is. They should be the same.
If you are deploying to 4 hosts you might want to consider precompiling locally - see this answer for details - as it is a lot faster.
I'm in the process of upgrading a 3.0 Rails App to 3.1.4 including the Asset Pipeline.
I'm on Heroku, so I'm I have this in my application.rb
config.assets.initialize_on_precompile = false
I noticed that when I run:
bundle exec rake assets:precompile
it creates files in a public/assets directory (even though my assets are in app/assets already).
For example, it creates files like application-72b2779565ba79101724d7356ce7d2ee, as well as replicating the images I have in app/assets.
My questions are:
(1) should be uploading these files to my production server?
(2) if I'm suppose to be uploading these, am I suppose to update each application-xxxxxxxx or only the latest one?
To your first question: Heroku will not allow you to modify the filesystem. So your assertion is correct- You will need to pre-compile the asset pipeline before you send it up to Heroku, so that it can be utilized in your production environment.
And the latter: You'll want to make sure you have the latest compilation. Any others wont be used. The "xxxxxxx" portion is to make sure that your users have the latest and greatest version of your assets. It's a way of versioning what the browser gets, and making sure they're not caching a bad copy of the JavaScript, when you want to set up their cache to hold on to the JS and CSS files as long as they can, instead of constantly getting it from your web server.
Take my Heroku comments with a slight grain of salt, as I have not deployed to Heroku before. I just know how their system works to some degree.
Since I'm running my app on the Bamboo stack I'm precompiling my assets and committing them.
I've included the file manifest.yml in public/assets/ but heroku doesn't detect it. As a result it tries to compile assets and borks itself.
Am I missing something?
Ok, I discovered that I was trying to serve up unprocessed files from the public directory.
Also, I migrated my app to cedar which helped too. :)