A web site consist of many more files than just the
HTML documents we have been generating up to now:
css files, image files, font files, javascript 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!
Making less HTTP Requests was a main goal in performance optimization for many years.
Many JavaScript files were "bundled" - 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
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 as a hash from the full
content of the file. If only one byte changes in the file, the fingerprint will
be different.
Let's look at the effect that fingerprinting has on caching:
I create a file slider.css
the asset pipeline publishes it as slider-abc.css (simplified) and an expiry date in the year 2099
rails displays the webpage with a link rel=stylesheet tag that points at slider-abc.css
a browser loads the page for the first time, loads slider-abc.css and keeps this version of the file forever
If the same user comes back to my webpage a year later, the browser will load
the new html page. this will still contain a link rel=stylesheet tag that points at slider-abc.css.
slider-abc.css is still in the browser cache, this will be used. No need to load it.
Another year later I change something in slider.css and deploy the web application again.
Now what happens:
I edit the file slider.css
the asset pipeline publishes it as slider-xyz.css (simplified) and an expiry date in the year 2101
rails displays the webpage with a link rel=stylesheet tag that points at slider-xyz.css
Now if a user comes back to my website, their browser will see a new URL for the style sheet.
The cached style slider-abc.css is ignored, the new file slider-xyz.css will be loaded
and added to the cache.
If you want to use bootstrap for your project it makes
sense to also use sass. This way you can set SASS-Variables
that will be used by bootstrap.
So to prepare your project for using bootstrap install these two gems:
sassc-rails
bootstrap
This will install the bootstrap sass files in your asset pipeline.
You should remove app/assets/stylesheets/application.css and create
application.sass instead.
Now you can use sass to import bootstrap, and to set variables
that influence bootstrap:
The asset pipeline handles assets that are
added by developers during development.
Images uploaded by users in production
are handled by activestorage.
From now on you can add npm packages for the frontend with importmap pin. For example:
$bin/importmap pin unicode-emoji-picker
Pinning "unicode-emoji-picker" to vendor/javascript/unicode-emoji-picker.js via download from https://ga.jspm.io/npm:unicode-emoji-picker@1.3.9/index.js
Pinning "scrollable-component" to vendor/javascript/scrollable-component.js via download from https://ga.jspm.io/npm:scrollable-component@1.2.1/index.js
Pinning "unicode-emoji" to vendor/javascript/unicode-emoji.js via download from https://ga.jspm.io/npm:unicode-emoji@2.5.0/index.js
Here I requested one module, but it came with two dependencies. All three modules
were downloaded do my machine and added to the folder vendor/javascript.
See the file config/importmap.rb for the complete list of pinned imports.
The files from /vendor/javascript are handled like other assets: they
will get a new filename with a fingerprint and in production
they will be copied to public/assets/.
The link tags with rel modulpreload tell the browser to load these files
as soon as possible, so they will be available when an import-statment is encountered.
The entrypoint for you own JavaScript is app/javascript/application.js.
From there you import and call you own modules:
importEmojifrom"src/emoji";// all the code that needs to run after DOMContentLoaded:document.addEventListener('DOMContentLoaded',()=>{Emoji(document);})
Here a module src/emoji.js is imported. This file also needs
to be "pinned". You can do this for all the files in app/javascript/src at once with
pin_all_from'app/javascript/src',under: 'src'
In emoji.js you can import the module "unicode-emoji-picker" by referencing it by it's bare name:
But when you look inside the files, they reference other modules by their
bare names.
Dependencies need to be updated regularly to stay ahead of security problems.
You can do this with importmap:
$bin/importmap outdated
| Package | Current | Latest |
|----------------------|---------|--------|
| unicode-emoji-picker | 1.3.9 | 1.4.0 |
1 outdated package found
$bin/importmap update
Pinning "unicode-emoji-picker" to vendor/javascript/unicode-emoji-picker.js via download from https://ga.jspm.io/npm:unicode-emoji-picker@1.4.0/index.js
With this update the file vendor/javascript/unicode-emoji-picker.js has changed. This
will result in a new fingerprint. Browsers that already have the other javascript
file in cache will only need to load on new file.
(Contrast this to classic "JavaScript bundling" where all files are concatenated into one
giant bundle, and every change leads to reloading the whole bundle.)
