There are an awful lot of reasons why a page may be slow, and not all of them have anything to do with the server end. XAMPP isn't slow by nature (nor is WampServer). If you're sure that it's not code running in the browser (JavaScript, Flash, etc. - especially JavaScript that touches the DOM repeatedly) and you aren't waiting for external HTTP requests (fonts, stylesheets, JavaScript libraries, advertisements, social media widgets, and that sort of thing), then there are a few things you can look at.
(You can check to see if it's the browser by creating a static HTML version of your page to take PHP and the database out of the equation. And use your browser's developer toolset if it's still slow; it will tell you a lot.)
First, do you have enough memory in your machine to run both the server (servers, really, since you are running both Apache and MySQL) and the browser at the same time effectively (along with whatever else you may have open, and the operating system as well)? If you are using an old machine or something like a netbook, try closing everything you don't need.
Second, take a good look at the code you're running. Are you doing the same thing over and over again when you don't have to? Things like making the same request to the database over and over again instead of getting the data once into a variable or object and using it over and over again from there can make a
huge difference. So can things like
Schlemiel the painter's algorithm - make sure that if you are iterating over a collection of data that you aren't counting up from zero every time. If you are parsing data into tree structures (such as using a DOM parser), you need to be aware that those structures can get awfully big awfully fast, and that can leave you out of fast memory and doing a lot of paging (or swapping to disk if things get really bad). It's really, really easy to code things that work in PHP; it's a little less easy to code things that work quickly, and because the faster things are usually a little harder to explain (and to grasp) a lot of the tutorials and whatnot you'll find on the web will show you the worst way. (By the way, if you're having memory space or execution speed problems on your local machine, it's going to be worse on a shared hosting server — especially on Free Hosting, where the restrictions on execution time and available memory may mean the page won't work at all.) Oh, and if you're using some sort of silly framework where all of the code lives on a page that's included on a page that's included on a page that's included on a page that's included on a page that's included on a page that's included on a page that needs to load a template to make the HTML happen, just stop. Figure out what the application is supposed to be doing and simplify as far as you can. (Those frameworks are
marginally useful for large teams of developers, but they lead to inefficient, slow, and hard-to-maintain code. The only plausible benefit to them outside of a corporate cubicle farm is that it means that developers are always working with the smallest possible chunks of code, and that's only a real benefit in bottom-up design. Since PHP doesn't allow problem decomposition or language composition at that level, it only leads to long load times and code hiding.)
There are some things that are supposed to be kind of slow, like the password hashing and verification built into PHP 5.5. Not "takes all day" slow, but a big chunk of a second, which may come as a surprise if you were expecting near-instant response, or if you were expecting to be able to use the function several times on a single page call. (The reason it's slow is to make it as hard as possible to use brute force to crack passwords. It may take a tenth to a half of a second to check one password, but that means it takes at least 24 hours to check a million guesses at the same password on the same hardware, and there are a heck of a lot more than a million possible passwords to check if you want to crack a password.)
