Skip to content

Progressive Web Apps: Architecture and Examples

Shortcut to Cloudinary’s solution

As lightweight versions of native apps, progressive web apps (PWAs) offer a reliable, instantly installable version of traditional apps. This post explains the inner workings of PWAs, describes the best practices for developing PWAs, and clues you in to Cloudinary’s superior capabilities for optimizing rich media for faster load times as part of app content.

Here are the topics:

Progressive web apps (PWAs) are web applications that mimic the experience of native apps and must be:

  • Capable: PWAs often include such features as keyboard shortcuts, file-system access, app badging, media controls, and clipboard support, all created through modern web APIs and WebAssembly. With the aid of HTML, CSS, and JavaScript, PWAs can leverage web technologies to run on multiple platforms and devices from a single codebase. They offer capabilities similar to native apps such as operating offline, accessing hardware features like the camera, microphone, and GPS, and utilizing push notifications, making them a powerful tool for modern web development.
  • Reliable: PWAs remain usable regardless of the quality of network connections. The recent content is always available and, if access requests fail, PWAs alert users and tell them why. Also, PWAs support offline access.
  • Installable: PWAs run in a standalone window, not a browser tab, hence launchable like native apps. You can specify PWAs as defaults just as you do with native apps.
    Important:

    In March 2020, Apple announced that its Safari browser engine, WebKit, will delete local storage of cookies after seven days. Consequently, unless you access a PWA’s site within seven days, that app will not run on your Apple device.

    Even though that change by no means rings a death knell for PWAs, you must adjust how you develop PWAs in the future. Also, since Google collaborated with Apple in hammering out that policy, other devices might soon adopt it as well.

    While creating a PWA, you can choose from two architecture styles, server-side rendering (SSR) and client-side rendering (CSR), to define the way in which to load pages and the amount of communication between a user client and your server required for your PWA to work.

    When a user client requests your web app, SSR renders dynamic content on your web server and then delivers the prerendered page.

    Here are the benefits of SSR:

    • Fast initial renders for users
    • Mature architecture with well-established tooling
    • Support of all browsers regardless of the JavaScript feature

    Two downsides exist, however:

    • You must generate a new document object model (DOM) for each user navigation.
    • Rerendering is slow due to the round-trip request to your web server.

    The same user request with a CSR architecture returns a default page in which dynamic content is rendered after delivery through manipulation of the DOM with JavaScript.

    Here are the benefits of CSR:

    • CSR offloads page updates to client resources.
    • Given that requests need not be sent to the server, rerendering is faster.
    • Rather than rerendering the entire page, CSR can rerender only portions of it, as necessary.

    Note the downsides:

    • CSR relies on user clients to support JavaScript methods.
    • Client resources might slow down rendering.

    In general, choose SSR for those PWAs in which users primarily navigate and view static content, e.g., news or scheduling apps. CSR is preferable for dynamic sites whose content changes according to user behavior or real-time content, e.g., social media or shopping apps.

    In practice, however, many apps combine those two styles to optimize performance and user experience. Since all web apps require an initial user request of your page, it makes sense to adopt SSR to ensure that the first rendering is complete before delivery. The result is a caching of all components of your app into a shell for user access. Then, as new data is sent by the server, you can dynamically render individual elements through the cached elements, as warranted, with CSR.

    You build PWAs with APIs that offer native-like characteristics. PWAs are intended to work anywhere from a single codebase by being installable. A fundamental part of making PWAs installable and functional is the inclusion of a web app manifest and a service worker. The web app manifest provides information about the app (such as its name, author, icon, and description) in a JSON text file, enabling user agents to provide a richer user experience. The service worker, on the other hand, is a script that the browser runs in the background, separate from the web page, enabling features like offline support, push notifications, and background sync. These components, along with the web application itself, form the core structure of a PWA, ensuring it delivers a robust, app-like experience on the web.

    To be installable, PWAs must meet the expectations chronicled in the Google-authored Progressive Web App Checklist, which contains the following items:

    • Performance: PWAs must start fast, run fast, and prioritize user-centric metrics.
    • Browser compatibility: PWAs must work in all browsers, which vary according to the device in use. You can ensure browser compatibility by leveraging the feature-detection capability, with which you can account for browser features upon their release.
    • Responsiveness: PWAs must be responsive web apps and equally functional on screens of any size. Be sure that your content adapts comfortably to changes in screen and viewport size.
    • Offline functionality: PWAs must retain as much functionality as possible when offline. For example, user-specific content for boarding passes, calendar events, and the like must be available even without a network connection.
    • Variable input: Users must be able to access PWAs from any input device. Whether it’s keyboards, mouse devices, styluses, or touch screens, PWAs must offer similar functionality. Do not restrict input options according to screen size or device. However, PWAs might accord enhanced functionality for certain input methods.

    Although not common knowledge among users, many companies are already running PWAs for their sites. Below are a few popular ones.

    Previous efforts by the renowned e-retailer AliExpress to convert mobile users into app users didn’t work as well as hoped, probably partly due to the poor adaption from website to mobile site. To rectify that issue, AliExpress revamped its mobile site into a PWA. Soon afterwards, significant improvement in user engagement emerged, including a 104-percent increase in user conversions and a 74-percent jump in session length.

    Although most people are familiar with the standard Twitter app, not everyone is aware that the company has also created a Twitter Lite version. That’s an installable PWA aimed at improving the experience of mobile users, many of whom rely on weak or inconsistent network connections.

    Twitter Lite delivers a mobile experience with optimized images and cached data for instant page loads with lower data requirements. Additionally, users can receive push notifications and add the PWA to their device’s home screen, just like the full app. So far, Twitter Lite has delivered impressive gains, including a 65-percent rise in the number of pages accessed per session and a 75-percent surge in sent tweets.

    A top business magazine, Forbes publishes content on numerous marketing, finance, and investment topics, offering print, website, and mobile versions. Recently, the publication company added an option for a PWA geared for enhancing the experience of mobile users.

    Once released, the PWA garnered significant adoption with impressive gains in the number of sessions per user (43 percent), the number of articles read to completion (six times), and the engagement rate (100 percent).

    To ensure that your PWA is well received and to avoid the inclusion of unnecessary or undesirable features, adopt the best practices below during the development process.

    Keep things simple.

    PWAs are not intended to replace standalone apps so do not design them to do that. Instead, your goal is to condense and enhance mobile experiences with select features, such as push notifications, widgets, and offline availability. Focus on building those core features and don’t pack too much into your app.

    Multi-platform development.

    With PWAs you can build one website that functions as an iOS and Android application. This saves the cost and complexity of building a separate experience of iOS and Android, while giving users the best functionality regardless of how they are accessing the content.

    Prioritize content.

    Because users want PWAs to simplify, smooth out, and streamline their experience, ensure that high-priority content is easily and readily available. Do not overcrowd content with complex menus or distracting ads and banners to spare users from having to mentally filter through content. Instead, make important elements, such as a call to action, obvious.

    Communicate with users.

    Many users have come to expect instant gratification and feedback when interacting with technology. If they must wait for something to happen in an app, they want to know why and how long it will take. To prevent frustration from a seeming lack of response, clearly communicate what your app is doing at that time, such as by acknowledging input or showing a progress wheel for rendering.

    Avoid unwanted interactions.

    Because many PWAs are accessed on mobile devices with limited screen space, uncluttered designs are paramount. If too many interactive items are present in a limited space, users could accidentally perform unintended actions.

    To avoid that scenario, vary how interactions are registered, such as by requiring a long press to open an item or two fingers to scroll through a list. Additionally, clearly identify interactive features and static ones.

    Optimize for user devices.

    While designing a PWA, keep in mind the devices it is intended for. Typically, layouts and navigation for mobile devices vary for desktop apps. So, beware of the ways in which users interact with devices and figure out the capabilities to build to accommodate those interactions. For example, pinpoint how your app functionality changes if users rotate their device. Or, the effect caused by a mouse movement versus a touch screen.

    Focus on readability.

    Fancy and elaborate fonts can be appealing and might look captivating on a large screen but often do not translate well to mobile. Additionally, custom fonts might not be available on certain devices. For a consistent and comfortable user experience, stick to simple, default fonts. If you really want to use a custom font, set the device defaults as a fallback in case the custom font is incompatible with the device in question.

    Reduce friction.

    For all that speed PWAs are ideal, their loading speed does not matter if users cannot easily check out or fill out forms. While building your apps, minimize users’ pains with features like integrated payments, autofill, and automatic sign-in. It’s an absolute no-no that users must navigate away from your app to accomplish tasks, nor should they need to zoom in to access form fields or buttons.

    Provide offline features.

    Leverage PWA capabilities to allow users to interact with your application offline. This can support users in limited connectivity environments, and ensures high availability of the application even in case of server downtime.

    To display media assets, such as images and videos, in a PWA, be sure to adhere to the rules described earlier. For example, serve images in an optimized format for a great user experience.

    Another benefit of optimizing images in PWAs is related to caching those images for offline access. Given that mobile devices and laptops have limited cache storage, storing fewer bytes of data means that you can serve more images and, therefore, more offline content for users, who can then reap a full app-like experience regardless of the speed of their Internet connection.

    Paid 3rd Party PWA Resource

    Check out this eBook by Tamas Piros for the basics of PWAs and the procedure for creating them.

    For a cool solution, take a look at the Network Information API, an experimental web API that determines the network connectivity of the viewing device and that returns a value, such as 2G or 3G. With that information and Cloudinary’s flexible q_auto feature, you can load lower-quality images if the users are on a slow connection, and higher-quality ones otherwise.

    To take all that a step further, combine the Network Information API with videos. If the user is on a fast connection, load a video; for slower connections, load an image. You can pull that off easily with Cloudinary, which, by replacing the video extension in the URL with an image extension, takes the video’s middle frame and returns it as an image. That way, you can still deliver a remarkable visual experience on slower connections.

    Sign up for Cloudinary today and try out its nifty capabilities. Generous free plans are available to get you started.

Back to top

Featured Post