Magento 2 PWA is not React/Vue headless SPA(single page application)

5 min readMay 21, 2020

For some reason, a lot of people think Magento 2/1 headless Progressive Web Applications (PWA) should be single-page applications (SPA) and use modern JS frameworks like ReactJs or VueJS, AngularJS

Magento PWA does not necessarily have to be a headless implementation or SPA.

I recommend don’t use SAP for Magento sites targeting search (SEO) traffic and for usual simple online stores.

Requirements to be a single page application are not the same requirements to be a progressive web app. This means you can make a SPA, but it is not a PWA.

Why Magento Progressive Web Apps are not headless Single Page Apps

Progressive Web Applications are websites that meet three technical requirements:

HTTPS (Secure)
Valid Web Manifest File
Register a Service Worker with a Fetch Event Handler and Minimal Offline Support

You can check your website and easily build PWA support using this project: https://www.pwabuilder.com It quickly and easily turns your website into an app!

Nowhere in those requirements does it say the PWA should require JS SAP APP

There is also nothing in those requirements saying the website must use JavaScript. You must just register the service worker using client-side JavaScript

Your site’s service worker is written using JavaScript, but it executes in a different process so it does not count against your front-end user experience. SpeakingThere are some user experience expectations progressive web applications have, such as speed

Magento PWA Studio, VueStorefront is single-page applications by nature.

To utilize the full potential of PWA, the site should be rebuilt from scratch. This can be quite expensive. (3–6 months of work) However, it is also possible to integrate only the necessary PWA features to the existing Magento legacy theme.

eCommerces can concentrate on the features that will create maximum impact, and implement it. This will also increase customer experience considerably. Some businesses that use selected features of PWA:

AirBerlin

AirBerlin utilized the offline functionality of PWA to offer reliable offline support to its customers at airports. This allowed their passengers to access boarding pass and journey details without internet connectivity.

Why Progressive Web Apps Kill headless Magento Single Page Apps

A properly designed progressive web application pre-caches many site assets: scripts, CSS, images, and markup before they are required. This eliminates the network from the rendering process and enables the application to work offline.

A PWA can still use the app shell model, but now instead of the core markup being rendering in the UI thread it can be prefetched in the service worker or dynamically rendered in the service worker.

The key to this process is the service worker runs in a separate thread from the UI. This means the browser tab is not locked up while the JavaScript is executed to render the content.

This means you can completely remove the excessive JavaScript overhead single page application JavaScript frameworks add to your webs apps. Instead, you can move that logic to the service worker.

Magento Hybrid Progressive Web Application Website Model

It’s simple, a website that uses the best the web has to offer to deliver great user experiences.

Almost all websites have a core common set of expectations.

Load Fast
Smooth Animations
Responsive, Mobile First Design
Some Dynamic Rendering Capabilities

BEST Magento PWA is a static website.

That’s right, the original type of website, static and simple.

Avoid single page applications today. Instead, use service workers to implement much of what single-page applications were designed to do. But instead of clogging the UI thread with excessive JavaScript code execution, you can offload client-side rendering tasks to the service worker.

Also, evaluate what pages in your site are candidates for service worker rendering. Not every page needs client-side rendering. You can use service worker caching to avoid the network request for many pages as well as needing heavy JavaScript payloads.

For libraries like React, you should be concerned by the cost of booting up the library on mobile as this can catch folks out. In React, site accomplished interactivity in under 1700ms by keeping the size and execution cost of the overall app relatively small despite having multiple views: 11KB gzipped for our app bundle and 107KB for our vendor/React/libraries bundle which looks a little like this in practice:

Javascript has to be downloaded, compiled, parsed and executed first before any rendering can happen. This makes SPA/PWA slower than old school SSR when it comes to initial perceived performance, not a lot of people will tell you this.

Technical overview of the client-side JS

Why Static ReactJS Magento with Server Side Rendering

The Fastest Website is Static Website.

React is traditionally used for building client-side applications, which are burdened by an upfront performance cost. Many Magento websites do not require a single-page app experience, it is irresponsible to make a user-pay this UX penalty.

React has recently introduced server-side rendering (SSR) as a great solution to this problem, however, this can require a simple NodeJS server architecture, which may not be appropriate for websites with more basic needs.

We can achieve the same result of sending pre-rendered markup to the browser with a technique called static rendering (also known as snapshot rendering). This is where the pages are rendered into HTML by a full-page cache (FPC) — cached static HTML files. This gives us a performance boost without complicated server maintenance.

Static sites are better for Google indexing and can mitigate security threats by way of not having a database behind the page rendering.

Regular React Web sites loads like this. If we open the dev tools of the browser and select the “Network” tab, we can record a timeline of the page render. Since it is important to optimize for ‘mobile-first’, we will select “Fast 3G” from the network speed presets, then record the page load.

The above screenshot shows that nothing renders until 1.50s, with the complete render clocking in at 2.09s. This test sample website has a bare minimum of content, so it is taking 2 seconds to render hardly anything. We can improve this with static rendering.