Interviewing about a software developer for the company website. I've noticed that navigating trough the pages of items on sale and clicking on an item takes longer than it should.
I believe this is an issue as my current employer wouldn't tolerate such a long loading time and I personally believe the loading time can be decreased.
Should I mention this during the interview
Don't if you want the job. Best case, they know about this and want to fix it and it's not fixed for whatever reason, and you're just touching a sore point. Not a good way to make friends. Worst case, they are absolutely happy with their site and you are seeing as rocking the boat.
If you are a web developer or in a related area they might ask if you looked at their website and how you would improve it. At that point you can say that you did indeed look at it, and among other things you would make it faster. So you are not saying that there is something wrong with what the company does, but what good things you can do for them.
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).
Don't do it.
It's like going to a party and meeting new people, and there is this key couple who have the power to invite you back again. All they will remember is how you insulted the guy's wife by pointing out her flaws and how to fix them.
He can't invite you back. It's become a matter of principle.
