I assume you're talking about a structure like this:
F
|
ISP
|
R S
| |
===+===+===+===
|
C
If your router supports so-called "hairpin routing" (or "hairpin NAT"), then if you have this situation it will accept the request from client C and send it back out the LAN-side interface to server S. This has the advantage that the DNS is the same for C and also far client F. (The traffic doesn't actually go out of the router to the internet though, as you've suggested, it just goes in and back out of the router's LAN interface, somewhat inefficiently, but doesn't touch the slower WAN interface.)
If your router does not support hairpin routing, the packets from C will not reach S: depending on configurations, they will fail on one of these ways: a) be discarded by R; b) be sent from R to ISP which then discards them; or c) sent from R to ISP and back in a loop until TTL expires.
As noted in comments you might prefer to give different DNS answers to local and remote clients, and send C to S's local address, and F to the NAT address from R. You can do this in a number of ways, the simplest being a local resolver which is also a name server for your own domain, giving private answers to local clients, and with a typical DNS service's server giving public answers to remote clients. Alternatively, if you run your own DNS servers you can use "split horizon DNS", but I don't suppose that's likely to be best for you.
The other solution is "public LAN" or "DMZ" setup, where there are two local segments:
F
|
ISP
|
R
/ \
==+===+= =+===+===
| |
S C
Here you have a separate LAN segment for publicly-available servers. This has the advantage that you can control ingress to S's segment very tightly, and doesn't require hairpin functionality. But it's more work on your networking setup, and doesn't have any performance advantage.
Multiple DNS is certainly the easiest answer if you can do it. It's not very difficult to set up, gives the best local performance, has the simplest networking.
EDIT: as suggested in comments, using public addresses throughout obviates the need for any NAT, and so you don't have this problem at all. But that would probably be IPv6, which might or might not be practical for you.