6 ms·

So I looked at https://nextfield.vercel.app/exhibitions https://nextfield.vercel.app/exhibitions to understand how Nest.js's static page rendering works alongsi

So I looked at https://nextfield.vercel.app/exhibitions https://nextfield.vercel.app/exhibitions to understand how Nest.js's static page rendering works alongside React. The HTML it returns is really big! 374kb before compression. I turned off Javascript to see how the page loaded without it, and it still downloaded the whole 374kb HTML (I guess that's to be expected). I dug into the HTML and realised that the reason for the size is that Next.js includes a <script id="__NEXT_DATA__"> element that contains the entire data of the page's components as JSON for React to hydrate. This JSON takes up 60% of the whole HTML file! I suppose it's prioritising smooth rendering over reducing data use, but it doesn't seem very optimal, tbh. And it's really inefficient for browsers operating without JS, since every navigation click requires downloading a bloated HTML file. I found Github issues, SO questions, and blogposts about this drawback, and it seems like this is a common practice for even the largest websites. This massive duplication seems to be a problem that newer frameworks are trying to solve. I wonder if non-dynamic sites like this aren't better off just being static HTML served from CDNs, since they aren't interactive. Also, the main stylesheet is 1.12mb uncompressed! Bootstrap is part of it, but it seems like there's a lot of other CSS? (Now I understand more about why my web browsing on mobile consumes so much data even on low-media sites, ouch.)

solardev 4y ago
So I don't want to take away from your main point: That these frameworks add bloat (even more on top of React). It's an important consideration. Like you said, it's a drawback/trade-off. In our case, we decided it wasn't a dealbreaker and would still be worth it because: 1) That 374kB file is only like 50kB gzipped. We had bigger fish to fry/optimize, like that massive CSS. (Which is a holdover from the PHP days. Phase 2 of the project would eventually have refactored that and tree-shaken it, but it was out of scope for the prototype.) A lot of the bloat you see is because that's still a work in progress and they haven't had a chance to do any optimizations yet. A future version would probably get rid of much of that CSS and maybe even Bootstrap, then think about webfonts, oversized images, etc. There's a lot of work on that front. 2) Our target audience wasn't expected to have Javascript disabled, and with it enabled, Next's hybrid rendering model actually makes it really fast to navigate between pages after an initial page load. In an earlier test, we had the individual exhibition pages side-by-side, the Drupal version next to the Next one in iframes, plus back/forward buttons to navigate through each exhibition in sequence. Originally that was meant just as an easy way to catch visual differences, but we realized that the Next version was loading almost instantly (couldn't even see it load), whereas the Drupal version took 4-5 seconds per navigation. It turned out that Next was able to just download the tiny JSON (~20kB) for each exhibition and injected that into the React shadow DOM for updates; it didn't have to download anything else while navigating between navigations. That was an unexpected, and really powerful, feature that would normally only be available in SPAs. Realistically, this means that if users had JS on, the initial page load might be a bit bloated, but subsequent navigations between pages should be MUCH faster. 3) The JSON shape was also an artifact of our CMS API (in GraphQL). If we wanted to, we could've optimized it before sending it over the wire. 4) Most importantly... I want to reiterate this... the main benefit of Next.js is NOT page performance, but developer experience. To the extent that there are any improvements at all to page load speed, that is a nice side effect. But even if there weren't, it would still be worth it for us. The big difference is in being able to quickly create new pages/templates, in a single language (JS), with a zero-stack configuration. Especially once we also decided to move the content to a hosted headless CMS. That meant no more LAMP stack to maintain, no more DBs to prune, no more fiddling with CDN caching, Drupal modules, Docker, CI/CD etc. Previously we were spending 80% of our dev time fighting our own stack and framework (Drupal is really really hard to work with, even compared to the messy Node/React ecosystem). Next got us out of the DevOps and infrastructure game completely so we could focus solely on the frontend, and Next + Vercel takes care of everything else. It's not just "serverless" but almost stack-less in a way (managed). All we had to do is write React, push a commit, and done. For a small team, that was HUGE... being able to push out a new template in a matter of hours instead of days/weeks, and being able to deploy to production in seconds (and roll back in seconds) too. In the Drupal world, there are companies like Pantheon and WPEngine and Acquia that try to do the same thing for the PHP landscape (and they do it well), but Next + Vercel is waaaaaay easier and faster. Other competitors in that scape (for JS) are Netlify, Gatsby, etc. These Jamstack hosts are gaining popularity because they are so much easier to work with than the traditional backend + pipeline + frontend model. But of course they have their own tradeoffs and aren't right for every use case -- for example, if we anticipated heavy user interactions (logins, profiles, personalizations, etc.) we would've had to consider a lot more factors. But for write-rarely, read-often informative website, it was the perfect fit for us. YMMV of course!

solardev 4y ago

So I don't want to take away from your main point: That these frameworks add bloat (even more on top of React). It's an important consideration. Like you said, it's a drawback/trade-off. In our case, we decided it wasn't a dealbreaker and would still be worth it because: 1) That 374kB file is only like 50kB gzipped. We had bigger fish to fry/optimize, like that massive CSS. (Which is a holdover from the PHP days. Phase 2 of the project would eventually have refactored that and tree-shaken it, but it was out of scope for the prototype.) A lot of the bloat you see is because that's still a work in progress and they haven't had a chance to do any optimizations yet. A future version would probably get rid of much of that CSS and maybe even Bootstrap, then think about webfonts, oversized images, etc. There's a lot of work on that front. 2) Our target audience wasn't expected to have Javascript disabled, and with it enabled, Next's hybrid rendering model actually makes it really fast to navigate between pages after an initial page load. In an earlier test, we had the individual exhibition pages side-by-side, the Drupal version next to the Next one in iframes, plus back/forward buttons to navigate through each exhibition in sequence. Originally that was meant just as an easy way to catch visual differences, but we realized that the Next version was loading almost instantly (couldn't even see it load), whereas the Drupal version took 4-5 seconds per navigation. It turned out that Next was able to just download the tiny JSON (~20kB) for each exhibition and injected that into the React shadow DOM for updates; it didn't have to download anything else while navigating between navigations. That was an unexpected, and really powerful, feature that would normally only be available in SPAs. Realistically, this means that if users had JS on, the initial page load might be a bit bloated, but subsequent navigations between pages should be MUCH faster. 3) The JSON shape was also an artifact of our CMS API (in GraphQL). If we wanted to, we could've optimized it before sending it over the wire. 4) Most importantly... I want to reiterate this... the main benefit of Next.js is NOT page performance, but developer experience. To the extent that there are any improvements at all to page load speed, that is a nice side effect. But even if there weren't, it would still be worth it for us. The big difference is in being able to quickly create new pages/templates, in a single language (JS), with a zero-stack configuration. Especially once we also decided to move the content to a hosted headless CMS. That meant no more LAMP stack to maintain, no more DBs to prune, no more fiddling with CDN caching, Drupal modules, Docker, CI/CD etc. Previously we were spending 80% of our dev time fighting our own stack and framework (Drupal is really really hard to work with, even compared to the messy Node/React ecosystem). Next got us out of the DevOps and infrastructure game completely so we could focus solely on the frontend, and Next + Vercel takes care of everything else. It's not just "serverless" but almost stack-less in a way (managed). All we had to do is write React, push a commit, and done. For a small team, that was HUGE... being able to push out a new template in a matter of hours instead of days/weeks, and being able to deploy to production in seconds (and roll back in seconds) too. In the Drupal world, there are companies like Pantheon and WPEngine and Acquia that try to do the same thing for the PHP landscape (and they do it well), but Next + Vercel is waaaaaay easier and faster. Other competitors in that scape (for JS) are Netlify, Gatsby, etc. These Jamstack hosts are gaining popularity because they are so much easier to work with than the traditional backend + pipeline + frontend model. But of course they have their own tradeoffs and aren't right for every use case -- for example, if we anticipated heavy user interactions (logins, profiles, personalizations, etc.) we would've had to consider a lot more factors. But for write-rarely, read-often informative website, it was the perfect fit for us. YMMV of course!