diff --git a/app/api/files/[...key]/route.ts b/app/api/files/[...key]/route.ts
index 8e4d4f3..ea99102 100644
--- a/app/api/files/[...key]/route.ts
+++ b/app/api/files/[...key]/route.ts
@@ -9,16 +9,14 @@ import path from "path";
 // Target workload: 2–20 s H.264 MP4 clips at 30–50 Mbps = ~7–125 MB per file,
 // 1–3 concurrent reviewers on a LAN/office network.
 //
-// At 8 MB each chunk:
-//   • A 7 MB clip (2 s @ 30 Mbps) arrives in a single request.
-//   • A 75 MB clip (20 s @ 30 Mbps) needs ~10 requests total.
-//   • A 125 MB clip (20 s @ 50 Mbps) needs ~16 requests total.
+// At 2 MB each chunk:
+//   • A 7 MB clip (2 s @ 30 Mbps) arrives in ~4 requests.
+//   • A 75 MB clip (20 s @ 30 Mbps) needs ~38 requests total.
+//   • A 125 MB clip (20 s @ 50 Mbps) needs ~63 requests total.
 //
-// The previous 2 MB cap produced 4× as many HTTP round-trips and 4× as many
-// file-open/stat operations for the same content, with no benefit for this
-// workload. Larger values (16 MB+) offer diminishing returns and increase
-// per-request heap pressure.
-const CHUNK_SIZE = 8 * 1024 * 1024; // 8 MB
+// Keeps time-to-first-frame low: the player can start after the first
+// 2 MB chunk rather than waiting for a full 8 MB download.
+const CHUNK_SIZE = 2 * 1024 * 1024; // 2 MB
 
 // READ_HIGH_WATER_MARK — libuv/Node.js internal read-buffer size per stream.
 //