A web site consist of many more files than just the
HTML documents we have been generating up to now:
css files, javascript files, image files, font files, ...
The asset pipeline is rails' way of preparing
theses files for publication using the current state
of knowledge regarding web performance.
By referring to this guide, you will be able to:
keep your assets in the right place
have all your assets compiled and minified for production
What do we mean by 'web performance'? From the viewpoint of one user,
the crucial value is the time it takes from requesting a page (by clicking a link
or button, or typing in an URL) to having the page displayed and interactive in your browser.
We will call this the 'response time'.
From the publishers point of view it might also encompass the question of
how many users you can serve (with acceptable response time) on a given
server. If you look at the question of how to serve more users in case
of more demand you enter the realm of 'scalability'. This is a more advanced
question that goes beyond the scope of this guide.
If you have never studied this subject you might still have
an intuition about where performance problems come from.
Many beginners are fascinated by details of their programming
language like: will using more variables make my program slower?
or is string concatenation faster than string interpolation?.
These 'micro optimizations' are hardly ever necssary with modern
programming languages and computers. Using Rails, Postgres and a modern
hosting service you will have no trouble serving hundreds
of users a day and achieving adequate performance for all of them.
Trying to 'optimize' you code if there is no problem, or
if you don't know where the problem is,
will make your code worse, not better.
"The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil" -- Donald Knuth
Only after you have measured the performance factors that are
relevant to your project, and only after you have found out
which part of the system is causing theses factors to go over
the threshold of acceptable values, only then can you truly
start to 'optimize'.
The "exceptional performance group" at Yahoo published the browser addon
yslow in 2007. It measures performance and displays the timing
of the different HTTP connections as a "waterfall graph":
Each bar is one resource being retrieved via HTTP, the x-axis
is a common timeline for all. The most striking result you can read from
this graph: the backend is only responsible for 5% of the time in this
example! 95% of time is spent loading and parsing javascript and css files
and loading and displaying images!
Yahoo first published 14 rules for web performance in 2007, based
on the measurements back then:
Make Less HTTP Requests
Use a Content Delivery Network
Avoid empty src or href
Add an Expires or a Cache-Control Header
Gzip Components
Put StyleSheets at the Top
Put Scripts at the Bottom
Avoid CSS Expressions...
Make JavaScript and CSS External
Reduce DNS Lookups
Minify JavaScript and CSS
Avoid Redirects
Remove Duplicate Scripts
Even with changing browsers and
protocols some of these are still very valid today.
But as a web developer you should always keep an eye on the changing
landscape of web performance! These rules and their priority will change!
Making less HTTP Requests was a main goal in performance optimization for many years.
Many JavaScript files were combined into one, the same for CSS. Icon Fonts were used
to combine many small image files into one file.
On the other hand the HTTP protocol itself was improved again and again,
to make repeated requests to the same server "cheaper":
HTTP/2 server HTTP requests can be multiplexed over a single TCP connection
The Rails asset pipeline was introduced in Rails 3.1 in the year 2011.
It automates handling static assets:
Compile to CSS (e.g. LESS, SASS)
Minify and combine several CSS files into one
Compile to JavaScript (e.g. typescript, babel)
Minify and combine several JavaScript files into one
Optimize images
Create several versions of pixel images
Create CSS Sprites
There are two main folders:
you put source files in app/assets/*
you configure which files are built and included in app/assets/config/manifest.js, app/assets/stylesheets/application.css and app/assets/javascript/application.js
files for publishing are created in public/assets/*
The second folder will be served by the web server directly, without going through the Rails stack.
The expires header for these files is set to a far future date.
In development the asset pipeline will not write files to public/assets. Instead
these files will be created on the fly, and not be conactenated. The two lines
in your Layout:
When you deploy to production, you deployment process will run rake assets:precompile,
which generates the files in public/assets, including public/assets/manifest-md5hash.json.
If you look at the generated HTML code on the production server,
you will only find two links (plus some code to handle IE 8): in production
the many css files have been concatenated into one application*.css, and
all JavaScript files have been concatenated into one application*.js:
The filenames mentioned in the last chapter all contain a part that seems random:
you named the file slider.css
but it shows up as slider-974d585dcb6f5aec673164664a4e49d5.css
Where do the extra characters come from and what do they mean?
These extra characters are the "fingerprint". It is computed from the full
content of the file. If only one byte changes in the file, the fingerprint will
be different.
This enables a neat trick with the expiry of the file: You can set the expiry time
to infinite, every browser can save the file forever and never try to reload it.
If the contents of the file change, a new file with a new fingerprint in the name will
be generated, and the HTML-page will link to that file.
The asset pipeline handles assets that are
added by developers during development.
Images uploaded by users in production
are handled by activestorage.
