Let’s assume you want to change what user sees on the website.
There are two ways to do that:
b) rebuild the whole page on demand (ie user input/click) via PHP (or simmilar server-side language). This way, you have to reload the page, yes, but you did not have to download any additional data prior to that and you can always use caching if you have resource heavy images, etc.
And let’s discount situation where server-side data manipulation is only option for security/validity reasons.
Both solution are viable, they simply don’t apply to the same use-cases.
b) This is the old traditional way to do web-applications. It is still valid a valid way to do web sites, let’s just have a look to why most people are changing their way.
Doing stuff client-side allows faster rendering when the user makes an input. It also reduces the resources needed by the server. And finally, by fetching data only on a webservice, you provide something that might be reusable by other systems. That’s why those solutions are getting more and more popular.
It comes at a cost, not everything can be done on the client (validation/security) and you often need to deal with different technologies as well as more numerous interfaces.
I’d just like to add that you don’t need to do everything with one solution or another, you can mix both approaches, on some event manipulating the DOM, on some other reloading the page.
EDIT : Since bandwidth seems to be a very strong concern, you can loose some of the user-reactivity by loading the JS code only when needed with solution a. See this example of lazy loading in JS Probably the more efficient design if you consider mainly/only that aspect.