In estimated order of importance:
Pick a perfectly clean channel and have good signal strength (between -40 and -60dBm).
Make sure no other traffic on the network is competing for airtime with your app. Especially multicast traffic, which gets sent at a low signaling rate, chewing up airtime. Don't use multicasts or broadcasts in your own app.
Make sure you have more than enough bandwidth for your app. Overprovision your links by about 33%.
Disable 802.11 power save; keep all clients in Constantly Awake Mode (CAM).
Disable any AP or client settings or software that could cause the radio to do scans or otherwise go off-channel. These include old things like roaming and channel agility, and new things like Wi-Fi Direct and Apple AirDrop. Don't run any kind of Wi-Fi network scanner like NetStumbler or inSSIDer in the background. Disable Wi-Fi-based location detection. Watch out for Widgets/Gadgets/Gizmos that list Wi-Fi networks; they often cause scans.
If using 2.4GHz, disable Bluetooth.
Disable NAT on the base station.
Use a low-latency WMM (QoS) queue. Either voice (VO) or video (VI).
Disable frame aggregation: both A-MPDU and A-MSDU.
Prefer IPv4 over IPv6. To this day, there's still lots of equipment that handles IPv4 via a hardware-assisted "fast path", but still handles IPv6 via software.
By the way, tweaking Beacon Intervals and DTIM Intervals are likely to do more harm than good overall. Most clients expect Beacon Intervals to be about 100 TU's (802.11 Time Units; 1024 microseconds; sometimes called kµsec (kilo microseconds) or Kiusec (Kibi microseconds)), and DTIM intervals between 0-3 beacons. I've seen some poorly-written Wi-Fi clients freak out if you change either of those too much (like make either of them more than one second long).