Sending Ajax to the site and returning a JSON, thus manipulating the array to use in the application.
But this can be paid over time if the data is loaded multiple times without reloading the page, since the amount of data transmitted is less per request.
Sending Ajax to the site and mounting it to a string with HTML code and returning it to the application to use this HTML in its interface.
Changing in kids, the site loads faster, but with each new asynchronous update it will consume a bit more bandwidth and processing on the server.
Another problem with this approach is that it can be complex to keep page snippets separate from the main page that are now rendered within the context of the page, sometimes independently. Without good organization and a good rendering engine this tends to generate spaghetti or duplicate code.
Normally it pollutes the backend code with infinite HTML tags being concatenated
Not necessarily. In PHP you can have snippets of templates that can be rendered independently or in conjunction with the page. Some frameworks allow you to create components or widgets that work that way.
You prevent that ajax url from being used in other parts of your project, because not everyone who needs those data needs that HTML.
Rendering HTML definitely engages the service with your page, but nothing prevents you from keeping JSON and private HTML services privately separate.
In my experience, third-party data consumers often have a different view of data. This is not always the case, but trying to maintain a single API for internal and external use can be a much greater headache, as you get stuck by the API contract that you can not break into external systems.
Anyway, I would choose to just return the data to your frontend and treat all the HTML you need right there.
From an architectural point of view this is more sophisticated form, the current trend and preference of the great majority of front end developers, because it enables:
Better concept separation : does not divide rendering logic between client and server, but focuses on the client
Flexibility : Allows the evolution of the front end independent of the back end APIs or services.
Finally, if you're really concerned about performance, consider using a more compact protocol than JSON, such as Google Protobuf . Here are some advantages here and an implementation in PHP here .