OK. So, at least from my point of view, those are two separate things.
1) Testing the the things that feed into the website. Here, you care about the language of the helper program if you’re doing function testing, because you need to be able to understand the interfaces that the program is using. Ideally, you can (and the program should be architected to allow this) be testing interfaces to the databases or whatever backs up the data. You don’t want to be doing this via a web browser/web automation tool, since that adds layers that you probably don’t have much control over.
2) Testing the web site itself. Here, you shouldn’t care about the backend processing; that’s invisible (or had better be) to the web browser. And here, ideally, you can use web automation tools to do the testing. Now, here, you might want to test for known problem areas that might be dependent on the underlying tools (SQL injections, passing in invalid data via custom http headers, cross site scripting holes, etc), but the language that the backend program that’s providing the data that builds the website is probably irrelevant; here you’re testing the end-user experience.
If you’re trying to do both of those things at once, in my opinion, you’re making a mistake, as there are types of testing that you can do if you’re testing the backend program that you can’t do from the website, and vice versa. And both of those tests are going to find different sorts of performance problems.