
- -Software engineering its all about understanding to move the state from point to point efficiently.  

- -Always keep it simple, add complexity when its really necessary.  

- -Least privilege principle is important, everything should be private by default.  

- -Design data so invalid states can ever exists, instead of adding many defensive checks.  

- -Code for humans first , computer doesnt care  

- -Abstraction hides complexity and also debugging clarity  beware of that  

- -Refactoring is not optional  

- -Your code will change, stop overscalling or prediction future, build for now make it easy for later change


Mindsets I developed through my experience.


> **In this article, we take a brief look at the evolution of client-side architectures and how they shaped the web as we know it today.**

we need to keep in mind that all of the innovations are designed to solve the business problem efficiently, based on these metrics:   
1- Performance  
2- Complexity  
3- Team size  
4- Cost  


in the early age of software engineering, most business logic was handled on the server side.  
we mainly needed to render static data in the browser and make it accessible to users.

## **Server-side MVC** :
since we already have a server application, it was easy to access databases and send pre-rerendered html to the browser from one centralized point. 
By the early 2000s, this marked the end of the debate, and frameworks like Django and ASP.NET became popular within developers’ stacks.

With the increase of web visitors, businesses started to expect the web to behave more like web applications,
so new problems started to appear ,
servers are receiving heavy interactivity load , and more developers are needed to focus on the client side .

---

at this stage, vanilla javascript  already introduced client-side logic, DOM manipulation, async communication ,

## **SPA** :
JS frameworks ERA, where the structured workflows and design patterns philosophy migrated to the client side now,  
many architectural patterns appeared under the single page applications:  
>**Component based** : mostly common for simple applications

>**BFF** : backend for frontend where the frontend owns the backend api DTO  
appeared with the multi client backend servers to avoid ( over / under) fetching data.

>**MVVM** : Model–view–viewmodel a classic separation of  
data, business logic, UI.

>**FLUX** : Unidirectional (Action → Dispatcher → Store → View)  
data flow pattern with centralized state management, Redux, Vuex.  

>**SSR/SSG/ISR** : Pre rendering strategies mainly to improve performance, SEO, and initial load experience.   

>**"Note" for classic modular architectures:**  
classic architectures like : Clean, Hexagonal, Onion are optimized heavily for backend,
can be applied conceptually in the frontend, only for long lived projects, where business logic doucoupling is extremely important 
but in most projects its hard to define boundaries and expect everyone to respect them
also the frameworks and there ecosystem were already opinionated.



---

now dedicated teams can solve complex data flows, Heavy UI rendering, apply unique patterns,
so we saw a release of large scale web-platforms, like Facebook, amazon and Binance
but tight coupling and technical opinion conflicts appeared.

## **Microfrontends**  
When many engineers worked on large modules, and the vertical scaling was not enough,  
the term microfrontends appeared as an inspiration from microservices,
where different Modules built with different technologies and design patterns can be deployed and managed separately.

## **Bonus**
with this trendy orientation into the browser, even heavy desktop applications and low-level systems began shifting toward the web.
WebAssembly (Wasm) made it possible to run near native performance code in the browser,
allowing languages like C, C++, and Rust to target the web without rewriting everything in JavaScript.

Evolution of Client-Side Architectures


A visually appealing software is only half the battle — its performance is what truly defines the user experience.  
This article dives into a collection of practical yet often overlooked strategies that can significantly boost your website’s performance.

---

## 1. General Frontend Optimizations

### The Browser Role (Critical Rendering Path)

We often focus solely on what we, as website owners and web developers, should do.  
But the truth is: delivering a fast web experience also requires a lot of work by the browser — how it receives our HTML, CSS, and JavaScript files and takes specific steps to convert them into pixels on the screen.  

Optimizing the critical rendering path improves load time and reduces perceived delays.  
Here is a simplified illustration of the render process steps:

![Cover Image](/assets/blog/frontend-performance/renderprocess.webp)

> This topic is out of the scope of this article, but I recommend these resources for more details:
> - *Ilya Grigorik* — [Critical Rendering Path: Crash Course on Web Performance](https://www.igvita.com/2010/06/17/analyzing-the-critical-rendering-path/)
> - *Ilya Grigorik* — [Analyzing Critical Rendering Path Performance](https://www.igvita.com/2010/06/17/analyzing-the-critical-rendering-path/)

### Minimize iFrames Usage

- iFrames are bad for performance and are not indexed by search engines.
- Use iFrames only if you don’t have any other technical possibility.

### Image Optimization

- **Compress Images**: Use tools like Squoosh or Compressor.io and aim for a compression level below 85% and less than 200kb (exceptions apply for high-resolution displays).  
- **Lazy Loading / Preloading**: Lazyload offscreen images to reduce initial load time, and preload images for the landing section.  
- **Use Modern Formats**: Prefer WebP over JPEG or PNG for better compression and quality.  
- **Define Image Dimensions**: Specify width and height for each image to avoid layout shifts.

### Minify JavaScript and Bundle Size

- **Dynamic Imports**: Split code into smaller bundles to reduce initial load time.  
- **Tree Shaking**: Remove unused code from the final bundle using build tools.  
- **Analyze Bundles**: Use tools like Webpack Bundle Analyzer or Source Map Explorer to identify large dependencies.  
- **Choose Dependencies Wisely**: Evaluate libraries by size and functionality using BundlePhobia or NPM Trends.

### Debouncing and Throttling

- Utilize these techniques with search requests or event handlers like `scroll` or `resize` to prevent unnecessary function calls.

---

## 2. React Ecosystem Optimizations

### Efficient List Rendering

- Avoid extra reconciliation: use unique keys to help React update the DOM efficiently.  
- For large lists, render only visible portions using libraries like `react-window` or `react-virtualized`.  
- Be mindful of dependencies inside `useEffect`, `useMemo`, and `useCallback`.

### Optimize State Management

- Avoid deep state trees and prop drilling, which can trigger unnecessary global rerenders.  
- State declaration rules:
  1. Keep state local when possible  
  2. Lift state up (parent → children)  
  3. Callback state (child → parent)  
  4. Global state (for complex scenarios)

### Utilize Caching

- **Cache API Responses**: Avoid unnecessary fetch requests and improve UX with smoother navigation.  

Depending on your priorities, you can opt for:

- **Automatic Caching**: Handled by libraries like TanStack Query, RTK Query, or `axios-cache-interceptor`.  
- **Manual Caching**: Implement caching logic yourself using `localStorage`, `sessionStorage`, or Redux.

---

## 3. Specific Use Case Scenarios

### Large Number of Viewport Elements

- Rendering many markers on a map or avatars in a Figma-like playground can be expensive and clutter the UI.  
- **Solution**: Use the "cluster technique" to group nearby elements into a single marker, dynamically adjusting based on zoom level or viewport.
![Cover Image](/assets/blog/frontend-performance/map2.webp)

### Charts Optimizations

- **Smoothing Data**: Techniques like clustering or random downsampling reduce chart points but can distort trends.  
- Use smoothing algorithms such as SMA, ASAP, and LTD to preserve chart shape and performance.  
![Cover Image](/assets/blog/frontend-performance/map.webp)


- **Render Charts on View**: Avoid rendering charts during initial page load to prevent freezing. Only render charts when they appear in the viewport.

### Dealing with Animations

- Prefer CSS animations over JavaScript.  
- Animate light properties like `scale` and `transform` rather than heavy properties like `width`, `height`, `margin`, and `padding`.  
- Avoid animation loops, especially on mobile. Stop loops when elements are out of view.

---

## 4. You Can’t Optimize What You Don’t Measure

- **React Profiler**: Helps you measure the rendering performance of a React tree programmatically, and find which elements are blocking or freezing your actions in the web  

![Cover Image](/assets/blog/frontend-performance/react-profiler.webp)

- **Lighthouse**: Provides webpage performance insights. Scores include:
  - First Contentful Paint (FCP)  
  - Largest Contentful Paint (LCP)  
  - Time to Interactive (TTI)  
  - Cumulative Layout Shift (CLS)  

> More details: [Philip Walton — Web Vitals](https://web.dev/vitals/)

---

## Conclusion

While these tips focus on JavaScript and the React ecosystem, the principles apply across all front-end technologies:  

- Clean architecture  
- Bundle size and image optimizations  
- Caching  
- Monitoring performance  

**Remember:** Performance isn’t optional — it’s essential for keeping users engaged and satisfied.

Blog.

Mindsets I developed through my experience.

Evolution of Client-Side Architectures

Frontend Performance: Best Practices and Practical Tips