Search
Red Dot Ruby Conference 2016
Speeding Up Your Front-End: 2016 Version
Edit
Summarized using AI

Speeding Up Your Front-End: 2016 Version

Vipul Am • June 24, 2016 • Singapore • Talk

In the video titled "Speeding Up Your Front-End: 2016 Version," speaker Vipul Amler, Director at BigBinary LLC, explores the performance improvements that have been made in Rails 5 and Sprockets 3/4, specifically focusing on enhancing the front-end experience. The talk discusses several key advancements that lead to significantly faster page load times and better developer experience:

  • Sprockets Enhancements: The speaker outlines important updates in Sprockets, especially the introduction of a manifest file that simplifies asset management and pre-compilation by enabling developers to link multiple assets in a cleaner way.
  • Module-Based Asset Inclusion: Amler highlights the new capability of using folders as modules, allowing clearer and more manageable imports of JavaScript files, resolving issues that arise during alphabetical imports that may cause dependency problems.
  • Source Maps: The inclusion of source maps is discussed as a debugging tool, facilitating easier identification of errors in production-like environments during development.
  • ES6 Support: The video emphasizes the addition of Babel support for Sprockets, thus allowing developers to write modern JavaScript (ES6) effortlessly in their applications.
  • Performance Improvements: Amler shares a striking 12x speed increase in the pre-compilation of assets, ultimately streamlining the asset pipeline and bolstering efficiency in application loads.
  • HTTP Header Enhancements: It covers how Rails 5 can leverage HTTP headers for caching strategies, such as ETags and cache-control settings, improving load times and reducing server requests.
  • Caching Techniques: The discussion includes various caching techniques introduced in Rails 5 that enhance performance, such as partial rendering from cache and collection caching—all aimed at minimizing compute time and resource usage.
  • JavaScript Execution Optimization: Finally, Amler presents strategies to optimize JavaScript loading through the use of 'async' and 'defer' attributes, which prevent scripts from blocking HTML parsing.

As a conclusion, Amler stresses the importance of employing these advancements in Rails to achieve noticeably faster web applications and better user experiences while maintaining robust and manageable codebases. The session encourages developers to leverage the latest Rails features for improved performance and efficiency in front-end development.

Speeding Up Your Front-End: 2016 Version
Vipul Am • Singapore • Talk

Date: June 24, 2016
Published: unknown
Announced: unknown

Speaker: Vipul Amler, Director, BigBinary LLC

Rails 5 and Sprockets 3/4, have made amazing strides in terms of performance, and dev-experience. Sprockets adds various resolution fixes to speed it up by more that 12x, allows to use ES6/ES2015, adopts good approaches from npm, and adds experimental features like Subresource Integrity. On Rails too, there are many improvements for speeding up front-end resources- Custom HTTP headers for static assets, Fragment caching improvements, ETag improvements, http_cache_forever and more. In this talk, we will see how to harness many of these to speed up page loads/cache and Google Pagespeed.

Speaker's Bio
Vipul is Director at BigBinary LLC. He is part of Rails Team, and helps triaging issues. His spare time is spent exploring and contributing to many Open Source ruby projects, when not dabbling with React JS. He has recently authored ReactJS by Example, that does a deep walk-through of using ReactJS. Vipul loves Ruby's vibrant community and helps in building PuneRb, is the founder of and runs RubyIndia Community. He also organizes DeccanRubyConf in Pune.

Event Page: http://www.reddotrubyconf.com

Produced by Engineers.SG

Red Dot Ruby Conference 2016

00:00:15.000 all right uh so I have 15 minutes gone in the salary negotiations so I have
00:00:21.519 less time um so I'll just with
00:00:27.760 it this so today be speaking a bit about rails front end um a bit about the
00:00:34.600 aspects in on the front end side of rails and how they have been you know
00:00:39.680 gotten some changes which speed up your ra front end a bit and also speak a bit
00:00:44.719 about sprockets and which changes that have come in uh the newest versions of uh spets uh I'm rle uh I am rle and
00:00:53.320 World on ghub uh Twitter uh I usually try to uh spend most of my time this
00:01:00.320 year trying to contribute to rails when I'm not doing that I work at this company called as B uh where I uh end up
00:01:09.119 working on Rails again uh and a bit on Ro as well uh and during like I'm
00:01:15.479 working over this I also get to move around because we are a remote Force company so I like I try to experience
00:01:22.119 time zones uh like for the last month I've been in Mumbai which is 520 UPC
00:01:30.640 plus I was in thaan which is 8 uh Pacific time I was in San Francisco for
00:01:36.479 a while in the past uh a month and then uh today we are back on 8 so it's like
00:01:44.360 time zones are stupid uh but that's what it is and not just for programming but
00:01:50.520 if you experience that it's pretty huge because you face really bad jet lag um
00:01:57.560 and that's what I'm facing right now now so that's the reason why I'm wearing this today uh this thing I usually don't
00:02:05.560 do that uh and why I'm very this is left so that even if I go to sleep nobody
00:02:10.879 will be saying anything to me uh today I'll be speaking about so everyone has
00:02:16.959 spoken a lot about the stack behind the scenes which is backend I'll be speaking
00:02:23.599 a bit about front and back end like back end uh a bit towards the end as well as
00:02:29.840 that's front end I don't know what this Emoji was how to represent back end so I just flipped it uh I tried to search for
00:02:36.840 it Emoji for front because there was a back so it should be there should be a Emoji I spent some hours actually a day
00:02:44.080 trying to trying to find this uh but I couldn't uh so I thought that hey I should actually try to submit my emoji
00:02:51.319 proposal and I ended up here but I didn't have time so yeah we are this is
00:02:56.360 the front end Emoji uh so today I'll be speaking uh many
00:03:02.920 progressions that have happened in the latest version of rails rails 5 uh one of the things is it has gotten a nice
00:03:09.319 logo and this homepage so yay for the designer who did that uh which was after
00:03:14.519 10 years using the same one uh I most of my references that I'll be speaking
00:03:20.799 today are based on the Block that we run on uh uh on my company which is called
00:03:26.680 as which you can find here we have around 60 plus uh blogy blog entries
00:03:32.480 right now for all the various changes which have come in uh the latest rails version uh so let's begin first thing
00:03:39.720 that I want to touch upon is sprockets um so sprockets is that part of rails
00:03:44.840 which is used for actually serving your resources uh your JS and CSS resources
00:03:50.599 there's a wonderful talk on how sprockets actually works if you want to go deeper into that which was given at
00:03:56.319 the the this this year's realcon by Rafael so you should check that out uh I want to focus on some of the main things
00:04:02.920 which help you out uh which are the new additions right now in sprockets the sprockets come consists of all of these
00:04:08.560 things which is sprockets sprocket rails uh s rails xjs coffee rails which are like peripheral gems which actually
00:04:15.000 comprise of the asset pipeline uh so one useful addition which
00:04:20.239 sprocket has seen is that of manifest. JS so previously in your older versions
00:04:25.280 of rails if you would like to have you know use a different kind of uh asset uh
00:04:30.960 like let's say I have my payments page and on my payments page I want to have different styling and not embed that
00:04:36.960 completely in my application CSS I could I needed to do this this kind of thing wherein my pre-compile needed to have
00:04:43.960 payment CSS advertising CSS Etc and then on my page where I actually need to use
00:04:49.080 that I would use this kind of tag uh rail 5 uh comes now with manifest
00:04:55.680 along with support from sprockets wherein you can just Define this kind of file it is is uh by default generated on
00:05:01.199 ra 5 apps uh and then here you can Define which file you actually want to
00:05:06.560 pre-compile as well so instead of defining that list which is not kind of Handy like you always need to Define
00:05:12.240 that and make sure that it's actually in the pre pre compilation uh so that it actually finds it in production in your
00:05:19.000 apps you can instead do something like link uh and you can actually use this
00:05:24.199 manifest file to Define dependencies on all of these multiple different assets
00:05:29.560 so we will say like link tree and Link all my images so instead of specifying
00:05:34.800 them I will say that hey I need to access these images and when pre-compilation happens they should also
00:05:40.000 go along like uh from this uh in the process of uh assets pipeline I can do
00:05:46.199 link directory and Link uh and so and so forth so here I see here you can see that I am doing link advertising CSS and
00:05:52.919 instead of specifying that in uh my pre-compile and specifying it over here
00:05:58.360 in using link after I do that I can then go ahead and start using that uh in my Erb or also in
00:06:06.479 some other directory uh in in some other asset as well so if I do this uh like
00:06:13.120 rails will like sprockets would automatically pick that up and it will auto like uh send it through the
00:06:19.120 pre-compilation path uh next useful addition which
00:06:25.199 sprockets has got is that as folders as modules uh so if you if you notice over
00:06:30.759 here I have this f/ index.js so this is a kind of a
00:06:36.319 technique which is pretty popular in node based apps uh wherein you have this directory and you specify
00:06:42.080 index.js and instead of having including this this asset like asset path f/
00:06:48.360 index.js instead of this you can directly just use fu. JS and it will go and import the index file so this is
00:06:55.680 pretty useful if you want to Define uh something like this so previously if you
00:07:01.199 wanted to you know import all of your different Assets in your directory what you would do is you would do something
00:07:07.199 like required tree uh required Tree in that particular directory and what will end up happening is it will import all
00:07:13.479 of those uh in an alphabetical way problem with this
00:07:20.599 is problem with this is if you have such kind of a file jQuery ui. JS and min.js
00:07:27.919 problem with this is it will import alphabetically and then this file will
00:07:33.240 be imported pre before uh its dependency and you will not you don't want to have
00:07:38.360 this kind of scenario so instead of this now you can just import index.js and there you can
00:07:44.960 specify the order in which you actually want to import uh a particular file so
00:07:50.639 this is pretty useful uh the next thing which is pretty useful again for debuging debugging purposes is Source
00:07:57.840 Maps so in the previous versions of rails on Rails 4.2 if you try to do this you would see that on a request on your
00:08:05.520 development side you have all of these resources being loaded so individual files uh every single resource that you
00:08:13.039 have it will send a new request for fetching that particular uh resource so like jQuery uh button
00:08:20.000 Etc uh on the latest version R now actually maps that similar to how you
00:08:27.039 have in production so in production you actually have just a single file which is compressed uh and minified so now in
00:08:33.800 uh in the railp apps you'll start seeing something like this which is application
00:08:39.200 debug and what this means is it it is trying to map the same behavior that you actually see in production which is
00:08:45.120 something that you would like to see uh because it uh so that you don't have any surprises when it actually is how it is
00:08:51.200 actually working in production so for so since you have this comprised thing like uh compressed thing
00:08:58.399 that is also being Serv in your uh development version uh whenever you want to debug something it's pretty hard to
00:09:04.760 actually find a particular line you know something goes wrong an error is thrown from a JavaScript you don't know where
00:09:10.880 that particular line is because it's not compressed so to actually find the location of that particular error or
00:09:17.320 something like that you uh we can now start using uh Source Maps so Source
00:09:23.160 maps are actually defined by this mapping this directive that you see over here so let's say I have this file
00:09:28.399 application Js uh sprockets will create this mapping file that you see over here which Ends
00:09:34.480 by just map and this mapping file will then be provided by these directives in the original file for c for JS it is
00:09:41.800 this way and for CSS it'll again provide a different kind of mapping file and this is pretty useful so like uh in your
00:09:49.320 request now you'll see these two files being served but on the on the browser end browser will detect these mapping
00:09:55.399 files and then you will actually you will actually be able to find the mapping of these particular uh so if you
00:10:01.440 want to actually Trace back to some log or some error being thrown you can map that back to the actual sources
00:10:08.839 again uh the next useful thing which uh at least for me which is pretty exciting
00:10:13.959 is beel support for sprockets uh how many of you use or know es6
00:10:21.040 es15 a lot nice so es16 has a lot of
00:10:26.079 these uh amazing things which uh I'm pretty excited about to use have started
00:10:31.240 using uh like The Arrow functions lexical uh binding uh classes and and
00:10:38.240 has object literals and bunch of different things so by default uh now in the latest version uh sprocket ships
00:10:45.440 with uh B support so now you can actually start using es6 uh by es6 uh uh
00:10:52.920 extension uh so this is pretty exciting again uh I wanted to show this by this uh and I tried to search for this but it
00:10:59.600 was like hey uh there are so many different things that you can actually show this for like rainbow unicorn poop
00:11:07.040 as well uh or something like this so internet is pretty awesome if you try to
00:11:12.720 search for it uh the other thing that I want to speak about is this 12x Improvement that
00:11:19.760 sprocket has seen in the uh pre-compilation process of uh asset pipeline so there's this uh nice blog
00:11:28.480 which Richard schne uh which he goes by schnees has written on Heroku so you
00:11:34.320 should check that out which actually provides the whole listing of uh whole process of how this uh speed up has uh
00:11:41.959 occurred so yes's the yes's the actual flow of things that go into the
00:11:47.760 pre-compilation process like you have your raw asset uh you try to you try to actually process that based on which
00:11:54.399 kind of you know SAS or or coffee script and then you try get this Bund bundled together like all of your different
00:12:00.600 files are bundled they are compressed then they are given a fingerprint uh like a digest that you see after a
00:12:07.000 particular asset which is for cash busting and then they are minified and so on so forth uh in the previous
00:12:13.839 versions of in the previous version it had actually had a bug if you see over here this is the function which is used
00:12:20.920 for actually finding the digest so when you pre-compile it tries to you know
00:12:27.240 store that particular asset in your T like asset TMP asset cache if if you
00:12:33.639 have heard of that uh so for actually finding so we ideally you would not like
00:12:38.839 to go through the whole compilation process because it's pretty slow uh to actually getting that asset so instead
00:12:44.199 of that we have these fingerprints and then you use that to find that uh if that resource is already being uh
00:12:50.440 processed and is it if it's either already in the exist in the cach or not and if it does then just return that
00:12:57.399 problem over here if you see the path is being provided over here in the previous versions it used to pick the absolute
00:13:05.040 path the issue with this is uh if you have if you use something like Heroku or
00:13:10.120 if you're using uh like Capistrano in case of Capistrano every deployment will actually create a new
00:13:16.279 directory so if you're using this your cache is always going to find A New Path
00:13:21.639 so it's not going to re uh refer to the original resource so you are actually
00:13:26.760 missing the whole point of uh having accessing the cach versions so this was fixed by uh this fix Again by Richard
00:13:34.560 and he added this uh unload asset which actually uh tries to find the actual
00:13:39.959 paths properly uh when it does the whole compilation for this digest and finding
00:13:45.199 it actually in the cache uh the next thing I want to speak about is Sri which is sub resource
00:13:52.160 Integrity uh so it it has been added as an experimental feature right now it has been present for a while uh so what this
00:13:59.240 allows us to do is we can append Integrity true as an option to our
00:14:04.560 application uh whichever resource that we want and that will create an Integrity hash uh so now why this hash
00:14:12.560 is useful is so let's assume we are have we have a page which has multiple different resources like uh I'm not
00:14:20.040 always going to access a resource which is in my project like I would like to access uh the jQuery or bootstrap which
00:14:27.240 is being accessed from some third party CDN or so and so forth in that case I need to make sure that whatever the the
00:14:34.519 resource which has been provided to me it actually matches the one that I wanted to access and something has not
00:14:40.519 been injected into that particular resource so in that case we have uh use
00:14:45.839 this use of sub resource Integrity which makes that whatever resource we are actually providing actually matches the
00:14:52.519 digest of the original resource which you meant to actually access from a particular domain so you can start using
00:14:59.480 that uh right now all right uh that's all about
00:15:04.959 sprockets uh hope everyone is following me uh the next thing I want to speak
00:15:10.000 about is all about headers in uh your page so this is a typical header or the
00:15:17.480 response that you see when you you know send a request to a page this is coming from uh the Chrome browser it shows what
00:15:25.360 are the response headers like you have you have your e tag date content type Etc so what I want to speak about a bit
00:15:33.240 about is uh these how you can use them uh how you can use or manipulate these
00:15:38.600 headers so that your resources are actually cached on your browser end so one of the uh good uses of these headers
00:15:46.399 is EAC so if you see over here uh there there's a header which is which says e
00:15:52.800 tag and it has some digest and then we also have this last modified over here so using these two headers because uh uh
00:16:01.240 the browser can negotiate with the server that hey whether I have the latest resource on my particular like in
00:16:08.240 my cache or not in the previous versions you could use like uh in the old like uh right now
00:16:14.680 you could use it with fresh when or stale and what essentially this will do is it will first of all find out all the
00:16:21.480 items and then it will generate an e tag for those items and when you send this
00:16:26.920 as a request so if you see over here I'm sending a request to find these fetch these items on the first request it will
00:16:34.079 return 200 as a response on the subsequent request if I pass this eag
00:16:39.839 which was generated over here this eag if I pass this to this request again it
00:16:46.240 knows that hey this was my EAC I'm passing this in in this header if none match it sees that there is some EAC
00:16:53.600 object which is being passed to me and it tries to find that on the server and if it does match then it return returns
00:16:58.759 with 304 modified uh not modified and just use the uh existing resource that
00:17:04.000 you already have in your browser so this is useful so that you don't actually go to your database and try to fetch uh
00:17:09.600 your resources and slow down your request so this speeds up uh uh that part of the thing so rails now uh has
00:17:17.559 support uh Jeremy added support for strong and weak eags uh what this means is uh so these are two kinds of eags
00:17:24.880 that you can actually have in your requests what this means is uh if you have a strong eag uh your request when
00:17:32.559 you send a request it will try to do bite by bite matching so this is useful when you have some kind of a PNG or you
00:17:39.440 know you're streaming a video where you want to see hey this resource which was previously sent to me does it actually
00:17:44.960 match uh to the resource that I uh currently have this is not so true in case of pages you are generated like all
00:17:51.919 the default pages that are generated in real app which are Dynamic and in which case they are not always going to change
00:17:57.919 it's useful to have this kind of weak eack right so in this case it is just going to create a digest of that uh of
00:18:05.559 the resource and it is going to match with the previous digest instead of doing bite by bite matching of the whole
00:18:11.840 uh response so this is pretty useful to you know not go through that render process to find out uh if the resource
00:18:17.799 has changed or not uh another useful helper which has been added uh is HTTP cach forever so
00:18:26.600 let's assume we had this uh home controller over here uh which just serves this welcome
00:18:33.120 tag previously like if you if you always try to access this page what will end up
00:18:38.640 happening is it goes through processing render and all that multiple different things the whole cycle of uh particular
00:18:45.400 uh serving offer like HTML page uh this happens for every s single request
00:18:52.000 instead uh now you can say cash forever uh it comes with the risk but but now
00:18:58.559 you can do something like this HTTP cach forever public true uh and render the response that you want to actually send
00:19:05.480 and if you do this for the first request it it will serve it in this way like processing so and so forth in the next
00:19:11.840 request it will just reply with 304 what is actually happening over here is when you do public uh caching it will
00:19:20.240 set the cash control over the resource so your page will actually be setting this cash control max age 100 years or
00:19:26.960 so so use this with caution what this is useful is let's say you have a page
00:19:32.159 which is really static and it doesn't change a lot and it's never like you it's you know that it's not going to
00:19:37.320 change you can use this so to notify the browser that hey don't always try to
00:19:42.919 compute this resource just use the one that you already have use this with caution because the only way to you know
00:19:49.679 uh undo this or get a fresh resource is doing a hard reset on your browser
00:19:55.200 cache uh the next important thing uh that I found or that is that I found
00:20:01.440 pretty useful was having support for custom asset headers uh so let's assume
00:20:08.000 we have this uh request this is a typical race request wherein uh you have
00:20:13.520 all these headers these are not visible thus but just take my word that there are lots of headers over here uh if you
00:20:19.679 see over here if I want to specify a custom header in my request in my response usually you can easily do that
00:20:26.159 by saying response. headers some header and then try to set some value over here
00:20:31.799 and then this value will be served from the request problem with uh problem with
00:20:37.000 this is you cannot do that easily or previously you could not do that easily in case of your assets your assets only
00:20:44.679 had uh or your Dynamic assets only had this one header which is static cash
00:20:49.840 control and the only thing that you could actually manipulate in this case was this header which will only set the
00:20:55.480 cache control over here this is useful again for caching purposes you will say that hey uh to the browser whether you
00:21:01.960 want to cach it publicly or not and for how much time you want to cach a resource before actually getting the new
00:21:07.960 one uh problem with this is sometimes uh like in case for me what it end up what
00:21:14.679 it uh what it does is it uh some of the browsers do not actually uh just depend
00:21:20.120 on the cache control you would like to have other headers like uh this is
00:21:25.240 something that I got from page speed which is a Google tool for analyz ing your uh how your uh pages are doing so
00:21:32.480 if you see how your uh page speed was warning me that hey expiration was not set for a resource so you actually want
00:21:39.159 it it was saying that for some of the browsers expiration header is also useful along with the cash uh cach
00:21:46.039 control so you I should be setting that but I could not do that easily since we
00:21:51.200 can only specify cache control as I spe as I said so uh this is a new thing that
00:21:57.640 you can now you start using uh on Rails 5 when you can specify public file
00:22:02.720 server and then it actually uses all of these custom headers like cash control you can specify for cash control you can
00:22:09.640 specify for expires or you can uh specify other different uh you know for controlling uh it so and so forth for
00:22:17.000 your uh surrogate cache or CDN and so so and so forth so this is useful if you are actually using something like uh
00:22:23.600 fastly or if you're on Heroku in case of if you have your own server like enginex
00:22:28.880 this will already be been taken care of by on the enginex side uh and now if I after I've added
00:22:36.840 this expires header uh in my uh like in my config uh like the result is that
00:22:43.520 you'll stop seeing that warnings and then you'll actually see start seeing that header which is being set over here
00:22:49.080 uh this was actually done by Yuki so thanks to him for that uh the next thing I want to speak about is
00:22:55.840 caching uh so apart from from these things uh which you can use like headers
00:23:01.039 or eags for specifying uh not to compute the resource you can also use a bunch of different things on the caching end of
00:23:08.679 uh action pack or action uh view uh there are a bunch of different ways you
00:23:13.960 can actually perform caching in rails page caching action caching Etc uh you can find them all on the rails guide
00:23:21.559 today I just want to speak about uh the new additions which have come into the latest uh uh rails release
00:23:28.840 so one uh important like important change which has come in is that of partial rendering from cash so if you
00:23:35.640 see over here uh I have this to-do collection and what I'm doing is I'm
00:23:40.880 rendering that as a partial and here I have this cache which is using this too
00:23:47.200 so when it wants to actually F like render this it will render it for that many number of times and then for every
00:23:53.600 single cash it will try to uh actually first a cash entry Tre for that uh this
00:23:59.480 too that you see over here which is expensive if I have 100 of these it is actually going to send hundreds of
00:24:04.880 requests to fetch uh this cached version of too so instead of this now you can
00:24:10.720 start specifying this cached true uh when you're trying to render the partial
00:24:16.400 uh this was basically influenced a lot from multi fetch fragments a gem now you
00:24:22.360 can start doing this and rails will uh identify that hey I want to actually
00:24:28.200 render a collection and then uh not do these multiple requests to the cache and
00:24:33.399 just use uh read multi to actually fesh all of these entries together in one
00:24:38.640 single request which gives you a lot lot uh lot of boost so you don't have to do that back and forth uh to the cash and
00:24:45.159 this is something that you'll see in the end result in the logs that hey it just fetched it in one single
00:24:51.039 go uh the author of this Library like the original Library which uh actually
00:24:56.720 which which was was from it which was influenced by this uh in in his us usage
00:25:03.240 it actually improves the performance for these kind of scenarios by at least 72% so which is pretty
00:25:09.559 good uh the next thing which is kind of on the peripheral is that of action
00:25:15.240 mailer fragment caching so now you can also use like make use of caching in
00:25:21.919 your mailers uh you can enable this by perform caching through again for Action mailers and and then in your mail
00:25:29.080 fragments what you can in your mailers what you can do is you can start doing this cash do and then it can also if whatever part
00:25:37.240 you have of mail which is you know actually Dynamic you don't need to do that uh you know pre-compute all those values this is pretty useful because uh
00:25:45.520 in your mailers you don't have to end up spending so much amount of time to actually compute all of these things which you know are going to just be know
00:25:52.480 this part of the particular uh mail is actually being going to be dynamic everything else is is going to be seen
00:25:59.440 so you can start using this now uh to use cach in your mails you can see over
00:26:04.679 here how it is uh if after you run this request it says that hey it's going to fetch the cash dig digest for that
00:26:11.360 particular part of your mailer uh one another addition which is
00:26:17.000 kind of useful which goes hand in hand with the fragment caching or collection caching uh is that of support for
00:26:23.440 collection caching on result sets so active record relation now has uh support for cash key so previously uh
00:26:31.200 when we were seeing cash do you have to actually provide so we'll see an example
00:26:36.440 for that so if you notice over here uh I'm trying to find this uh result set
00:26:43.200 where I'm saying I need to find all the users who stay in City Miami the thing
00:26:48.360 with this is if I'm not changing this particular query if no records were added or if no records were deleted this
00:26:55.039 result is always going to be the same if nothing was changed this result is actually going to be the same so I can catch this particular result now there
00:27:02.200 are multiple different ways uh previously you you had to do that manually for yourself like for a result
00:27:07.520 set you you need to derive uh how you're going to specify this cache key uh ra
00:27:13.600 now has the support for cash key on these collections so what it does is behind the scenes it tries to find that
00:27:19.399 based on the updated at timestamp and it has some restrictions but based on that it uh by itself it tries to find this
00:27:26.039 cash key and then you can start using this cach key to actually you know cach users and it will automatically start
00:27:32.480 using that cach key uh instead of you specifying or you trying to generate a cash key for that collection which is
00:27:39.240 again pretty useful uh so that it gives you again this use of uh caching overh
00:27:44.960 hold resource uh collection of resource uh finally I want to speak
00:27:51.440 about layouts and tags uh which is coming towards the end of how your pages
00:27:57.039 should be structured so I want to get uh to first or I want to first get to refer to this
00:28:03.960 async and differ which is kind of attributes that you can specify over your tags so here's just a legend of
00:28:10.679 that I picked it up from uh an example which is here somewhere uh so here the
00:28:16.720 green part is actually parsing uh halted downloading of a script and a script
00:28:23.240 execution so generally when you just have this script tag script tag with
00:28:28.720 application input your uh usual UT what will happen is it will uh your page is
00:28:34.600 passing passing passing it comes to your uh JavaScript include tag then it will
00:28:40.120 halt for a while it will stop rendering your page it will try to go and fetch
00:28:45.880 this since it is a different file it will send another request and for this time it is holding which is not pretty
00:28:52.440 good because for that time of download nothing is happening on your web page after it is downloaded it will then go
00:28:58.760 and actually execute that uh JS which was imported and then it will R you know
00:29:03.919 uh it will uh again start rendering or processing uh the HTML passing but this
00:29:11.320 is not pretty good because uh this affects your page speed if your resource is slow your file is huge this is going
00:29:17.880 to affect how your page is actually rendering other way is that of specifying
00:29:23.559 async if you specify async what will happen is this resource will download so
00:29:29.440 when it sees that hey this tag was async it comes over here instead of stopping
00:29:35.159 the passing it will continue passing it will try to find this parall and then it
00:29:40.600 will stop again the uh the HTML passing and execute that particular uh
00:29:46.000 JavaScript or css resource uh the third thing that we have is
00:29:51.440 defer here what happens is the normal execution will go as it is whenever it
00:29:56.880 finds this uh differ or it finds this JavaScript tag it will go and download
00:30:02.799 it but it will not stop normal HTML passsing it will do that towards the end
00:30:08.480 so based on your uh usage uh how you're actually importing your JavaScript or
00:30:14.159 css this is pretty useful for uh speeding up your page uh actual page
00:30:20.039 paints uh this is useful for your page speed again so there's an ongoing pull
00:30:25.080 request right now to have this by default in rails uh you can follow that over here so this will actually be
00:30:31.640 pretty helpful by default if it's enable in your rail apps uh towards the end I
00:30:37.919 just want to speak a bit about page speed uh so you can use page speed this tool which is provided by Google for
00:30:44.159 finding out different things that you can improve uh and this lets you know about
00:30:49.480 how your placement of JS and CSS Imports are how you should import your fonts analytics how you should actually have
00:30:55.960 your analytics tags and so so and so forth so in a typical application. HTML
00:31:01.679 file you will have bunch of different things so I just want to end with this that uh how you should actually place
00:31:08.559 all of these Stacks based on your execution it will actually slow down or speed up uh your painting of a page if
00:31:16.720 you see over here uh I have my stylesheet tag by default stylesheet and JS F JS tags will be in the head uh in
00:31:24.360 your new apps you should usually try to move the JS towards the end so that the execution is not stopped you can also
00:31:31.000 specify aing and differ again so that execution is not stopped for your HTML
00:31:36.039 passing uh you might also have something like this which is for your loading of
00:31:41.679 external fonts which is something uh I don't like but you need to have in your apps uh so you you you should actually
00:31:48.240 try to move them towards the end or actually try to use open fonts and just embed them in your assets asset
00:31:54.960 pipeline uh Google actually says that you should have this stylesheet towards the end so that it is not blocking again
00:32:02.399 for fetching that file but usually this is pretty useful again because you don't want to have the page like you know all
00:32:09.919 black page and suddenly you have that whole style coming so this is useful so that it appears that your page is
00:32:15.799 actually pretty fast so this style sheet actually should be uh Above So based on your usage you should have your scripts
00:32:23.200 execute towards the end of your page on page load and so and so forth
00:32:28.799 uh and yeah you can combine all of these different things that we have discussed today to actually speed up your page uh
00:32:35.120 which is something I like in the latest release of rails uh that's all I have for today uh thank
VA
Vipul Am
2 talks
Explore all talks recorded at Red Dot Ruby Conference 2016
+17