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
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.
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.
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:
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.
The views expressed on this blog are those of the author and do not necessarily reflect the views of New Relic. Any solutions offered by the author are environment-specific and not part of the commercial solutions or support offered by New Relic. Please join us exclusively at the Explorers Hub (discuss.newrelic.com) for questions and support related to this blog post. This blog may contain links to content on third-party sites. By providing such links, New Relic does not adopt, guarantee, approve or endorse the information, views or products available on such sites.