4 ms·

Wycats is a great guy and contributes a ton to the Ruby community, but I have to say...there's really not much here that's new or insightful. Set your headers,

by cscotta 17y ago

Wycats is a great guy and contributes a ton to the Ruby community, but I have to say...there's really not much here that's new or insightful. Set your headers, gzip content, and split assets across domains, yes, but - "Your pages will load faster with Rails"? Somehow the headline doesn't seem appropriate.

wycats 17y ago
Hey @cscotta: This is just the first part of a few posts on this topic. The important part of the post is that Rails handles most of the heavy lifting for you. "Split assets across domains" sounds like it's a snap, but if you already have a large application and want to add it, it can be quite painful. The point is that with Rails, it's literally just a matter of adding a single line in your configuration and all your existing assets URLs will come along for the ride. Same with far future expires. If you just set your headers to the far future, you'll be stuck with outdated content on the client that you can't control. If you use Rails, without doing a single additional thing, your asset URLs come prebaked with cache-busting behavior that operated in the background with no additional work by you.
- brown9-2 17y ago
  The title is misleading though because it makes it sound as if all you need to do to make your pages load faster is switch to Rails. Whether or not Rails makes it easy to implement these suggests or if another framework makes it harder/easier is another discussion.
  - wycats 17y ago
    There are a few cases where it's actually true depending on your host. For instance, if you use a Rails hosting provider, your image_tag, javascript_include_tag, and css_link_tag, you will get the benefit of far-future expires for free. This is not really specific to any particular Rails hosting provider; they all know that since Rails provides the cache-busting infrastructure, they can be aggressive about client-side caching.
  - charlesmarshall 17y ago
    Yes, the title is very misleading. As for the op protesting its because Rails makes its easy to do those things then surely that should be reflected in the name of submission - 'Built in Rails functionality helps page load' I would also say the title is very presumptuous; claiming to make all pages load faster is an unachievable goal & clearly an exaggeration.
    - wycats 17y ago
      Is it? Do you have pages that don't include assets? No JavaScript? No CSS? No images? If so, then I think you're right. Otherwise, built-in Rails functionality will make all your pages faster.
      - charlesmarshall 17y ago
        Yes, it is presumptuous. Do you think that Rails could make every & any website in the world faster? Looking at http://www.alexa.com/topsites http://www.alexa.com/topsites for example, which of those would you think Rails could make faster?
      - brown9-2 17y ago
        The problem with the title "Your Pages Will Load Faster With Rails" is that it implies that Rails alone will make your pages load faster, and/or that Rails alone will make your pages load faster than they already are. All of the speedup suggestions outlined in your article can also be handled easily - easier than Rails or not, I don't know - in other languages and frameworks as well. There is nothing about any of these items that only Rails can handle - heck half of them don't even have anything to do with your choice of server-side frameworks. The main point of your article is "How Rails can make it easy to make your pages load faster".
    - patio11 17y ago
      claiming to make all pages load faster is an unachievable goal & clearly an exaggeration. No, it is not. This is a claim which is testable and measurable, and for reasonable assumptions, you can predictably, measurably, and in a reproducible fashion improve page load times by implementing the YSlow recommendations. If you have the following line of code in application.rhtml: javascript_tag "prototype", "scriptaculous", "shopping-cart", "color-picker", "mysite-functions" and you add these 16 characters , :cache => true then every page on your site now loads faster. P.S. Explanation for non-Rails users: the above code causes the five specified Javascript files to be concatenated into "all.js" the first time any page on the Rails site is rendered, and all pages load all.js rather than loading the five Javascript files. This cuts the overhead of four HTTP request/response cycles from the page. It gives an obvious, measurable impact to page load times, and plays well with another braindead easy optimization "set your HTTP server to gzip outgoing textual content (including Javascript)".
- charlesmarshall 17y ago
  Expiry headers can just as easily be setup in your apache config and I can't think of any modern language that can't access file modification times. A simple config for multiple resource domains is nice; but I'm not a fan of helper functions. javascript_include_tag just isnt as clear as <script src="/location/of/file"></script>
  - wycats 17y ago
    You have to set up the Expires header and modify every asset tag to include a cache-busting query string. Doing this via HTML parsing in Apache is extremely non-performant. Manually adding the mtime query string to every asset reference is possible but tedious and yet another thing to think about while building your app (resulting in a very-close-to-0 use of the technique outside of explicit framework support).
    - charlesmarshall 17y ago
      Yes, both are very tedious, but both possible and done by other frameworks.
      - wycats 17y ago
        The lack of tediousness is the feature. When using Rails, you aren't required to know much about what's going on in order to get the benefits. And that results in an almost universal level of usage.
  - wycats 17y ago
    Also, the reason for using javascript_include_tag instead of <script> is that the actual script tag would look like <script src="http://assetsN.yourapp.com/location/of/concatted_js_files.js?mtimestamp></script&#62 http://assetsN.yourapp.com/location/of/concatted_js_files.js...; There's a lot of additional help that a framework can offer for the client-side if you use its helpers, and that help can be tuned over time as the best practices themselves get refined.
    - 17y ago
mhartl 17y ago
Yehuda already replied, but allow me to summarize: the point is that Rails will do these things automatically, without developers having to think about them. This means that, unless you are doing all the things Rails 3 will give you for free, it's true that "your pages will load faster with Rails"---thus fulfilling the titular promise.

by cscotta 17y ago

wycats 17y ago

Hey @cscotta: This is just the first part of a few posts on this topic. The important part of the post is that Rails handles most of the heavy lifting for you. "Split assets across domains" sounds like it's a snap, but if you already have a large application and want to add it, it can be quite painful. The point is that with Rails, it's literally just a matter of adding a single line in your configuration and all your existing assets URLs will come along for the ride. Same with far future expires. If you just set your headers to the far future, you'll be stuck with outdated content on the client that you can't control. If you use Rails, without doing a single additional thing, your asset URLs come prebaked with cache-busting behavior that operated in the background with no additional work by you.

brown9-2 17y ago
The title is misleading though because it makes it sound as if all you need to do to make your pages load faster is switch to Rails. Whether or not Rails makes it easy to implement these suggests or if another framework makes it harder/easier is another discussion.
- wycats 17y ago
  There are a few cases where it's actually true depending on your host. For instance, if you use a Rails hosting provider, your image_tag, javascript_include_tag, and css_link_tag, you will get the benefit of far-future expires for free. This is not really specific to any particular Rails hosting provider; they all know that since Rails provides the cache-busting infrastructure, they can be aggressive about client-side caching.
- charlesmarshall 17y ago
  Yes, the title is very misleading. As for the op protesting its because Rails makes its easy to do those things then surely that should be reflected in the name of submission - 'Built in Rails functionality helps page load' I would also say the title is very presumptuous; claiming to make all pages load faster is an unachievable goal & clearly an exaggeration.
  - wycats 17y ago
    Is it? Do you have pages that don't include assets? No JavaScript? No CSS? No images? If so, then I think you're right. Otherwise, built-in Rails functionality will make all your pages faster.
    - charlesmarshall 17y ago
      Yes, it is presumptuous. Do you think that Rails could make every & any website in the world faster? Looking at http://www.alexa.com/topsites http://www.alexa.com/topsites for example, which of those would you think Rails could make faster?
    - brown9-2 17y ago
      The problem with the title "Your Pages Will Load Faster With Rails" is that it implies that Rails alone will make your pages load faster, and/or that Rails alone will make your pages load faster than they already are. All of the speedup suggestions outlined in your article can also be handled easily - easier than Rails or not, I don't know - in other languages and frameworks as well. There is nothing about any of these items that only Rails can handle - heck half of them don't even have anything to do with your choice of server-side frameworks. The main point of your article is "How Rails can make it easy to make your pages load faster".
  - patio11 17y ago
    claiming to make all pages load faster is an unachievable goal & clearly an exaggeration. No, it is not. This is a claim which is testable and measurable, and for reasonable assumptions, you can predictably, measurably, and in a reproducible fashion improve page load times by implementing the YSlow recommendations. If you have the following line of code in application.rhtml: javascript_tag "prototype", "scriptaculous", "shopping-cart", "color-picker", "mysite-functions" and you add these 16 characters , :cache => true then every page on your site now loads faster. P.S. Explanation for non-Rails users: the above code causes the five specified Javascript files to be concatenated into "all.js" the first time any page on the Rails site is rendered, and all pages load all.js rather than loading the five Javascript files. This cuts the overhead of four HTTP request/response cycles from the page. It gives an obvious, measurable impact to page load times, and plays well with another braindead easy optimization "set your HTTP server to gzip outgoing textual content (including Javascript)".
charlesmarshall 17y ago
Expiry headers can just as easily be setup in your apache config and I can't think of any modern language that can't access file modification times. A simple config for multiple resource domains is nice; but I'm not a fan of helper functions. javascript_include_tag just isnt as clear as <script src="/location/of/file"></script>
- wycats 17y ago
  You have to set up the Expires header and modify every asset tag to include a cache-busting query string. Doing this via HTML parsing in Apache is extremely non-performant. Manually adding the mtime query string to every asset reference is possible but tedious and yet another thing to think about while building your app (resulting in a very-close-to-0 use of the technique outside of explicit framework support).
  - charlesmarshall 17y ago
    Yes, both are very tedious, but both possible and done by other frameworks.
    - wycats 17y ago
      The lack of tediousness is the feature. When using Rails, you aren't required to know much about what's going on in order to get the benefits. And that results in an almost universal level of usage.
- wycats 17y ago
  Also, the reason for using javascript_include_tag instead of <script> is that the actual script tag would look like <script src="http://assetsN.yourapp.com/location/of/concatted_js_files.js?mtimestamp></script&#62 http://assetsN.yourapp.com/location/of/concatted_js_files.js...; There's a lot of additional help that a framework can offer for the client-side if you use its helpers, and that help can be tuned over time as the best practices themselves get refined.
  - 17y ago

mhartl 17y ago

Yehuda already replied, but allow me to summarize: the point is that Rails will do these things automatically, without developers having to think about them. This means that, unless you are doing all the things Rails 3 will give you for free, it's true that "your pages will load faster with Rails"---thus fulfilling the titular promise.