Tarayıcılar JavaScript zamanlayıcılarını neden throttle ediyor?

• JavaScript’te setTimeout(0) gerçekte anında çalışmaz; çoğu durumda en az 4 ms gecikmeyle çalışır ve bu, kötüye kullanımı önlemek için tarayıcıların koyduğu temel bir sınırlamadır
• Bu kısıtlar, web sitelerinin zamanlayıcıları ölçüsüzce kullanarak pil tüketimine veya etkileşim kalitesinin düşmesine yol açmasını önlemek içindir; pil modunda 16 ms’ye, arka plan sekmelerinde ise 1 saniyeye kadar daha sıkı sınırlar uygulanabilir
• Geliştiriciler, setTimeout sınırlamalarını aşmak için setImmediate, MessageChannel.postMessage, window.postMessage, scheduler.postTask gibi çeşitli alternatif zamanlayıcı API’lerini kullanagelmiştir
• Gerçek benchmark sonuçlarına göre Chrome ve Firefox’ta 4 ms clamping uygulanırken MessageChannel ve scheduler.postTask neredeyse gecikmesiz çalışır; Safari ise setTimeout üzerinde daha agresif kısıtlamalar uygular
• Temelde konu, kullanıcı deneyimini koruma ile geliştirici özgürlüğü arasındaki denge meselesidir; bugün Scheduler API standartlaşmış çözüm olarak öne çıksa da, kötüye kullanım olursa yeni tarayıcı müdahaleleri (intervention) gündeme gelebilir

---

setTimeout kısıtının arka planı

• setTimeout(0) olsa bile kötüye kullanım nedeniyle gerçek çalıştırma çoğu zaman en az 4 ms sonra gerçekleşir

  const start = performance.now()  
  setTimeout(() => {  
    // yaklaşık 4 ms sonra çalışır  
    console.log(performance.now() - start)  
  }, 0)  
  

• Amaç, kontrolsüz yinelenen çağrıları engelleyerek pil tüketimini ve render gecikmesini azaltmaktır
• Bazı tarayıcılar ortama göre bu sınırı daha da sıkılaştırır
  • Pil modu: eski Edge’de 16 ms
  • Arka plan sekmesi: Chrome’da 1 saniyeye kadar gecikme

Diğer zamanlayıcı API’lerinin ortaya çıkışı

• setImmediate: yalnızca IE ve eski Edge’de desteklenir, fiilen terk edilmiştir
• MessageChannel.postMessage: ayrı bir kanal üzerinden event loop’a iş iletir
• window.postMessage: performansı iyidir ama diğer script’lerle çakışma riski vardır
• scheduler.postTask: modern tarayıcılarda desteklenir ve en istikrarlı seçenek olarak değerlendirilir

Benchmark sonuçları (MacBook Pro 2021, 101 tekrar ölçümü)

• Chrome 139: setTimeout 4.2 ms, scheduler.postTask 0 ms
• Firefox 142: setTimeout 4.72 ms, scheduler.postTask 0.01 ms
• Safari 18.4: setTimeout 26.73 ms, MessageChannel 0.52 ms, window.postMessage 0.05 ms

fake-indexeddb vakası

• IndexedDB, event loop’taki microtask’lar biter bitmez transaction’ın otomatik commit edilmesini ister
• Node.js’teki setImmediate idealdir, ancak tarayıcılarda setTimeout verimsiz kalır
• Chrome’da 300 ms süren bir işin tarayıcıda 4.8 saniyeye kadar uzaması sorunu ortaya çıkmıştır
• Çözüm olarak varsayılan tercih scheduler.postTask oldu; uyumluluk için de MessageChannel/window.postMessage fallback olarak benimsendi

Tarayıcı müdahalesi tartışması

• Bir görüşe göre zamanlayıcılar sınırlandırılmalıdır; ancak bu sayede geliştiriciler kendilerini kendi hatalarına karşı koruyabilir
• Diğer görüş ise geliştiricilere ölçüm yapıp optimizasyon uygulayabilecekleri özgürlüğün tanınması gerektiğini savunur
• Sonuçta tarayıcılar, kullanıcı önceliği ilkesi doğrultusunda kötüye kullanımı önlemek için müdahale eder
• Scheduler API, bu iki yaklaşım arasında uzlaşma sunar; geliştiricilere ayrıntılı görev kontrolü verirken tarayıcının render pipeline’ıyla uyumlu olacak şekilde tasarlanmıştır

Geleceğe bakış

• postTask ve postMessage bir süre daha throttle edilmeden kalacak gibi görünüyor
• Ancak user-blocking gibi yüksek önceliklerin kötüye kullanılması durumunda yeniden müdahale gündeme gelebilir
• Uzun vadede scheduler2 benzeri başka bir alternatif API’ye ihtiyaç duyulabilir