I disagree. Using AJAX to hit internal APIs to load or update content improves performance of the site, and can make it easier to maintain.
Conditional loading certainly can improve perf. in theory. I've yet to see any evidence it does so in practice. The aggregate of bundle-size, bundle-parse, client-side execution resource-usage & added latency of the plethora of metadata normally bundled with API responses is more than enough to negate any actual perf. gains.
As for "easier to maintain", I've never seen anyone even try to make that argument in theory, nevermind practice. Pretty sure it's widely accepted even by advocates of this architecture that it's a trade-off of perf. gains for ease-of-maintenance losses.
It moves some of the rendering work from the backend (having to query the data and generate markup) to the browser (query the API and generate the content based on the responses).
At my current job, it's made a significant improvement. The server returns compact JSON data instead of HTML, so it's easier to generate the data and uses less bandwidth.
It also looks faster for the user, because they change search parameters and only part of the page changes, rather than reloading the entire page.
As for "easier to maintain", that may be subjective. Code to generate a simple HTML template from results is replaced by JavaScript code to hit the API and generate the DOM. Although HTML5 templates makes that much easier.
If most examples of a strategy make things worse, and only one person uses that strategy to improve things, then going around saying "everyone is doing it wrong" rather than questioning the strategy isn't particularly sound.
I've build plenty of (small) client-side rendered UIs myself that lazy-load content; I know the trade-offs and I even believe I can achieve a performant outcome on my own. But that's anecdotal. In the wild, I have not seen a single major website improve perf. via lazy-fetched content rendering.
> My modern version of this is browsing with JavaScript disabled. Most of the sites that don’t work weren’t worth my time anyway.
I think a lot of sites that require JavaScript are worthwhile.
(Whether they are all well implemented is another matter.)
It is one of those things where in theory if absolutely everything was done right and no other stuff was done differently it can work. E.g. if the only difference between a JS-enabled and a JS-disabled version of the site was the content change and nothing else (no additional JS frameworks, functionality or whatever) then yes it most likely can be faster (though for the difference to be noticeable the site needs to be rather heavy in the first place).
Problem being that in practice this comes with a bunch of other baggage that not only throws the benefit out of the window but introduces a bunch of other issues as well.
The reality is, with node junk, the average site uses 10mb of js, taking 5s to render, to show 1kb of text.
Get rid of that 10mb of js, all those fonts, and you don't need to update only part of a page.
It will load and render in 10ms.
For the main content, yes, yes, most will. Why are they on the website in the first place?
Especially the main content. Sure, some things you can load later, like comments, etc
Many years ago smart frameworks implemented smart stuff like you can display only what is visible. For example you could have a table with 1 million rows but in your html page you will not create 1 million row elements, you can create GUI widgets only for the visible part, as the user scrolls you can recycle existing widgets.
As a practical example , you go to a yotube channel page and they load only 2 or 3 rows of videos and you have to scroll to force more to appear, this means you can't do a Ctrl+F and seatrch and is also less efficient because as you scroll the items at the top are not recycled and reuse so probably more memory is used.
The json for all the videos is not huge,some strings with title and thumbnails, maybe some numbers but the issue is that is not possible to natively do the best/correct thing, only recently we got lazy loading for example so basicaly html was desibned for documents and frameworks/toolkits designed for apps did the correct thing many years ago... this is an explanation but no excuse why things are such a shit show with pagination today.