When a social networking container imposes strict security measures on the content being loaded to it, applications with large amounts of content tend to load much slower and might time out if the container expects all the application content to load within a specific time. This problem can be compounded if the application being built loads its content from a single server request, which in turn performs an extensive amount of processing before returning the complete application markup. Processing an entire application from a single request can certainly reduce the number of HTTP requests that are being made from the application and can help with performance. So, for many smaller applications, this may make sense. But in the case of applications with heavy content loads, this approach can be detrimental to the point that it sometimes prevents the application from loading within the container at all.

Using a deferred loading approach can easily mitigate this issue. Since most containers load applications on a page only after the container and page content have finished loading, there is usually precious little time for an application to capture the user’s attention. An application that stays in a loading state for eight seconds while all of its markup loads will usually miss this window, as the user moves on to doing other tasks within his profile.

If you load the most important content of the application within the first HTTP request, returning data such as core user customizations or pertinent application information like scores or statuses, you can grab the user’s attention. Once you have that attention, the application can continue to make HTTP requests to the server to gather additional, less important content, loading once that’s completed.

By using this technique to engage with users as soon as possible, you can increase the number of daily active users.