I've been working on the content/slides for my presentation (Front End Performance) in a week and I've been thinking about various trade offs for various situations. One of the more interesting ones has to do with a very popular page where 99% of visitors bounce off; aka the Slashdot effect. When something like this happens, the less open connections to your server the better. Browser caching of the pages resources is pointless because 99% of the visitors will not visit another page. If you don't have a CDN, using inline CSS and JS and data urls in image tags might actually be a good idea.
Questions:
- Given the above situation (slashdot effect with no CDN), would inlining almost all content make sense?
- Has anyone built a module that does this? If not, it could be built using AdvAgg for the JS/CSS parts and Imageinfo Cache uses the right hooks that could be used to make use of data urls in img tags (interception of calls made to theme_imagecache(), theme_imagefield_image()).
- Could this improve mobile browsing?
Comments
Inlining some content would
Inlining some content would make sense. But even if all your content is on one domain, the A and B grade browsers can still open 6 connections per domain. So you want to make the full use of all 6 connections for the full duration of the time that it takes to download the content. But it is possible to go too far with the inlining where you have 5 connections only in use for a short time, and a single connection in use for the majority of the time.
You also need to take into consideration the cost of inlining - if you inline two dozen CSS images it now takes longer to download that CSS file. How does that impact the render time? It might make things slower. It might be very difficult to set this up in a manner that is generalizable for all (most) sites. Each site may need to pick and choose what to inline.
But I'm finding that for A-grade browsers even if two domains point to the same IP address it will treat them as separate hosts and open 6 connections for each. So it may be beneficial for you to simply set up www2.example.com that points to the same docroot and use CDN module to pull some resources from that domain. This way you can decrease keep-alive limits in your webserver and free up connections faster.
--
Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his
Well, catch has made a
Well, catch has made a project called agrcache. From the looks of it, it doesn't seem to be quite what you are looking for.
Android 2.3 supports 7 connections, while the most widely used browsers use 6 like dalin mentioned. Apparently, Iphone 4 supports 4, and blackberry supports 5. Some quick research leads me to believe that figuring out the max range of a file's size would yield useful info. You have the files useful for rendering the page to the user (for the appearance of speed), and then obviously load various other css or js files. Labjs (from the previous link), sounds interesting.
Taking a cue from responsive web design, perhaps going for something along the lines of "responsive caching design" is a design concept to consider.
You can inline header pictures within the main css, and perhaps a second css for footer pictures, and the amount of css files with pictures would depend on what's considered too large of a css + js file for the source origin info that you're dealing with (ip, user-agent, etc.). To prepare for that, getting some rough estimates of connection speeds and max connections should help you figure out how to make the logic that's necessary. For high speed, non-mobile connections, inlining everything seems ideal for the aggregate throughput of the server, and for everyone else, it's a matter of figuring out how many files to serve, and determining what kind they are.
I wouldn't mind fast loading for the header css files (the logo, menu portion, and info/ad section), and if everything else fades in or appears like a nice splash page.
Not related at all, but is it possible for a user to have a page loaded where they have to scroll up? Just curious. :)
With respect to Mobile - make
With respect to Mobile - make sure you check http://www.youtube.com/user/LinkedInTechTalks#p/u/0/5ENYA_RCCjM - this has a great assessment of weighing up the pros and cons of inlined resources, and using appcache or other approaches at the same time.
Slides
http://www.slideshare.net/souders/high-performance-mobile-sfsv-web-perf
Did you ever do any testing
Did you ever do any testing for this type of situation and setup? Maybe use something like Charles Proxy to simulate a couple different connection speeds and see if there is a performance improvement.
Also, how do you identify a page is being slashdotted? Is that a manual step or is detection automated?
just an idea
This post is just an idea; I don't know of anyone who has done this. But it does seem possible. After your presentation the guy who used to work at AOL also mentioned doing something like this as well for mobile; seems like it has a chance of being faster, bandwidth is no longer as big of an issue as it used to be; round trip time seems to be the biggest pain point.
One of my idea posts that did turn into reality is this one http://groups.drupal.org/node/53973. We needed it badly at work, thus it got green lighted.
Just wait for a
decent spdy implementation in a modern server. That will take care of many of the issues regarding round trips and also will allow to simplify the setup by avoiding the domain sharding route.
It's coming on Nginx 2.x. To arrive in a few weeks (I hope).
That only works with
SPDY only works with Chrome/Chromium so far, I believe (it is available with Firefox 11, but off by default), so I am not sure it will help that much in practice. It is cool stuff though.
In general though, I don't think there is really a huge problem to be solved here - we have handled prime time Slashdot/Digg-frontpages to mainly static sites with nothing but the Drupal page cache (on a shared server, no less) - adding Boost or Varnish would do even better. Adapting the front page assets to high-bounce-rate traffic is an interesting idea, but my feeling is that if frontend performance is important to you and you are already following best practices (e.g. using advagg and image sprites etc) you should already have a small <6 or <12 perhaps) number of http requests (so 1 or 2 roundtrips) and hence there is not that much to be gained by getting down to exactly 1(sih) http request. As others mentioned above, the reduced parallelization is probably slower in reality.
Aree there any special
Aree there any special handling of drupal in code to support Google SPDY protocol ?