Derleyici yaklaşımıyla web performansı: Rich Harris'in görüşü

Bazı web uygulamaların iyi cihazlarda bile neden yavaş hissettirdiği

Kullanıcılar nadiren performansı teknik terimlerle tanımlar. Uygulama ağır geliyor derler. Sayfalar hiçbir şey göstermesi için biraz gecikiyor, butonlar geç tepki veriyor ve menü açmak, arama kutusuna yazmak veya sekme değiştirmek gibi basit eylemler takılıyor.

Belirtiler tanıdık: yavaş ilk yükleme (boş veya yarım oluşmuş UI), gecikmeli etkileşimler (tıklamaların bir duraklama sonrası gerçekleşmesi, titreyen kaydırma) ve form kaydetme veya liste filtreleme gibi anında hissetmesi gereken işlemler sonrası uzun spinner'lar.

Bunun büyük kısmı çalışma zamanı maliyetidir. Basitçe, sayfa yüklendikten sonra tarayıcının uygulamayı kullanılabilir hale getirmek için yapması gereken işler: daha fazla JavaScript indirmek, ayrıştırmak, çalıştırmak, UI oluşturmak, handler'ları bağlamak ve her güncellemede ekstra işler yapmak. Hızlı cihazlarda bile tarayıcıya çok fazla JavaScript aktarırsanız deneyim yavaşlamaya başlar.

Performans problemleri genelde geç ortaya çıkar. Başlangıçta uygulama küçüktür: birkaç ekran, hafif veri, basit UI. Sonra ürün büyür. Pazarlama izleyiciler ekler, tasarım daha zengin bileşenler ekler, ekipler durum, özellikler, bağımlılıklar ve kişiselleştirme ekler. Her değişiklik tek başına zararsız görünür, ama toplam iş birikir.

İşte bu yüzden ekipler derleyici-öncelikli performans fikirlerine bakmaya başlar. Amaç genelde mükemmel puanlar değil. Amaç, uygulamanın her ay daha da yavaşlamasını engelleyecek şekilde göndermeye devam edebilmektir.

Çalışma zamanı-ağır vs derleme-zamanı: temel fikir

Çoğu frontend çerçevesi iki şeyi yapmanıza yardımcı olur: bir uygulama inşa etmek ve UI'yı verilerle eş tutmak. Temel fark ikinci kısmın ne zaman gerçekleştiğidir.

Çalışma zamanı-ağır bir çerçevede işin daha fazlası sayfa yüklendikten sonra tarayıcıda gerçekleşir. Birçok durumu halledebilen genel amaçlı bir runtime gönderirsiniz: değişiklikleri takip etme, neyin güncelleneceğine karar verme ve bu güncellemeleri uygulama. Bu esneklik geliştirme için harika olabilir, ama genellikle UI hazır hissetmeden önce indirilecek, ayrıştırılacak ve çalıştırılacak daha fazla JavaScript anlamına gelir.

Derleme-zamanı optimizasyonunda bu işin daha fazlası build adımına kayar. Tarayıcıya geniş bir kural seti göndermek yerine build aracı bileşenlerinizi analiz eder ve daha doğrudan, uygulamaya özgü kod üretir.

Kafa modeli faydalıdır:

• Çalışma zamanı-ağır, talimatları ve aleti gönderip müşterinin evinde montaj yapmaya benzer.
• Derleme-zamanı, parçaları zaten kesip etiketlenmiş gönderip montajı hızlandırmaya benzer.

Gerçek ürünlerin çoğu bu iki uç arasında bir yerde durur. Derleyici-öncelikli yaklaşımlar hâlâ bazı runtime kodu gönderir (routing, veri getirme, animasyonlar, hata yönetimi). Çalışma zamanı-ağır çerçeveler de istemci işini azaltmak için build-zamanı tekniklerine (minifikasyon, code-splitting, server rendering) dayanır. Pratik soru hangi kampın “doğru” olduğu değil, hangi karışımın ürününüze uyduğu.

Rich Harris ve “framework bir derleyicidir” demesinin önemi

Rich Harris derleyici-öncelikli frontend düşüncesinin en net seslerinden biridir. Argümanı basittir: kullanıcıların daha az kod indirmesi ve tarayıcının daha az iş yapması için işi önceden yapın.

Motivasyon pratiktir. Birçok çalışma zamanı-ağır çerçeve genel amaçlı bir motor gönderir: bileşen mantığı, reaktivite, diffing, zamanlama ve her uygulama için çalışması gereken yardımcılar. Bu esneklik byte ve CPU maliyeti getirir. UI küçükken bile büyük bir runtime için ödeme yapabilirsiniz.

Derleyici yaklaşımı modeli tersine çevirir. Build sırasında derleyici gerçek bileşenlerinize bakar ve ihtiyaç duydukları spesifik DOM güncelleme kodunu üretir. Bir etiket hiç değişmiyorsa düz HTML olur. Sadece bir değer değişiyorsa, sadece o değer için güncelleme yolu üretilir. Genel bir UI makinesi göndermek yerine ürününüze özel çıktıyı gönderirsiniz.

Bu genellikle şu sonucu verir: kullanıcılara gönderilen daha az framework kodu ve her etkileşimde yapılan daha az iş. Ayrıca düşük kaliteli cihazlarda bu fark daha çabuk görünür.

Takaslar hala önemlidir:

• Derleyicinin önceden anlayamadığı bazı dinamik desenler zorlaşır.
• Araç kalitesi daha önemli hale gelir (build hızı, hata ayıklama, source map'ler).
• Ekosistem gelenekleri farklı olabilir; bu işe alım ve yeniden kullanım üzerinde etkili olur.
• Hâlâ daha küçük ve hedefli runtime yardımcılarına ihtiyaç duyabilirsiniz.

Pratik bir kural: UI'nızın çoğu derleme zamanında bilinebiliyorsa derleyici sıkı çıktı üretebilir. UI'nız yüksek derecede dinamik veya eklenti odaklıysa daha ağır bir runtime daha kolay olabilir.

Derleme-zamanı optimizasyonu pratikte neleri iyileştirebilir

Derleme-zamanı optimizasyonu işin nerede yapıldığını değiştirir. Daha fazla karar build sırasında verilir ve tarayıcıya daha az iş kalır.

Gözle görülen bir sonuç daha az JavaScript gönderilmesidir. Daha küçük bundle'lar ağ süresini, ayrıştırma süresini ve sayfanın bir dokunuşa veya tıklamaya yanıt vermesi arasındaki gecikmeyi azaltır. Orta seviye telefonlarda bu birçok ekibin beklediğinden daha önemlidir.

Derleyiciler ayrıca daha doğrudan DOM güncellemeleri üretebilir. Build adımı bir bileşenin yapısını görebildiğinde, her etkileşimde sadece gerçekten değişen DOM düğümlerine dokunan güncelleme kodu üretebilir; bu, soyutlama katmanlarını azaltır. Bu, listeler, tablolar ve formlarda sık gerçekleşen güncellemelerin daha hızlı hissetmesini sağlayabilir.

Build-zamanı analizleri tree-shaking ve dead-code kaldırmayı da güçlendirebilir. Ödül sadece daha küçük dosyalar değildir; tarayıcının yüklemesi ve çalıştırması gereken daha az kod yolu demektir.

Hydration başka bir alandır; build-zamanı seçimleri burada yardımcı olabilir. Hydration, sunucu tarafından render edilmiş bir sayfanın tarayıcıda etkileşimli hale gelmesi adımıdır. Eğer build gerçekten hangi kısımların etkileşim gerektirdiğini işaretleyebiliyorsa, ilk yüklemeye kalan iş azaltılabilir.

Yan etki olarak, derleme genellikle CSS kapsamlamasını da iyileştirir. Build sınıf adlarını yeniden yazabilir, kullanılmayan stilleri kaldırabilir ve bileşenler arası stil sızıntısını azaltabilir. Bu, UI büyüdükçe sürpriz maliyetleri düşürür.

Bir dashboard'u düşünün: filtreler ve büyük bir veri tablosu. Derleyici-öncelikli bir yaklaşım ilk yüklemeyi hafif tutabilir, bir filtre tıklamasından sonra sadece değişen hücreleri güncelleyebilir ve asla etkileşim gerektirmeyen sayfa bölümlerini hydrate etmekten kaçınabilir.

Çalışma zamanı-ağır çerçevelerin hâlâ mantıklı olduğu yerler

Daha büyük bir runtime otomatik olarak kötü değildir. Genelde esneklik satın alır: runtime sırasında karar verilen desenler, çok sayıda üçüncü taraf bileşen ve yıllardır test edilmiş iş akışları.

Çalışma zamanı-ağır çerçeveler UI kurallarının sık değiştiği yerlerde parıldar. Karmaşık yönlendirme, iç içe yerleşimler, zengin formlar ve derin durum modellerine ihtiyacınız varsa olgun bir runtime güvenlik ağı gibi gelebilir.

Runtime kolaylık için ödeme yapar

Runtime, uygulama çalışırken çok şeyi halletmesini istediğinizde yardımcı olur; sadece build sırasında değil. Bu ekiplerin günlük olarak daha hızlı hissetmesini sağlayabilir, hatta ek yük getirse bile.

Yaygın kazanımlar: büyük bir ekosistem, durum ve veri getirme için tanıdık desenler, güçlü geliştirici araçları, eklenti tarzı genişletme kolaylığı ve işe alımda ortak bir yetenek havuzundan hızlı onboarding.

Ekip tanıdıklığı gerçek bir maliyet ve gerçek bir faydadır. Biraz daha yavaş bir çerçeve, ekibinizin güvenle gönderebildiği bir yapı olarak, daha hızlı ama yeniden eğitim, daha sıkı disiplin veya özel araçlar gerektiren daha hızlı bir yaklaşımdan daha iyi olabilir.

Runtime yükü darboğaz değilse

Birçok “yavaş uygulama” şikayeti framework runtime'dan kaynaklanmaz. Sayfanız yavaş API bekliyorsa, ağır görseller, çok fazla font veya üçüncü taraf betikler varsa framework değiştirmek çekirdek sorunu çözmez.

Bir iç admin dashboard'ı genelde daha büyük bir runtime ile bile iyi hissedebilir; çünkü kullanıcılar güçlü cihazlarda olur ve işler tablolar, izinler ve backend sorguları tarafından domine edilir.

Erken aşamada “yeterince hızlı” doğru hedef olabilir. Ürününüzün değerini hala test ediyorsanız, iterasyon hızını yüksek tutun, temel bütçeler belirleyin ve derleyici-öncelikli karmaşıklığı ancak bunun gerçekten fark yaratacağına dair kanıt olduğunda üstlenin.

Performans vs iterasyon hızı: ekiplerde gerçek takas

İterasyon hızı geri bildirim süresidir: birinin bir ekranı değiştirmesi, çalıştırması, neyin bozulduğunu görmesi ve düzeltmesi ne kadar sürer. Bu döngüyü kısa tutan ekipler daha sık gönderir ve daha hızlı öğrenir. Bu yüzden çalışma zamanı-ağır çerçeveler erken aşamada üretken hissettirebilir: tanıdık desenler, hızlı sonuçlar, çok yerleşik davranış.

Performans çalışması çok erken veya çok geniş yapıldığında bu döngüyü yavaşlatır. Her pull request mikro-optimizasyon tartışmalarına dönüşürse ekip risk almaktan vazgeçer. Ürüne dair belirsizken karmaşık bir pipeline inşa ederseniz, insanlar araçlarla uğraşarak kullanıcılarla konuşmak yerine zaman harcar.

Püf noktası “yeterince iyi”nin ne olduğunda uzlaşmak ve o kutu içinde iterasyon yapmaktır. Bir performans bütçesi size bu kutuyu verir. Mesele mükemmel puan peşinde koşmak değil; geliştirmeyi ilerletirken deneyimi koruyacak sınırlar koymaktır.

Pratik bir bütçe şunları içerebilir:

• Orta seviye telefonlarda birkaç saniye içinde sayfa kullanılabilir olsun.
• Rota başına JavaScript ekipçe kabul edilen bir sınırın altında kalsın.
• Ana etkileşimler (ara, sepete ekle, kaydet) hızlı yanıt versin.
• Hiçbir özellik küçük sabit bir miktardan fazla JS veya CSS eklemesin.

Eğer performansı görmezden gelirseniz, genelde ileride ödersiniz. Ürün büyüdüğünde yavaşlık mimari kararlara bağlanır; geç bir yeniden yazım özellikleri dondurmak, ekibi yeniden eğitmek ve eskiden çalışan iş akışlarını kırmak anlamına gelebilir.

Derleyici-öncelikli araçlar bu takası kaydırabilir. Daha uzun build'leri kabul edebilirsiniz ama her cihaz, her ziyaret için yapılan işi azaltırsınız.

Ürün kendini ispat ettikçe bütçeleri yeniden gözden geçirin. Erken aşamada temelleri koruyun. Trafik ve gelir arttıkça bütçeleri sıkılaştırın ve değişikliklerin gerçek metrikleri hareket ettirdiği yerlere yatırım yapın, gurur değil.

Kaybolmadan performansı nasıl ölçersiniz

Performans tartışmaları “hızlı”nın ne olduğunu kimsenin kabul etmemesiyle karışır. Küçük bir metrik seti seçin, yazın ve ortak bir skor tahtası gibi davranın.

Basit bir başlangıç seti:

• İlk yükleme süresi (ilk kullanılabilir ekran)
• Etkileşim gecikmesi (bir dokunuş veya tıklama ne kadar sıkışık hissediyor)
• Bundle boyutu (tarayıcının indirmesi ve ayrıştırması gereken şey)
• API gecikmesi (backend yanıt süresi)

Geliştirici dizüstü bilgisayarıyla değil, temsilci cihazlarda ölçün. Hızlı bir CPU, sıcak önbellek ve yerel sunucu gecikmeleri saklayabilir; orta seviye bir telefonda ve ortalama mobil veride ortaya çıkan gecikmeleri gizleyebilir.

Sayıları somut tutun: gerçek kullanıcılara uyan iki veya üç cihaz seçin ve her seferinde aynı akışı çalıştırın (ana ekran, giriş, yaygın bir görev). Bunu tutarlı şekilde yapın.

Çerçeve değiştirmeden önce bir başlangıç alın. Bugünün build'ini alın, aynı akışlar için rakamları kaydedin ve görünür tutun. Bu başlangıç fotoğrafınızdır.

Performansı tek bir laboratuvar skoruna göre yargılamayın. Lab araçları yardımcı olur, ama yanlış şeyi ödüllendirebilir (mükemmel ilk yükleme) ve kullanıcıların şikayet ettiği şeyi kaçırabilir (takılan menüler, yavaş yazma, ilk ekrandan sonraki gecikmeler).

Sayılar kötüye gittiğinde tahmin yürütmeyin. Ne gönderildiğini, neyin render'ı engellediğini ve zamanın nerede geçtiğini (ağ, JavaScript, veya API) kontrol edin.

Gerçekçi, kullanılabilir bir karar çerçevesi

Framework ve render kararlarını sakin, tekrarlanabilir bir seçim gibi ele alın. Amaç en iyi teknoloji değil; performans ile ekibinizin ihtiyaç duyduğu hız arasında doğru dengeyi bulmaktır.

1. Ürün yüzeylerinizi tanımlayın. Pazarlama sayfaları, giriş yapılmış dashboard, mobil ve iç admin araçlarını ayırın. Her yüzeyin farklı kullanıcıları, cihazları ve beklentileri var.
2. Bir performans bütçesi belirleyin. Orta seviye telefonda ilk yükleme ve bir ana etkileşim (ara, filtre, kaydet) gibi 2–3 sayı seçin ve koruyun.
3. Kısıtlarınızı sıralayın. Şu an için en çok neyin önemli olduğunda dürüst olun: ekip becerileri, teslim tarihler, SEO, veri gizliliği kuralları ve uygulamanın hangi ortamda çalışması gerektiği.
4. Bir yaklaşım seçin. İlk yükleme ve etkileşim hızı pazarlık konusuysa derleyici-öncelikli uygundur. Maksimum esneklik ve hızlı iterasyon gerekliyse çalışma zamanı-öncelikli seçin. Hibrit sıklıkla kazanır: performansa duyarlı yüzeyleri hafif tutun, interaktivitenin değer kattığı yerlerde daha ağır runtime kullanın.
5. İnce bir dilimle doğrulayın, sonra kararı kilitleyin. Gerçek bir kullanıcı akışını baştan sona inşa edin, bütçeye karşı ölçün ve seçiminizi ve nedenini yazılı hale getirin.

Bir ince dilim daima karmaşayı içermeli: gerçek veri, auth ve en yavaş ekranınız.

Prototiplemek için hızlı bir yol arıyorsanız, Koder.ai (koder.ai) sohbet üzerinden web, backend ve mobil uygulama akışları oluşturmanıza ve ardından kaynak kodunu dışa aktarmanıza olanak tanır. Bu, gerçek bir rotayı erken test etmenize ve denemeleri geri almayı kolaylaştıran snapshot'larla deneyleri tersine çevirebilir.

Kararı açık ve basit dille belgeleyin; hangi koşullar altında yeniden gözden geçireceğinizi (trafik artışı, mobil pay, SEO hedefleri) yazın. Bu, ekip değiştiğinde seçimi dayanıklı kılar.

Performans seçimlerinde ekiplerin yaptığı yaygın hatalar

Performans kararları genelde ekipler bugün gördükleri şeyi optimize ettiğinde değil, üç ay sonra kullanıcıların hissedeceğini öngöremediklerinde yanlış gider.

Erken aşamada aşırı optimize etmek bir hata. Ekip günlük değişen bir sayfanın milisaniyelerini azaltmak için günler harcar; o sırada gerçek problem kullanıcıların doğru özellikleri almaması olabilir. Erken dönemde öğrenmeyi hızlandırın; rotalar ve bileşenler stabilize olduğunda daha derin performans çalışması yapın.

Bir diğer hata bundle büyümesini acıya kadar görmezden gelmektir. 200 KB iyi görünürken bir süre sonra birkaç “küçük” ekleme megabaytlarca göndermeye yol açar. Basit bir alışkanlık yardımcı olur: bundle boyutunu zaman içinde takip edin ve ani sıçramaları hata gibi ele alın.

Ekipler her şeyi istemci tarafı render ile yapma eğilimine girer, oysa bazı rotalar çoğunlukla statik olabilir (fiyatlandırma sayfaları, dökümantasyon, onboarding adımları). Bu sayfalar genellikle cihazda çok daha az iş ile sunulabilir.

Daha sessiz bir tuzak, kolaylık için büyük bir UI kütüphanesi eklemektir; bunun prod build maliyetini ölçmeden yapmak tehlikelidir. Kolaylık geçerlidir; ama ekstra JavaScript, ekstra CSS ve orta seviye telefonlarda yavaşlayan etkileşimler için ne ödediğinizi bilerek karar verin.

Son olarak, yaklaşımları net sınırlar koymadan karıştırmak hata ayıklaması zor uygulamalar yaratır. Uygulamanın yarısı derleyici tarafından üretilmiş güncellemelere dayanırken diğer yarısı runtime sihrine güveniyorsa, belirsiz kurallar ve kafa karıştırıcı hatalar ortaya çıkar.

Gerçek ekiplerde işe yarayan birkaç kural:

• Tüm uygulama için değil, ana rotalar için bundle boyutu bütçesi belirleyin.
• Hangi rotaların ilk yüklemede hızlı olması gerektiğine karar verin ve render'ı buna göre tasarlayın.
• Bir kütüphaneyi eklemeden önce prod ağırlığını kontrol edin.
• Sınırları yazılı hale getirin (hangi parçalar derleyici-optimize, hangi parçalar runtime).
• Gerçek kullanıcı verisinden sonra kararları yeniden gözden geçirin, önceden değil.

Gerçekçi bir örnek: SaaS gönderirken kendinizi köşeye sıkıştırmayın

3 kişilik bir ekip bir planlama ve faturalama SaaS'i geliştiriyor. İki yüzü var: halka açık pazarlama sitesi (landing, fiyatlandırma, dökümantasyon) ve kimlik doğrulamaya sahip dashboard (takvim, faturalar, raporlar, ayarlar).

Çalışma zamanı-öncelikli bir yol seçersek, UI değişiklikleri hızlı olduğu için runtime-ağır bir kurulum seçerler. Dashboard büyük bir client-side uygulama olur; yeniden kullanılabilir bileşenler, bir durum kütüphanesi ve zengin etkileşimler var. İterasyon hızlıdır. Zamanla ilk yükleme orta seviye telefonlarda ağır hissetmeye başlar.

Derleyici-öncelikli bir yol seçersek, client JavaScript'ini azaltmak için daha fazla işi build zamanına kaydıran bir framework seçerler. Yaygın akışlar (dashboard açma, sekme değiştirme, arama) daha hızlı hissedilir. Takas: ekip desenler ve araçlar konusunda daha dikkatli olmalı ve bazı kolay runtime hileleri doğrudan kullanmak o kadar basit olmayabilir.

Değişimi tetikleyen nadiren zevktir. Genelde gerçek hayat baskısıdır: yavaş sayfalar kayıtları düşürür, daha fazla kullanıcı düşük kaliteli cihazlarda gelir, kurumsal alıcılar öngörülebilir bütçeler ister, dashboard sürekli açık olduğunda bellek önem kazanır veya destek biletleri gerçek ağlarda yavaşlıktan bahseder.

Hibrit bir seçenek genelde kazanır. Pazarlama sayfalarını hafif tutun (server-rendered veya büyük ölçüde statik, minimal istemci kodu) ve interaktivitenin değeri olduğu dashboard'da daha ağır runtime kabul edin.

Karar adımlarını kullanarak: kritik yolculukları (kayıt, ilk fatura, haftalık raporlama) adlandırırlar, orta seviye bir telefonda ölçerler, bir bütçe koyarlar ve hibrit seçerler. Pazarlama sayfaları ve paylaşılan bileşenler için derleyici-öncelikli varsayılan, sadece deney hızını gerçekten artırdığı yerlerde runtime-ağır kullanılır.

Hızlı kontrol listesi ve ürününüz için sonraki adımlar

Bu fikirleri gerçek kılmanın en kolay yolu kısa bir haftalık döngüdür.

15 dakikalık bir tarama ile başlayın: bundle boyutu artıyor mu, hangi rotalar yavaş hissettiriyor, o rotalardaki en büyük UI parçaları neler (tablolar, grafikler, editörler, haritalar) ve en çok hangi bağımlılıklar ağırlık katıyor. Sonra yığını değiştirmeden çözebileceğiniz bir darboğaz seçin.

Bu hafta için küçük tutun:

• Bir başlangıç ölçümü yapın: en yavaş rotanızın soğuk yüklemesi ve bir yaygın eylem.
• Ürüne uygun tek bir bütçe belirleyin.
• Bir darboğazı düzeltin (bir bağımlılığı kaldırma, rota ayırma, ağır bir bileşeni lazy-load etme, gereksiz render'ları kesme).
• Yeniden ölçün ve ne değiştiğini yazın.

Seçimleri geri alınabilir tutmak için rotalar ve özellikler arasında net sınırlar çizin. Sonradan değiştirebileceğiniz modülleri tercih edin (grafikler, zengin metin editörleri, analitik SDK'ları) ki tüm uygulamayı ellemeye gerek kalmasın.