Tek video oynarken median frame 16.7ms kaldı. İkinci clip başlayınca aynı sahne 33.3ms'e düştü ve framelerin yüzde 97'si geç kaldı. Sayfada başka hiçbir şey değişmemişti.
Bu ölçümler clodron.com üzerinde Ağustos 2026'da yaptığımız çalışmadan geliyor. Test, ekrandayken X ekseninde translate edilen pinned horizontal track üzerinde, CPU 6x throttle ve 2x device pixel ratio ile yapıldı. İlk şüpheli video decoding idi. İlk şüphe yanlıştı.
Trace JavaScript'i eledi
Tek videolu ve iki videolu run içinde sıfır long task vardı. Main thread event handler, animation loop veya React işiyle bloklanmıyordu. Scroll callback'ten kod çıkarmak, orada harcanmayan zamanı geri getiremezdi.
Belirleyici kontrol daha basitti. Horizontal track'i aynı scroll konumunda durdurduk ve üç clip'i oynar bıraktık. Ölçülebilir maliyet oluşmadı. Aynı medya, aynı viewport ve aynı decoder yükü containing layer hareketsizken normal davranıyordu. Maliyeti değiştiren hareketti.
Bu sonuç araştırmayı dosyalardan composition tarafına taşıdı. Performance trace yalnızca bir hikâyeyi doğruladığı için değil, makul bir hikâyeyi elediği için de değerlidir.
Transform edilen layer video yolunu değiştirir
Section geniş track'i pinliyor ve scroll ilerledikçe X ekseninde taşıyordu. Video normalde ucuz compositor yolundan gidebilir. Onu taşıyan layer sürekli transform edildiğinde bu ucuz yol kullanılamayabilir. Her ek playing clip, hareket eden her frame'e pahalı compositing işi ekler.
Belirleyici ayrım görünür ve gizli video değildi. Değişen layer içindeki playing video idi. Bu, birkaç sabit clip'in neden ucuz, hareketli sahnedeki ikinci clip'in baskı altında neden yıkıcı olduğunu açıklıyor.
JavaScript azaltmanın ölçümü değiştirmemesi de aynı nedenle anlaşılır. Geç frameler, geliştiricinin önce baktığı main-thread işinden sonra oluşuyordu.
Mantıklı iki düzeltme hiçbir şeyi değiştirmedi
will-change hint'ini kaldırdık. Sonuç değişmedi. contain: paint ekledik. Sonuç yine değişmedi. Layer promotion ve paint containment hareketli section'ı etkileyebileceği için ikisi de makul deneydi. Bu sahnedeki video composition yolunu çözmediler.
Browser performance işinin rahatsız edici kısmı budur. Tanıdık optimizasyon mimariyi iyileştirebilir, fakat başarısız trace üzerinde ölçülebilir yarar üretmeyebilir. Before ve after rakamı hareket etmiyorsa final açıklamaya çözüm olarak girmez.
Encode'ları küçültmekle de başlamadık. Dosya boyutu transfer ve startup için önemlidir. Aynı decode edilmiş clip'lerin track durunca neden bedavaya geldiğini açıklamıyordu.
Playback'i viewport'a verin
Çözüm tek playback slot oluşturmaktı. Hareketli section boyunca yalnızca ekranda en çok görünen card oynayabildi. Önceki clip, yenisi başlamadan durdu. Card poster frame ile görsel olarak tamam kalırken compositor transform içinde tek aktif video taşıdı.
Bu policy bütün sayfada 33ms üzerindeki frame oranını yüzde 13.8'den sıfıra indirdi. Performance modelini de açık hale getirdi. Playback artık her card'ın tesadüfi özelliği değildi, viewport'un yönettiği kaynaktı.
Seçimde hysteresis gerekir, yoksa görünürlüğü birbirine yakın iki card slot'u hızla değiştirir. Playback state tab visibility ve reduced-motion tercihine de cevap vermelidir.
Bu hafta hareketli layer'ı teşhis edin
Ek videolar scroll'u bozuyorsa encode değiştirmeden önce stationary control çalıştırın. Aynı scroll konumunda kalın, clip'leri oynatın ve frame timing'i karşılaştırın. Main-thread ile compositor hatasını karıştırmamak için long task'i ayrı kontrol edin.
Sonra transformed layer hareket ederken yalnızca en görünür clip'e playback verin. Sadece section'ı değil bütün sayfayı ölçün. Başarısız deneyleri performance notunda tutun. will-change ve contain: paint değişikliğinin sonuç vermediğini bilmek, sonraki mühendisin aynı makul ama ilgisiz düzeltmeyi tekrarlamasını engeller.
Videolar tek başına fazla ağır değildi. Sayfa compositor'dan birkaç aktif video yüzeyini aynı anda taşımasını istemişti. Kalıcı çözüm ilgisiz kodu törpülemek değil, kıt yolu sınırlamaktı.