The Problem with this whole concept of Microservices for the frontend is, that it can't really work out due to the constraints of the frontend: Every byte count

The Problem with this whole concept of Microservices for the frontend is, that it can't really work out due to the constraints of the frontend: Every byte counts. It does matter how a component is written and which framework you used, as you don't want to load 2MB of Javascript for every new page. This is in contrast to the classical Microservices, where it absolutely doesn't matter how big each of them is. So of course I checked their new site, that was written with this architecture (https://www.hellofresh.com/shop/ https://www.hellofresh.com/shop/). Could they solve this problem? In total, they transmit ~770KB of minified JavaScript with an activated adblocker. This is quite a lot, at my last company we had a big react app with 70K LOC and a number of used libraries. It served about 800KB of minified JavaScript. They load React, ReactDom, Immutabble and Axios separately to avoid having them duplicated, which accounts to ~67KB. So what are the 700KB doing? 219KB for a shop fragment 135KB for the header particle 96KB for the footer particle The last 250KB is some API stuff called api_static and api_dynamic. I can't really tell how sophisticated the shop is with its 219KB, but having a 96KB Footer and 135KB Header should raise some doubts, how is this possible? A React Footer should be 1KB or something. As I checked the source code I found mainly vendor code and as far as I can tell it's duplicated among the source files. For me this shows me, that they couldn't solve the problems that arise with such an architecture and I doubt that there will be anything that solves these issues (without putting a lot of burden on the developers) in the near future.