Long Task Nedir?

50 milisaniye eşiğinin önemi

Web performansında uzun görevlerden söz edilirken 50 ms sınırı sık geçer. Bunun nedeni, kullanıcı komutları ile görsel yanıt arasında akıcı sayılan pencerenin çok dar olmasıdır. Tarayıcı bir göreve uzun süre gömüldüğünde, kullanıcı girdisini zamanında işleyemez.

50 ms mutlak sihirli sayı değildir ama pratikte önemli bir eşiktir. Çünkü bu sürenin üstüne çıkan işler tek başına çok büyük görünmese bile art arda geldiğinde main thread blocking etkisi üretmeye başlar. Kullanıcı tarafında hissedilen "takılma" da bu noktada belirginleşir.

Dolayısıyla mesele yalnızca bir görevin kaç milisaniye sürdüğü değil, bu sürenin kullanıcı komutlarına alan bırakıp bırakmadığıdır.

Long Task tek bir büyük görev değildir

Çoğu kişi long task denince aklına devasa tek bir fonksiyon çağrısı getirir. Oysa bazen sorun tek bir dev blok değil, birbirine çok yakın çalışan birkaç yoğun görevin birlikte yarattığı baskıdır. Kullanıcı yine aynı bekleme hissini yaşar.

Yani bazen tek parça ağır iş vardır, bazen de birkaç orta ölçekli iş peş peşe gelip ana iş parçacığını aynı derecede bloke eder. Bu ayrım önemlidir çünkü çözüm yöntemi de değişir.

Eğer sorun tek bloksa parçalamak daha doğrudan işe yarar. Ama problem kümelenmiş görevlerse, hangi adımların gerçekten gerekli olduğunu ve hangilerinin yanlış anda çalıştığını ayırmak gerekir.

Kullanıcı tarafında en sık görülen belirtiler

Long task çoğu zaman "sayfa yavaş" gibi genel bir şikâyetle gelir. Ama altında yatan desen daha spesifiktir: düğmeye basınca kısa bir sessizlik, input alanında takılarak yazma, geç açılan filtre paneli, sıçrayarak ilerleyen scroll ve gecikmeli arayüz tepkileri.

Bu yüzden long task konusu doğrudan INP metriğiyle de ilişkilidir. Çünkü etkileşim anında ana iş parçacığı doluysa, kullanıcı komutu gelmiş olsa bile yeni görsel yanıtı üretmek gecikir. Tarayıcı önce mevcut uzun işi bitirmek zorunda kalır.

Kullanıcının hissettiği problem "sunucu geç cevap verdi" gibi görünse de, gerçek darboğaz çoğu zaman cihazın üzerinde çalışan görev yoğunluğudur.

Long Task üretiminin yaygın kaynakları

İlk sırada ağır JavaScript yürütmesi gelir. Büyük bundle'lar, etkileşim sonrası çalışan yoğun hesaplar, liste dönüştürme, sıralama ve filtreleme maliyetleri burada öne çıkar.

Ama long task yalnızca JavaScript demek değildir. Stil hesaplama, layout zincirleri, yoğun animasyonlar, büyük DOM güncellemeleri ve üçüncü taraf script'ler de aynı baskıyı yaratabilir. Bazen sorun veri miktarından değil, küçük bir işin yanlış yerde tekrarlanmasından doğar.

• Tek seferde çalışan ağır hesaplar: Özellikle filtre ve sıralama akışlarında görülür.
• Gereksiz geniş render alanı: Küçük değişiklik için çok büyük ağaç güncellenir.
• Üçüncü taraf tetiklemeler: Etkileşim anında ek iş yükü bindirir.
• Ölçüm-sonra-stil döngüsü: Tarayıcıyı tekrar tekrar hesap yapmaya iter.

Özellikle CPU süresi yükseldiğinde bu kaynakların toplam etkisi daha da görünür hale gelir.

İlk tespitte odak noktası

İlk adım, gecikmenin hangi akışta hissedildiğini netleştirmektir. Sayfa açılırken mi, kullanıcı tıklayınca mı, yazı girerken mi, yoksa scroll sırasında mı? Long task analizi en hızlı sonucu, belirli bir kullanıcı davranışına bağlandığında verir.

Ardından performans kaydında o davranışın etrafındaki görevleri izlemek gerekir. Sorun tek bir dev blok mu, arka arkaya gelen birkaç görev mi, yoksa üçüncü taraf tetiklenmesi mi? Bu ayrım yapılmadan "kodu küçültelim" demek çoğu zaman yüzeysel kalır.

Eğer ilk yükte de dağınık bir akış görüyorsanız, Speed Index ile long task kümelerini birlikte okumak faydalı olur. Çünkü görsel ilerleme ile ana iş parçacığı yükü zaman zaman aynı problemden beslenir.

Görevleri bölmenin gücü

Çünkü tarayıcıya nefes alma payı bırakır. Tek parça halinde çalışan bir iş, kullanıcı girdisini araya alamaz. Aynı iş daha küçük parçalara bölündüğünde araya yeni kareler, yeni input işleme adımları ve daha hızlı görsel yanıtlar sığabilir.

Bu yaklaşım sadece teknik optimizasyon değil, deneyim optimizasyonudur. Kullanıcı tüm işin bitmesini beklemek yerine önce küçük ama anlamlı tepki görür. Panel kabı açılır, yükleniyor durumu görünür, aktif sekme hemen değişir. Ağır iş arkadan tamamlanırken deneyim daha akıcı hissedilir.

Bu yüzden long task sorununda hedef her zaman "işi tamamen yok etmek" değildir. Bazen en gerçekçi kazanç, işi daha küçük ve daha doğru zamanlanmış parçalara dönüştürmektir.

Beklenen kadar işe yaramayan hamleler

Sadece dosya boyutunu küçültmek her zaman yeterli değildir. Kod daha küçük olsa bile aynı anda, aynı yerde ve aynı yoğunlukta çalışıyorsa kullanıcı yine takılma hissedebilir.

Benzer şekilde, animasyonla gecikmeyi maskelemek de her zaman doğru yol değildir. Görsel geçişler bazen faydalı görünür ama ek iş yükü getirirse long task etkisini daha da artırabilir.

Bazı ekipler yalnızca açılış performansını iyileştirip etkileşim sonrası iş yükünü sabit bırakır. Oysa long task çoğu zaman asıl hasarı kullanım anında verir. Bu yüzden sadece ilk yükteki puanlara bakmak eksik teşhistir.

Tek donma ile sürekli küçük takılmaların farkı

Kullanıcı tarafında ikisi de rahatsız edicidir ama etkileri farklıdır. Tek bir büyük long task çoğu zaman "bir anda dondu" hissi yaratır. Sürekli tekrarlanan orta ölçekli görevler ise arayüzü kronik olarak hantal gösterir. Biri keskin bir kırılma, diğeri ise sürekli bir ağırlık hissi üretir.

Performans incelemesinde yalnızca en büyük bloğu avlamak bu yüzden yeterli değildir. Arka arkaya gelen görevler de kullanıcıyı benzer biçimde yorar. Özellikle scroll, arama ve canlı filtreleme akışlarında küçük gecikmelerin üst üste binmesi toplam deneyimi ciddi biçimde bozar.

Doğru yaklaşım, hangi görevlerin tek seferlik pik yarattığını, hangilerinin ise ritmik biçimde tekrarlandığını ayırmaktır. Çözüm stratejisi bu ayrım üzerinden çok daha net kurulur.

Long task mobil cihazlarda daha sert görünür

Çünkü aynı görev, düşük ve orta seviye telefonlarda daha uzun sürer. Masaüstünde tolere edilen bir blok, mobilde rahatlıkla kullanıcı hissine taşınabilir. İşlemci gücü, termal sınırlamalar ve tarayıcı motorunun cihaz üzerindeki maliyeti burada birlikte çalışır.

Bu yüzden masaüstünde sadece ufak bir pürüz gibi görünen görev zinciri, telefonda input gecikmesi, takılan scroll ve sertleşen arayüz olarak hissedilebilir. Long task analizi yaparken düşük güçlü cihazlarda farklı profil almanın nedeni de budur.

Özellikle etkileşim ağırlıklı arayüzlerde mobil farkı daha da açılır. Filtreleme, sekme geçişi, menü açılışı ve kart listeleme gibi akışlar kısa görünse bile, cihaz sınıfı düştükçe daha belirgin bekleme üretir.

Long task okurken yapılan ölçüm hataları

İlk hata, yalnızca açılış kaydına bakmaktır. Oysa birçok long task sayfa açıldıktan sonra, kullanıcı gerçekten bir şey yapmaya başladığında görünür olur. Bu yüzden etkileşim odaklı kayıt almak şarttır.

İkinci hata, tek bir kayıtta görülen uzun görevi bütün problemin merkezi sanmaktır. Bazen nadir bir görev fazla dikkat çeker, asıl sorun ise sürekli tekrarlanan daha küçük görevlerdir. Kullanıcı açısından ikinci durum daha yorucu olabilir.

Üçüncü hata da cihaz farkını göz ardı etmektir. Tek bir masaüstü profiliyle hareket etmek, mobil tarafta hissedilen gecikmeyi olduğundan hafif gösterebilir. Bu yüzden long task verisi bağlama göre okunmalı, yalnızca ham süre listesi gibi ele alınmamalıdır.

Üçüncü taraf script'lerin özel riski

Çünkü kendi işiniz kadar görünür değildirler ama aynı ana iş parçacığını paylaşırlar. Analiz araçları, test platformları, reklam kodları ve gömülü bileşenler kullanıcı etkileşiminde ek görev başlatabilir. Çoğu zaman ekip bunu doğrudan kendi performans problemi gibi görmez.

Üstelik bu tür kodlar yalnızca açılışta değil, tıklama anında da devreye girebilir. Böylece normalde tolere edilebilir olan bir akış, kullanıcı komutu geldiği anda long task haline dönüşebilir.

Sorunun özellikle kritik hale geldiği anlar

Dashboard, e-ticaret filtreleri, canlı arama, sekmeli arayüzler ve veri yoğun ekranlarda long task etkisi daha yıkıcıdır. Çünkü kullanıcı bir sayfayı sadece görmek için değil, kullanmak için açar. Etkileşim zincirinin her adımı hızlı cevap vermelidir.

Mobil cihazlarda bu etki daha da büyür. Orta sınıf işlemciler aynı işi daha pahalı çalıştırdığı için masaüstünde hafif görünen bloklar telefonda belirgin gecikmeye dönüşebilir. Bu nedenle uzun görevler düşük güçlü cihazlarda ayrıca değerlendirilmelidir.

Kalıcı azaltma için gerekli takip

Long task temizliği tek seferlik iş değildir. Yeni bileşenler, kampanya modülleri, etiketler ve etkileşim akışları eklendikçe ana iş parçacığına yeni görevler yazılır. Eğer ekip bunun kaydını tutmuyorsa, sorun kısa sürede geri döner.

En sağlıklı yaklaşım, kritik kullanıcı akışlarını ayrı ayrı izlemektir. Hangi etkileşimde uzun görev oluşuyor, hangi değişiklik sonrası bu blok dağıldı, hangi cihaz sınıfında etkisi daha sert görünüyor; bu bilgiler tutulduğunda performans kararları daha isabetli olur.

Long task sorunu, "çok iş var" cümlesinden daha spesifik bir şey söyler: tarayıcı yanlış anda çok uzun süre meşgul kalıyor. Bunu çözdüğünüzde hem etkileşim akışı hem de hız algısı belirgin biçimde toparlanır.