Layer 1: Server Location and International Routing
The Philippines has enterprise and carrier-grade datacenters (ePLDT Vitro, ST Telemedia Global Data Centres), but it is not yet a major regional cloud hub like Singapore. Many international services and game servers are still routed through Singapore, Hong Kong, or Japan. This means your ping to a foreign-hosted game server is determined by: the physical cable path, how your ISP peers with that destination, and how efficiently your traffic reaches the cable landing stations in Cavite and Batangas.
Scourge Servers runs a primary node physically in Cebu, plus a secondary node in Singapore. For most Filipino players, the Cebu node gives the lowest possible latency since your traffic stays within domestic ISP infrastructure and avoids international transit entirely. Typical ping ranges by region to the Cebu node:
- Cebu and nearby Visayas: 5ms to 15ms. Traffic remains within domestic infrastructure with no international hops.
- Iloilo, Bacolod, and western Visayas: 15ms to 40ms. Close inter-island routing on most major ISPs.
- Mindanao (Davao, CDO, Zamboanga): 15ms to 40ms. Routes through Cebu, avoiding international transit entirely.
- Metro Manila and NCR: 30ms to 70ms. Routes south through Luzon before reaching Cebu.
- Luzon outside NCR (Pampanga, Baguio, Laguna, etc.): 50ms to 90ms. Routes through Manila first, then south to Cebu.
These are typical ranges, not guarantees. Actual latency depends heavily on your ISP routing, peering arrangements, congestion levels, and geographic location. Test against the actual server IP rather than assuming.
Compare this to a Singapore-only host: even a good Manila connection sees 30ms to 80ms and Mindanao players see higher. A server inside the Philippines is a genuine advantage, especially for Visayas and Mindanao players who are typically underserved by international-only hosts.
Layer 2: Your ISP and the Barangay Problem
In the Philippines, ISP quality is not just city-level or even subdivision-level. It is often barangay-level. Globe can be excellent in one community and terrible two streets over. The reason is how last-mile infrastructure works:
- Fiber rollouts are contracted to local third parties. The quality of splicing, cable routing, and equipment depends on which contractor did the work in your specific area.
- Street cabinets and fiber nodes serve a fixed number of households. When subscriber density exceeds what the node was designed for, everyone on that node shares the congestion.
- Peak hour congestion (roughly 7 PM to 11 PM) is one of the clearest indicators of node saturation. If your ping to 8.8.8.8 goes from 10ms at noon to 150ms at 9 PM, your local node is oversubscribed.
How to diagnose properly: rather than pinging 8.8.8.8 (which tests Google DNS, not your game server), ping the actual game server IP or use tracert/mtr to see the full path:
ping <game-server-ip> -t
tracert <game-server-ip>On Linux/Mac, mtr <game-server-ip> gives a combined traceroute and ping that shows per-hop packet loss and jitter in real time. Google DNS may use completely different routes than your game server, so testing the actual destination gives more meaningful results.
If you document specific ping spike times and submit a technical report to your ISP (not a generic speed complaint), you are more likely to get an actual technician dispatched.
Layer 3: Latency, Jitter, and Packet Loss
Most players only look at the ping number, but there are three distinct metrics that affect how gameplay actually feels:
- Latency - the round-trip time for a packet. Causes input delay. This is the number shown in the server browser.
- Jitter - variation in latency between packets. A connection that bounces between 20ms and 120ms feels worse than a stable 60ms connection. Jitter causes inconsistent movement, rubber-banding, and unpredictable desync.
- Packet loss - packets that never arrive. Even 1% to 2% packet loss causes significant rubber-banding and desync in real-time games. A stable 50ms connection with 0% packet loss often feels better than a 20ms connection with intermittent packet loss.
You can observe all three with a sustained ping test. Watch not just the average but the min/max variance (jitter) and any "Request timed out" lines (packet loss).
Layer 4: Bufferbloat - Why Ping Explodes When Someone Uploads
One of the most common causes of gaming lag spikes in home networks is bufferbloat. This happens when your router has a large buffer that queues packets during periods of high upload or download activity. When someone in your house runs a cloud backup, uploads to Google Drive, or streams, the router fills its buffer and all other traffic including your game packets sits in queue waiting. The result:
- Idle ping: 20ms
- Under upload load: 150ms to 300ms
This is distinct from ISP congestion - it happens even on fast plans because it is a router buffering issue, not a bandwidth issue. The fix is a router with SQM (Smart Queue Management) or QoS configured to prioritize gaming traffic. OpenWrt with CAKE or FQ-CoDel are the standard solutions for home networks. If you cannot change your router firmware, at minimum limit upload bandwidth usage by other devices while gaming.
Layer 5: Your Home Network Setup
Even with a clean ISP connection and no bufferbloat, your home network can add latency before packets even reach your router.
Wired vs WiFi
Modern WiFi 5 (802.11ac) and WiFi 6 (802.11ax) add only a few milliseconds of raw latency under ideal conditions. The real issues are jitter, retransmissions, airtime contention, and interference - all of which cause the kind of inconsistent, variable lag that feels worse than a higher but stable wired ping.
- WiFi 4 (802.11n) on 2.4GHz: High jitter under interference. Very common on ISP-issued equipment more than 3 years old. In dense residential areas (Manila apartments, Cebu subdivisions), 2.4GHz congestion from neighboring networks adds significant retransmissions.
- WiFi 5 (802.11ac) on 5GHz: Much better. Less interference, lower overhead. Still subject to retransmissions under poor signal.
- WiFi 6 (802.11ax): Best WiFi option. OFDMA reduces airtime contention significantly. Still adds more jitter than wired under load.
- Wired gigabit LAN: Zero airtime contention, deterministic latency, no interference. A 15-meter Cat5e cable costs under 200 pesos and eliminates this entire variable.
If a player reports lag, ask them to test wired first. WiFi issues are frequently misreported as server problems.
Layer 6: Client Hardware and Why Ping Can Lie
Your ping number does not tell the full story. Ping measures raw network round-trip time. What it does not measure is how long the game client takes to process incoming packets and update the world state.
Project Zomboid runs on the CPU. If the CPU is overloaded - low-spec hardware, thermal throttling, or background processes competing - the game loop runs slower. Incoming server updates queue up waiting to be processed, and outgoing player actions sit in a buffer. The result feels exactly like high ping but the network is fine. The bottleneck is the CPU not keeping up with the simulation.
Signs your issue is CPU-bound rather than network-bound:
- Low FPS at the same time as perceived lag (network lag does not reduce FPS; CPU lag does both)
- Lag only in zombie-dense areas, not open fields
- Ping looks normal (30ms to 60ms) but the game feels unresponsive
- Fan at full speed, CPU temperature high (thermal throttling)
Server-Side Settings for Better Responsiveness
These server.ini settings reduce processing load on the server itself:
MaxPlayers=16
SaveWorldEveryMinutes=30
PauseEmpty=trueMaxPlayers: keep this realistic for your RAM allocation. Overfilling causes server-side processing delays that feel like lag for everyone.SaveWorldEveryMinutes=30: frequent auto-saves cause CPU spikes. Every save writes the entire world state to disk. 30 minutes balances data safety and performance.PauseEmpty=true: pauses the simulation when no one is online, preserving CPU and memory.
Server Plan: vCores and RAM
An underpowered server introduces its own latency regardless of network conditions. PZ's main simulation loop is largely single-threaded, so single-core performance matters more than core count:
- vCores: 2 dedicated vCores minimum. One handles the main PZ game loop; the second handles background tasks. Oversold shared CPU environments are the silent killer of server responsiveness.
- RAM: 4GB for vanilla, 6 to 8GB for modded. Running under the RAM limit causes Java garbage collection pressure, showing up as periodic hitches for all players simultaneously.
- Storage: NVMe or SSD. PZ world saves write a lot of data. Spinning disk causes longer save spikes.
For real benchmark data on RAM usage at different player counts and mod loads, see How Much RAM Does a Project Zomboid Server Actually Need?
Scheduled Restarts
Long-running PZ servers may experience increasing memory usage over time due to mods, memory fragmentation, world state growth, and JVM behavior. Scheduled daily restarts at a low-traffic hour (4 AM PHT is standard for PH-focused servers) maintain consistent performance. On Scourge Servers, this is configurable directly from the Restart Addon in the panel.
When a player reports lag, diagnose in order: Are you on WiFi? Run a sustained ping to the actual server IP - what is the jitter and any packet loss? What is your in-game FPS? Those three answers will tell you whether the problem is their home network, their ISP, their hardware, or the actual server.
