Skip navigation EPAM

How JavaScript Frameworks Impact Performance — and How to Monitor It

In the News:

Built In – by Dustin Sparks, EPAM

Page performance is a critical consideration for an application, but its importance is relative to the scenario.  

According to Dustin Sparks, lead front-end software engineer at digital and product design company EPAM Systems, considerations like search engines make fast performance a comparatively higher concern for external-facing applications versus internal ones. 

“Internal applications that are not exposed to search engines typically need this less, but external-facing applications — like commercial, informational and e-commerce websites — need to focus on page performance in order to be fast and high-performing; not just for users, but also for search engines,” Sparks said.

Accordingly, Sparks makes sure that the JavaScript frameworks his team uses are matched to the unique needs of a project. Prioritizing mobile performance for a recent client, for example, required lazy-loading support from the frameworks. 

“Most of these frameworks leverage webpack’s ability to associate chunks of code with specific features at build-time in order to load them where appropriate at run-time,” he said.

Additionally, deciding on a framework can be informed by outside considerations. When developing a largely internal, single-page application, Angular presented itself as an option owing partially to the client’s familiarity with the framework.

“We chose Angular partly because the client had an existing team that’s already familiar with it and a component framework already built with recent versions of Angular,” Sparks said. 

Giving a glimpse inside his development process, Sparks shared his recent use case of Angular, why his team adopts certain frameworks and how tools like Google’s Lighthouse help monitor performance. 

Dustin Sparks, LEAD FRONT-END SOFTWARE ENGINEER

What JavaScript framework is your team currently using? 
My team is distributed across several different projects, each of which has varying needs based on scope and clients’ requirements. Therefore, my team is actively using Vue, Angular and React in production applications. 
One of our latest projects is a single-page application with a standalone headless Angular 9 front-end hosted in an Alpine/NGINX Docker container. This project is mainly an internal application without a CMS or specific SEO requirements requiring server-side rendering, so we excluded those features from this one.

Why did you decide to use this particular framework?
We chose Angular partly because the client had an existing team that’s already familiar with it and a component framework already built with recent versions of Angular. Since the server-side integration was headless, the single page application approach has worked nicely with Angular’s built-in routing capabilities.
My team is actively using Vue, Angular and React in production applications.”

How do factors like page performance play into your development process? 
Page performance needs vary quite a bit between clients and projects. Internal applications that are not exposed to search engines typically need this less, but external-facing applications — like commercial, informational and e-commerce websites — need to focus on page performance in order to be fast and high-performing; not just for users, but also for search engines. 
In a recent project, mobile performance was the client’s main focus, and the application needed to support lazy-loading components. All of the modern frameworks our team was using support lazy-loading and code-splitting, which allow the application to only load the resources it needs on each page for each section. Most of these frameworks leverage webpack’s ability to associate chunks of code with specific features at build-time in order to load them where appropriate at run-time.

What other tools, technologies or strategies are you using to monitor or improve website performance?
Our teams heavily use Google’s Lighthouse tool to measure performance. Lighthouse is flexible enough to be accessible to developers while they’re building their applications locally — on their own machines via Google Chrome, while also being available to automation testing with a Node-based CLI version.

The original article can be found here.