Web-development – MPA vs SPA for first-load performance & meta tags

optimizationseoweb-applicationsweb-developmentwebsites

Let there be a static web application.

Let the following be a priority:

  1. First loading time (ignore cache etc)
  2. User experience
  3. Search Engine Optimization (meta tags & bot friendliness)

When writing a web application, there are two broad approaches:

  1. Single Page Application (AngularJS, Vue.JS, React, …)
    • Benefits:
      • Load once, highly responsive UX
      • Less bandwidth usage
    • Drawbacks:
      • Relies on JavaScript (not friendly to bots that don't run JS)
      • Long initial load (may be render blocking)
  2. Multi Page Application (Traditional)
    • Benefits:
      • Friendly to bots
      • Lightweight (load only what you need for each page)
    • Drawbacks:
      • Loading when switching pages (hits UX)

A single page application can be made friendly to robots using server side pre-rendering, but that would mean the application is no longer static and would incur an operations (hosting) cost.

Given the priorities and possible options, which approach would be optimal?

Best Answer

If you use React, Vue or Angular(1.5+) and ES201(X) its very simple.

You make a separate module for each section in your application (e.g. user, order, products, etc...), than you make a root-entry-point (e.g. app.js) and a bootstrap.js where you do your complete bootstrapping process without dependencies of app.js.

if you use webpack+babel you can choose if you wanna have one entry point or multiple.

than you put on each index.js of module an if statement for e.g. 

if(document.querySelector('#my-module-root').length) {
// ... import & load bootstrap
// ... render module 
}

so you can choose at the last step if you wanna make a complete spa solution (import all modules to app.js) or an mpa solution (load & bootstrap each module separate) by requesting a page from server and rendering each module separate.

there is no better one, it depends mostly on the size and resources of your application. e.g. your application has 10 modules with each 150 submodule with each 20 components, than the final spa file is very big, for sure you can chunk (separate in parts) the file but the user have to load your complete application.

if your application is slim you can do it as spa.

for bot´s and better ux (user experience) it´s better to render the javascript-application on the server (SSR = server - side - rendering). the user and the bot has a very very small longer loading (depends on the nodejs engine to render and the caching process in background) at the beginning and than the user and the bot see an consumable result, a few seconds later the client-side-js is loaded and the whole functionality is available. BUT(!!) There are many many small hints to build a SSR-MPA/SPA some parts working a lil different. if you dont familiar with SSR you better choose CSR (client-side-rendering)... It´s also possible with both variants (MPA/SPA).

i prefer the mpa solution, cause the most web-apps has module based resources like translations, privileges, etc... e.g. you have 2k descriptions in you translation and 500 privileges for the user, on an mpa you have to load the resources just for the module instead of the whole application.

an traditional mpa (no client side application, angular, vue, react...) is mostly a lil simpler to maintain, cause your complete business logic is at the server. BUT(!) the ux is less than an mpa/spa with client application and your browser have to render the complete ui for each single request/call/command...

EDIT: i forget a very important thing about SSR, if you have a lot (500+) users at the same time on your application, you have in mind SSR means your server make the same work as the client. the server renders 500 applications at the same time. this is not impossible with good caching strategy and outsourcing the rendering to a different server in your prv-network. But mostly you have other problems with scaling by 500+ users at the same time and you can scale/outsource this part later when you application grows and needs more resources...

sorry for my bad english ... :D

Related Topic