The interview isn't the right place to bring up small issues. Either you'll end up working for them and can pursue it then, or you won't and you can decide whether to send feedback as a user (if the website provides a way to do that).
If there is a larger issue about either the company or its product, something where knowing the answer might affect your decision, then frame a question about it instead of bringing it up directly. For example, you could ask "what are you using on the back end for the shopping cart? a third-party solution, or did you roll your own?". Or you could ask "how do you decide where to focus on in performance testing?" (note the implicit assumption that they do performance testing).
Prepare an answer to "why do you want to know that?", which might or might not reference what you saw explicitly. On the shopping-cart question, your reason might be that you were surprised that this part of the site was slow or your reason might be that there are trade-offs between the two approaches and you're wondering how they decided. (This could lead into a discussion of development effort, "not invented here" syndrome, vulnerabilities in third-party libraries or services, and so on.)
Don't go into an interview with bug reports, but you can use things you've seen in their product to have a technical discussion. I've gone to several (successful!) interviews with questions of the form "how do you approach $problem?", some of which were because $problem is common in the field and some of which were because I knew they had $problem (but didn't need to say so; in one case the interviewer admitted it on his own).