Performance
Contrary to BE considerations, performance may not be the main thing to optimize for. Instead, on the FE, most optimizations lean towards speed of iteration.
There are of course exceptions, when dealing with low latency systems (pro trading) and a variety of clients (slow mobile connections).
Here are some general requirements that will help you architect a solution:
Response Time
What is the expected response time for various events. For example, for low latency systems such as trading terminals, you will want to use sockets of gRPC, which don't have much of the overhead of REST and GraphQL. On the flipside, such protocols aren't as advantageous for APIs that will evolve very quickly
First Load Speed
What is the expected time to first load? For example, are we dealing with a blog, where users are impatient and may navigate away after more than a second or two of load time.
Chunking
Webpack allows "chunking" the app into segments. So your preferences screen may be asynchronously loaded when you navigate to it. This is a great approach to reduce load time. However, it will increase load time in between pages (as opposed to loading up your app all at once)
Max Page Size
With the Node ecosystem, it's very easy to have bundle sizes in the megabytes. Which are no problem for gigabit LAN connections, but will cause issues on unreliable cellular connections. If lower page sizes are needed, you may want to opt for smaller libraries, or a few other strategies I will suggest below. I will discuss the tradeoffs of each strategy
Mobile App Considerations
Often times there will be a significant variation for the mobile vs desktop experience. While it's very convenient to maintain them as one app, sometimes the mobile experience could benefit from a smaller package size due to the cellular connection. There are many strategies to get the best of both worlds, such as sharing a common code library with tree shaking (ex: buttons, style guide, API handling) and chunking by route
Monitor Package Sizes
Using Alternative Libraries
Many mainstream libraries (React) will have great features, ecosystem, and support for various scenarios. But they come with a large package size. You may want to investigate alternatives if package size is an issue. For example Preact > React. Note that you may lose the advantages of realiability, ecosystem, and support if you opt for these libraries. So don't make this tradeoff prematurely.
Rolling Your Own Libraries
In general, there are very few scenarios where you might want to roll your own library, unless you have a very specific use case. The React community has optimized for every major use case of rendering standard components. You can most likely build on top of it rather than rewriting it.
However there are a few scenarios where standard libraries are not enough.
Special Requirements: At HOVER, we built a custom 3D Rendering library (on top of ThreeJS), because we had extremely specific needs, and there simply was nothing out there that covered those needs (for example ray tracing in the browser). Yet it still leaned heavily on ThreeJS when possible.
Performance: There may be some very high performance scenarios where standard libraries aren't sufficient. For example, charting and graphing come to mind. Standard tables will eat up all your memory when dealing with thousands of rows that need to be rendered at once. Likewise for charting. HighCharts does a great job, but may not be feasible if you have hundreds of charts on a dashboard. Remember to consider these requirements
Tree Shaking
Often times you can import just a portion of a package (ex underscore/map
instead of underscore
)
Functional vs Object Oriented
There is a lot of debate over which coding style is "better". And there certaintly are pros and cons to both, which I will go into later. However, when it comes to bundle sizes, functional will usually win out. It forces a style of few dependencies, and small objects. You will usually export individual functions as opposed to huge classes, which will enable tree shaking
SSR and SSG
Server Side Rendering is a great way to speed up that first load.
An additional benefit of SSR is SEO by Google, Bing, etc
Don't Put Marketing Pages In Your Main App
Your site will likely include many "marketing" pages, such as the home page, feature pages, help, contact, blog, etc. These pages tend to change very frequently in terms of content and design. But require no real "JS" functionality. Meaning by having your core app team work on marketing pages you are taking away from their time to work on the app. Additionally you are bloating your bundle size. And a lot of FE tooling is optimized for static content. Instead I recommend tools like Webflow and Squarespace where non-technical users can easily make copy changes. Additionally a Webflow engineer is significantly more affortable than an application engineer
Progressive Rendering/Loading
One way to speed up the time to first load is to render elements as the data becomes available as opposed to waiting for the whole dataset to load. This does require some pre-thought to make sure there's no "chunky" render experience. This usually requires defining loading states and set heights for containers.
Todo
Dataset Size
Do we anticipate any huge datasets to be rendered (thousands of history rows somehow) Ex: progressive tables, google photos
Monitoring Performance
Perf-analytics-fe
Google Performance API
Just log manually
Datadog
Metric - first page load
CDN - something like CloudFront? Akamai? Do we need multiple edge locations? Where are our users located?
Caching - latest info each time or slightly outdated ok? Latest - huge network usage Cache - might be slightly outdated Browser caching, cache busting LocalStorage Cookies or LocalStorage for Auth
Images
Image optimization - different sizes Retina Display (2x) Alt Text srcset (multiple image sizes)
Lazy load images
Serving over HTTP2 vs HTTP1 - compatibility, fallback
Load on Server
If doing SSR, more load on the server, are we using a separate server? Same server?
Load balancing for failover K8S cluster for server app?
For SSR app?
Lambda @ Edge?
Lots of API requests = too much load on server?
Or do we want the latest info all the time?
Microservices for FE, so that one app doesn’t affect another
Progress Web App?
Offline mode
No internet connection
Last updated
Was this helpful?