Lightning Fast Websites

Blazing Fast Websites by Lazy Loading Content with AJAX

This is somewhat continuation of an Angular.JS templates related article.

I am not so keen of keeping two codebases for the same purpose, but I am experimenting with a new approach, where server renders the simple document using the same data, including the web-app script and serves the same data in AJAX requests of the provided web-app.

Typical example would any big newspaper website with tons of articles. But as most of the readers, you followed the link to an article from some feed, or search results page. But instead of loading just the article you are interested in the first-place, the whole navigation tree, related articles, side-bars, comments, fonts, CSS needs to be loaded to use the web page. It’s insane bloat from the I-just-want-to-read-the-article perspective.

How about this:

  1. Render just the requested document (article) without the unrelated stuff (like sidebars, related articles, comments, etc.)
  2. Inject the web-app using javascript at the end of the article
  3. Load data, templates, CSS using AJAX and build the full-site lazily on the client

It’s not so hard to render readable representation of the article on the server. Just let go the urge to serve fancy website on the server. Let the client do the heavy lifting.

The server-side code base for the webpage would be so simple you might not need to maintain it at all. All the focus would go to the web-app website version itself.

Rendered parts of webpage could be only the:

  • resource requested
  • navigation
  • breadcrumbs

The web-app, the interactivity gets (maybe) loaded later depending on browser features/capabilities, speed of network, [name your own conditions].

Considerations:

  1. Rendering just the core data, just the resource, is easy. Rendering such document could be template-less, or could use only the native PHP templating title?>, which is sufficient to render data.
  2. It goes well with the mobile-first approach.
  3. Simplified content serves well not-so-smart phones and all search-engines (not only those able to index JavaScript apps). This should be future-proof.
  4. Less HTML means less CSS, means there’s no need for hacking CSS. There’s even less CSS needed to render such simplified document. Authoring and maintaining such CSS should be easier than creating above-the-fold CSS.
  5. Errors happen: something gets displayed even when the JavaScript got stuck due to error.
  6. No-JavaScript alternative: can provide no-JavaScript compatibility since it still can serve other than GET requests dynamic. (Caching can be handled by Varnish or other dedicated solutions.)
  7. Most of the extras (web-app, “under-the-fold CSS”, etc.) can be lazy-loaded later which leads to faster page load/render times, the Angular.JS could be lazy-loaded too.
  8. Using the “no-js” conditional class the simplified content can be hidden/changed/re-styled after loading the web-app.
  9. Helps to pass the page-weight under 14kb of compressed code.

From the point where the web-app is loaded, the content can be loaded using AJAX in lighter form than HTML, without reloading the frame.

Let me know what do you think.

  • Christopher Thomas

    ok, I’m coming from this page: http://www.martinadamko.sk/posts/114

    I understand the technique, basically you’re static html contains a skeleton with gaps that you can on demand fill with content you’re loading dynamically as you navigate around the website.

    whilst I think you’re “header animation” example is a little simplistic, because you’d have problems with fully fledged websites which required showing those content items when the page loads too, you didn’t really solve the problem of how to compose a page statically for search engines AND angularjs at the same time.

    I also like this approach and I’ve got an idea to create something similar, but one which also flexed the layout and downloaded content when the media queries demand it, meaning you don’t download content which your device will never see.

    However, I don’t see it as a solution to the previous article you spoke to me about, I just see it as another problem and another solution.

  • I do see your point. I think the problem I’ve described in previous article maybe should not be solved at all in first place.

    Here’s the thing: If we don’t force server to render all the (mostly unnecessary/secondary/related) stuff we could focus on the front-end, which in turn means to focus more on users. That means more time, care and happy users, which means better user experience and more happy clients.

    However, the necessity to let go the idea that the server-side should generate full representation of website, is still scary. I’m just embracing the idea that HTML response can be stripped to the bare minimum without consequences. (Is it possible?) The Angular compatibility would be, from that perspective, an overhead (a little) and unnecessary in the light of this approach.

    I know my example is a rather simple website, but I’ve created it with newspaper-size websites (with ton of content) in mind. And I think it’s doable.

    We’re on the same side here – the media query is a part of my proposal: to load extra bits depending on the abilities/conditions of the browser. First call for HTML page would result in response with the main content down the wire only. The app frame could be loaded later by the web-app itself.

    Everybody, it’s creators (developing websites faster) and it’s users (faster websites down the wire) could benefit a lot from it.

  • Christopher Thomas

    the reason for rendering on the server isn’t about users, it’s about search engines, you need to provide them with a searchable page otherwise your users are happy, but google can’t index your website.

  • Right, SEO is important. I’m proposing to render the article, navigation and that’s it. Google would consume the article and crawl the site following the provided navigation.

    That’s pretty easy task. No need for special templating engine compatible with Angular.JS and PHP.

    By injecting the JavaScript app to render those fancy stuff for users you mostly don’t need to index anyway would render the fancy website.

    If you need to index related data (like article comments) provide onother unique resource to crawl, e.g. under `/article-name/comments`. That’s also approach compatible with REST APIs.

    Load related articles, comments, sidebars, other navigation, [put other not-the-article-I-asked-for stuff here] later should not harm your rankings.

  • Christopher Thomas

    ah I see, this will require two rendering strategies then and I can’t see this working for complex websites, as the more complex it gets, the harder each rendering strategy becomes and then you effectively are building and maintaining two websites, imagine a website which complex SEO and lots of dynamic content depending on the URL, I think your example would be ok for simpler sites, but anything like a shop etc would probably not work so well.

    rendering both systems with angular would allow you to solve the problem with a single rendering strategy and accomplish both, I think it’s more useful to invest in making an automated system which can render on the server and browser dynamically and automatically, than doing the above, proposed plan which has only a limited set of functionalities before the complexity starts to kill the idea.

  • I see your concerns, I have them too. This is an early stage idea and I really appreciate your inputs on the subject. I’ll keep an eye on them.

    If I ever get as close to the case complex as you described, I’ll let you know how it went.

    Thanks.