DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Data Engineering
  3. Data
  4. Building Network-Friendly Single-Page Apps

Building Network-Friendly Single-Page Apps

Let’s look at some common network-related performance problems developers experience when using single-page app (SPA) frameworks and discuss how to address them as browser vendors encourage developers to use secure connections and new protocols like HTTP/2 gain wider acceptance.

Clay Smith user avatar by
Clay Smith
·
Oct. 18, 16 · Analysis
Like (6)
Save
Tweet
Share
7.98K Views

Join the DZone community and get the full member experience.

Join For Free

Network latency in web applications is not a new performance culprit. Developers and operations teams have known for years that sending and receiving data over networks can be slow. Yet as web pages carry consistently increasing amounts of CSS, JavaScript, and HTML, optimizing for better network performance—from reducing the number of connections to caching to bundling AJAX requests—still doesn’t get the attention it deserves.

To change that, let’s look at some common network-related performance problems developers experience when using single-page app (SPA) frameworks and discuss how to address them as browser vendors encourage developers to use secure connections and new protocols like HTTP/2 gain wider acceptance.

Revisiting the Client-Server Model for SPA

Building a modern JavaScript web application requires a substantial amount of technical knowledge. SPAs introduce an even more complicated development model than the designers of the World Wide Web had in mind in the early 1990s. The original design of the Web—still visible in the navigation bar of nearly every browser—assumed a set of pages joined by hyperlinks that can be navigated backward and forward or reloaded.

http request diagram

Example HTTP requests for viewing two pages on a site like it’s 1998.

In this model, comparing the load time of two simple HTML pages on the same domain is straightforward because they have different URLs, server-side processing time, and static dependencies such as CSS, images, and JavaScript.

Understanding performance in SPA apps is more challenging. It still relies on some combination of JavaScript, HTML, and CSS to render the page, but a SPA app makes additional requests (usually via AJAX) for additional content—including entirely new views—without completely reloading the originally requested page.

http request diagram: single-page apps

Example HTTP requests for a SPA application.

Performance questions like “How long did the page take to render?” and “How much time was spent doing server-side processing?” become complicated because a single view is often rendered using multiple HTTP requests triggered by JavaScript code that exists outside the classic browser page lifecycle.

Assume the Network Is Slow and Unreliable

Every smartphone user is familiar with pages that load slowly (or not at all) due to a flaky cellular data connection. As web apps capture an increasingly global, mobile audience, fast, reliable, and affordable internet connections can no longer be assumed.

Page size is closely related to how quickly a page loads, so measuring the overall size of the page is a good place to start the optimization process. Tools like New Relic Synthetics that give developers a breakdown of content sizes is a good starting point when deciding what can be removed or compressed.

This testing needs to be continuous and iterative because web page sizes can vary over time. For example, when we analyzed presidential-candidate sites during the primary campaign in February 2016, the total response size and load time fluctuated wildly on some sites as images and videos were rapidly updated in response to current events.

Image title

Total page size of presidential-campaign websites, February-March 2016.

Methods to reduce page transfer size vary. Simply removing unneeded JavaScript libraries and code and enabling image and gzip compression techniques on the server-side can help enormously. More advanced tools like Webpack or Rollup allow advanced dynamic loading and bundling techniques designed specifically for apps using SPA frameworks.

The Best Network Request Is One You Don’t Have to Make

Correctly caching static and dynamic resources, a feature built into the HTTP protocol and every browser, is important for apps that depend on repeat visitors. Google has an excellent primer on HTTP caching that is required reading for understanding how and why to cache using the Cache-Control and ETag headers.

Content-delivery networks (CDNs) are especially powerful when used in conjunction with well-defined public caching strategies. By caching content at edge locations all over the globe on servers located physically closer to users, CDNs can significantly reduce network latency. With secure connections using the Transport Layer Security (TLS) protocol quickly becoming standard for mobile and web content, there are potential performance benefits to performing the handshake needed to establish a secure connection as geographically close to users as possible.

Most important, however, auditing and investing time on HTTP caching and CDN strategy benefits all browser and mobile browser clients regardless of SPA framework, device, location, or operating system.

Implementing Web Performance Optimizations Using Microservices

Performance best practices like caching, bundling requests, leveraging CDNs, and the emergence of new protocols like HTTP/2 and TLS put pressure on the systems and infrastructure that power SPAs. For many teams, implementing these strategies is limited by difficult-to-change legacy systems and APIs. A software architecture pattern—what SoundCloud calls backends-for-frontends (BFFs)—is emerging that encourages teams to build small, specialized services that optimize the delivery of content to specific clients.

Image title

Simplified backend-for-frontend architecture.

In this model, instead of a large REST API monolith shared by external clients like web, mobile, and third-party partners, a small service is built that optimizes delivery for a specific downstream consumer. A web browser BFF could support features like HTTP/2, implement caching methods, or bundle API requests from downstream services to reduce the number of AJAX requests. A native mobile BFF, in contrast, could leverage cutting-edge data transfer protocols like gRPC that aren’t supported by browsers.

A major downside to this pattern is the need to manage the increased operational complexity of managing new services. A BFF must be very stable and always available—otherwise external requests will fail and users will notice. Ideally, however, a BFF service bridges the knowledge gap between backend and frontend teams. Technical expertise on how the frontend is designed and performs is directly integrated into the design of the service that supports it, allowing client-specific design decisions to be quickly implemented and deployed.

A Checklist for Finding and Optimizing Slow AJAX Requests

Before designing a new backend system or implementing a caching strategy, it’s a good idea to start by investigating pages that are most impacted by slow AJAX requests. Let’s check out the page load timings and route change timings in this Angular application using New Relic Browser’s SPA monitoring. We’ll sort pages by their average response time, so we can focus our energy on the slowest parts of the application, and drill into the associated AJAX timing information so we can see the most time-consuming calls:

Image title

click to enlarge

When going through the list of AJAX requests with the slowest response times, it’s possible to perform a basic performance audit. As discussed above, this could include such questions as:

  • Can any AJAX requests be eliminated?
  • For pages with multiple AJAX requests to the same host, can they be combined?
  • Is caching configured using the ETag or Cache-Control header? Has it been tested?
  • Is gzip compression enabled?
  • Is a CDN being used? How does page responsiveness vary for international users?

Networking Performance Is Required Knowledge for Frontend Developers

Users of web apps don’t care what framework was used to build it, they just want the web app to be fast and functional. While SPA frameworks can make creating desktop-like customer experiences easier for developers, a key bottleneck of web app performance, network request latency, is here to stay despite promising new innovations in protocol design.

Focusing on usability, design, and performance has long been the domain of frontend developers. However, with modern frameworks and app design, SPAs can no longer be thought of in relative isolation from backend systems. As SPAs directly and indirectly depend on dozens of upstream services—from internal apps, APIs, and CDNs to third-party products—understanding and getting network performance right is critical to the overall user experience.

Additional Resources

  • New Relic Single-Page App Monitoring
  • High Performance Browser Networking
  • How HTTP/2 Is Changing Web Performance Best Practices
  • BFF @ SoundCloud
mobile app Web Service Requests Cache (computing) AJAX Network TLS dev microservice

Published at DZone with permission of Clay Smith, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Better Performance and Security by Monitoring Logs, Metrics, and More
  • Top Five Tools for AI-based Test Automation
  • Why You Should Automate Code Reviews
  • How to Quickly Build an Audio Editor With UI

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: