Redirects may not always be obvious and even when we encounter them, we still may not know which part of the code is causing them, although we can assume that this will be an equivalent of the PHP's header function. To avoid a redirect, we can make the request more precise by using the right parameters, but this will needlessly grow our code and make it less portable. The slowest redirect is probably the one that comes from our own code as it gives a signal for the whole request body to be reloaded.
When a user types an address without the www prefix, the browser adds it, which can initiate a permanent (301) or temporary (302) redirect as the use of the Chrome add-on "Redirect Path" shows. This is a redirect initiated by the browser, but it happens so fast, that we barely notice it.
We can also think of URL rewriting as a form of redirect—one that happens on every request. Although the result is a clean URL with no evidence of the underlying technology, the use of regular expressions for matching and replacement can be slow (up to tens of ms) and adding more bytes to the .htaccess file makes the site slower while not adding much value to it. This is a redirect initiated by the web server. We should not forget that many people prefer clicking on links rather than specifying the correct URL structure. The latter makes them think and also adds to the perception of how fast the site feels.
Redirects take many forms and we must learn to recognize and avoid them. The purpose of a website is to deliver the content, not to seek detours to do the same. Not considering the value we provide through our websites is a harmful thought redirect.