Why so much Javascript-loaded content?

August 1, 2012 5:51 AM

Why is the page content loaded by Javascript?

I've noticed more and more websites are forgoing loading content into the main web page request, instead delivering a partial page and then using Javascript to load the main content. For example, all the sites on the Gawker network I've seen use this approach.

I can think of a couple of reasons why they might do this (minimise content-scraping, use of a CDN), but what other reasons might there be?

posted by urbanwhaleshark to Computers & Internet (14 answers total)

Its often easier to make pages act and look a certain way if you load them with Javascript.
posted by pyro979 at 5:56 AM on August 1, 2012

Google once came out with a study (that I can't find) that said that for every extra 10ms of page load time a significant number of users didn't use their products. So now some people are trying to get better page load times. One way is to load a lightweight page and then load the rest with javascript.
posted by Phredward at 6:10 AM on August 1, 2012

Its often easier to make pages act and look a certain way if you load them with Javascript.

This is especially true given the number of mobile devices with different screen sizes and different capabilities. I imagine a lot of that Javascript is to tailor the content for specific platforms.
posted by RonButNotStupid at 6:19 AM on August 1, 2012

There's also the fact that it makes the site navigation usable straight away.
posted by Nick Jordan at 6:34 AM on August 1, 2012

These were the reasons behind the Gawker Redesign of 2011 in which they moved to javascript page loads. It doesn't directly explain the technical reasons for that choice, but it might give you an idea of what the larger aims were.
posted by xchmp at 7:33 AM on August 1, 2012

It also forces viewers to turn off their javascript blocking, which means that advertising delivery is less likely to be blocked.
posted by Chocolate Pickle at 7:53 AM on August 1, 2012

There are a bunch of javascript libraries (e.g. jquery et al) that give web designers a huge boost in functionality for little or no effort other than learning how to use these toolsets.

There are a bunch of excesses imo. What gawker does is pathetic. i.e. display nothing if javascript is not enabled. Worst crime imo are the dullards who use the googleapis - google toadies - all of them. Host your own fricking libraries!
posted by w.fugawe at 7:57 AM on August 1, 2012

For larger sites, it also decouples different parts of your architecture. For example, a Facebook page consists of many smaller applications with their own load times:

Friend feed: 100ms
Notifications: 50ms
Personalized ads: 40ms

If you load the entire page at once, you can only respond when every one of the services has finished loading. In other words, your page load becomes max(100, 40, 50) = 100ms.

Now imagine if your servers are getting hammered and Personalized ads slows down:

Friend feed: 100ms
Notifications: 50ms
Personalized ads: 400ms

If you generate the page on the server, your site takes 400ms to load! That sucks! Many users don't even care about the ads— why should they have to wait for it?
posted by yaymukund at 8:09 AM on August 1, 2012

For contrast: Twitter recently switched back to more static server side rendering, less JavaScript. Here's why. Performance, mostly.
posted by Nelson at 8:09 AM on August 1, 2012

All technical considerations aside, and I'm sure there are some, I've figured it's a way to force people to view advertising and allow scripts to run in their browsers.
posted by OmieWise at 8:10 AM on August 1, 2012

Some sites use javascript to do automatic updates of content without reloading the entire page, perhaps it's simpler to use that method on first load as well.
posted by purplemonkeydishwasher at 8:29 AM on August 1, 2012

Worst crime imo are the dullards who use the googleapis - google toadies - all of them. Host your own fricking libraries! - w.fugawe

Delete this if it's too much of a derail, but I think this is bad general advice, though of course it depends on the individual use case. Users often have the googleapi version of jquery, for example, cached, reducing the load time. Even if not, Google have a worldwide CDN network, so jQuery will likely download much faster from Google's servers than your own one. Additionally, you're handing off some part of the load to a different connection to your main site. This allows jQuery to be downloaded in a synchronous request, speeding up the overall page load time again.
posted by Magnakai at 9:41 AM on August 1, 2012

It's all about client side templating these days... it means we can deliver the bulk of the HTML content from a CDN instead of our central server, which ensures much quicker delivery to our end users.
posted by ph00dz at 10:13 AM on August 1, 2012

• The user's computer represents a resource onto which I can unload processes that would otherwise occur on my server (as a developer, I don't want things to happen on my server unless they absolutely have to). One of these is rendering or altering views in response to input.
• The user would rather things happen in real-rime. If you click a button to change the view state, you don't necessarily want to wait while the application state gets bottled up and sent to the server and the new view renders and gets sent back. JavaScript can store application state in memory, load (and cache) those parts of the view that it needs and render them instantaneously.
• Separating a web application into a view (JS/HTML) tier and a service tier makes building, maintaining and expanding web applications easy. Plus, it makes it possible to serve multiple clients (browsers, phones, tablets, desktop apps, mobile apps) using the same services (without a bunch of unreliable client-detection decisions on the server).

Google maps vs. the old MapQuest is a good example for the first 2 points.

Ufile.ca is an excellent example for the latter two. It was a very early adopter of the "fat client" style of application design.
posted by klanawa at 3:05 PM on August 1, 2012