Web şişkinliğinin yavaş cihaz kullanan kullanıcılar üzerindeki etkisi

 (danluu.com)
1 puan yazan GN⁺ 2024-03-17 | 1 yorum | WhatsApp'ta paylaş
  • 2017’den bu yana bant genişliğindeki artış, tipik sitelerin aktarım boyutundaki artışı bir ölçüde geride bırakmış olsa da web uygulamalarının CPU gereksinimleri, düşük maliyetli cihazların performansından daha hızlı büyüdü; bu da hızlı internette bile web erişilebilirliğini kötüleştiriyor
  • 1Gbps bağlantıda bile Tecno Spark 8C, Discourse forumlarında tarayıcı çökmesi yaşıyor; Itel P32 üzerinde ise Discourse, Reddit, Shopify, Substack, Wix, Mastodon, Bluesky gibi siteler FAIL durumuna düşüyor veya fiilen kullanılamaz hale geliyor
  • Ölçümler M3 Max, M1 Pro, Chrome’da 10x CPU throttling, Tecno Spark 8C, Itel P32 üzerinde LCP* ve ana iş parçacığı CPU süresi karşılaştırılarak yapıldı; PageSpeed Insights puanlarının gerçek algılanan hızla ilişkisi zayıftı
  • MyBB, phpBB, eski WordPress, HN, danluu.com gibi basit veya eski siteler düşük maliyetli mobil cihazlarda görece iyi çalışırken; Discourse, Medium, Reddit, Substack gibi dinamik yüklemesi yoğun sitelerde kaydırma, arama ve dokunma gecikmeleri belirginleşiyor
  • Nigeria, India, Latin America gibi bölgelerde düşük maliyetli cihaz kullananlar gerçek web kullanıcılarıdır; web yalnızca iOS ve hızlı internet temel alınarak yapılırsa daha az varlıklı kullanıcılar ve düşük özellikli masaüstü kullanıcıları da dışlanır

Bant genişliğinden çok CPU’nun darboğaz olduğu web

  • 2017’de yavaş bağlantılarda web şişkinliği kullanılabilirliği ciddi biçimde zedeliyordu; sonrasında üst seviye bağlantılarda bant genişliği Nielsen ölçütüne göre yılda yaklaşık %50 gibi hızlı bir oranda arttı
  • Yavaş internet kullanan hâlâ çok sayıda kullanıcı var ve modern web’in önemli bir kısmı yavaş bağlantılarda kullanımı zor olmaya devam ediyor; ancak tipik sitelerde bant genişliği artışı, aktarım boyutundaki artışı bir ölçüde geçti
  • Buna karşılık web uygulamalarının CPU performansı gereksinimleri bant genişliği kadar hızlı iyileşmediği için, iyi bir internet bağlantısı olsa bile düşük özellikli cihazlarda web kullanımı zorlaştı
  • Discourse tabanlı “modern” forumlar Tecno Spark 8C üzerinde tarayıcıyı çökertebiliyor; çökmeler arasındaki tepki süresi de 8 MHz 286 ve 1200 baud modemle BBS kullanmaktan daha kötü ölçülüyor
  • Discourse’ta mesaj başlıklarını getiren sıkıştırılmış payload 2.6 MB; geçmişe kıyasla aktarım miktarı 1000x artmış durumda, ancak 1Gbps bağlantıda bu görece hafif kalıyor
  • CPU tarafında ise 8-core (2 1.6 GHz Cortex-A75 / 6 1.6 GHz Cortex-A55) taşıyan Tecno Spark 8C bile Discourse’un altından kalkamıyor; oysa bu CPU, 286dan yaklaşık 100000x daha hızlı

Ölçüm hedefleri ve metrikler

  • Test cihazları: M3 Max Macbook (14-core), M1 Pro Macbook (8-core), Chrome DevTools’ta 10x throttling uygulanmış M3 Max, Tecno Spark 8C, Itel P32
  • Ağ tarafında cihazlara avantaj sağlamak için 1Gbps internet ve yük altında düşük gecikmeli olduğu benchmark’larla görülen bir WiFi yönlendirici kullanıldı
  • Karşılaştırma kapsamına blog/mikroblog, forum ve küçük işletme platformları dahil edildi
    • Blog/mikroblog: danluu.com, Substack, Medium, Ghost, Hugo, Tumblr, Mastodon, Twitter, Threads, Bluesky, Patreon
    • Forum: Discourse, Reddit, Quora, vBulletin, XenForo, phpBB, MyBB
    • Küçük işletme platformları: Wix, Squarespace, Shopify, WordPress
  • Başlıca metrikler aktarım sıkıştırılmış boyutu (wire), sıkıştırma açılmış boyut (raw), LCP* ve ana iş parçacığı CPU süresi
  • LCP*, Chrome’un ölçtüğü Largest Contentful Paint değil; büyük ekran güncellemesi kullanıcı için işe yaramadığında, gerçekten faydalı içeriğin göründüğü anı temel alıyor
  • CPU süresi bir Core Web Vital değil, ancak yavaş cihazlarda kullanıcının hissettiği kullanılabilirlikle güçlü biçimde örtüşen basit bir metrik olarak kullanıldı

Tabloda görülen kullanılabilirlik uçurumu

  • danluu.com ve HN tüm test cihazlarında hızlı çalışıyor
    • danluu.com: 6kB wire / 18kB raw, Tecno Spark 8C üzerinde 0.4s LCP* / 0.3s CPU
    • HN: 11kB wire / 50kB raw, Tecno Spark 8C üzerinde 0.5s LCP* / 0.5s CPU
  • Eski PHP tabanlı forumlar, yavaş cihazlarda modern forumlardan çok daha iyiydi
    • MyBB, Tecno Spark 8C üzerinde 0.8s LCP* / 0.8s CPU
    • phpBB: 1.7s LCP* / 1.5s CPU
    • vBulletin: 4.4s LCP* / 4.8s CPU
    • Discourse: 15s LCP* / 26s CPU; Itel P32 üzerinde FAIL
  • Blog platformlarında da eski WordPress teması, düşük özellikli cihazlarda Medium ve Substack’ten çok daha hızlı
    • WordPress(old), Tecno Spark 8C üzerinde 0.7s LCP* / 1.7s CPU
    • Medium: 2.8s LCP* / 33s CPU
    • Substack: 14s LCP* / 14s CPU
  • Birçok modern site Itel P32 üzerinde başarısız oldu veya fiilen kullanılamaz durumdaydı
    • XenForo, Mastodon, Bluesky, Wix, Substack, Shopify, Discourse, Reddit: FAIL
    • Threads: 28s LCP* / 66s CPU, Twitter: 24s LCP* / 43s CPU, Medium: 3.2s LCP* / 63s CPU
  • 10s+ CPU kullanan sayfalar yükleme sonrasında da kötü bir deneyim yaratıyor
    • Kaydırma birkaç FPS’ye kadar düşüyor; dokunma gecikmesi uzadığı için kullanıcı dokunuşun kaydedilip kaydedilmediğini anlamakta zorlanıyor
    • Tekrar dokunulduğunda ilk dokunuş gecikmeli olarak kaydedildikten sonra ikinci dokunuş beklenmedik bir eylemi tetikleyebiliyor

Gerçek cihazlar ile CPU throttling arasındaki fark

  • Chrome DevTools’un CPU throttling özelliği kullanışlı olsa da gerçek yavaş cihazların sonuçlarını tutarlı biçimde yaklaşık olarak veremiyor
  • M3/10 ile Tecno Spark 8C karşılaştırmasında sitelere göre farklar büyük ölçüde değişti
    • danluu.com ve Ghost bir ölçüde yakınsadı
    • Medium, Substack, Twitter’da Tecno Spark 8C CPU süresi yaklaşık 3x daha yavaştı
    • Reddit ve Discourse yaklaşık 4x daha yavaştı
    • Shopify’da Tecno Spark 8C, M3/10dan tek haneli katlardan daha hızlı sonuç verdi
  • Yavaş sayfalar, cihaz yavaşladıkça kimi zaman süperlineer biçimde daha da yavaşlıyor; bir sayfanın yavaşlığı başka bir sayfanın yavaşlığını iyi tahmin ettirmiyor
  • Discourse, Medium, Reddit M3 ve M1 üzerinde fazla CPU kullanmıyor gibi görünse de Tecno Spark 8C üzerinde en yavaş gruba giriyor
  • Reddit hiçbir etkileşim olmadan beklendiğinde bile ~90% CPU kullanıyor; bu yüzden CPU ∞ olarak gösteriliyor

Eski sitelerin ve basit sayfaların gücü

  • Eski siteler genel olarak en yeni sitelerden daha hızlıydı; 10–20 yıldır görsel olarak pek değişmemiş siteler en hızlı grup içinde yer aldı
  • MyBB, Discourse’a göre M3 üzerinde 3.6x / 5x, Tecno Spark 8C üzerinde 19x / 33x daha hızlı
  • WordPress(old), Medium’a göre M3 Max üzerinde 17.5x / 10x, Tecno Spark 8C üzerinde 4x / 19x daha hızlı ölçüldü
  • Ghost, Medium’dan bir yıl sonra çıkmış modern bir platform olmasına rağmen eski platformlarla rekabet edebilen performans gösteren bir istisna
  • NodeBB de ek testlerde modern forumlar arasında istisnaya yakın
    • M1 üzerinde 0.3s / 0.4s
    • Tecno Spark 8C üzerinde 3.4s / 7.2s
    • Discourse’tan çok daha hızlı; yükleme sonrası kaydırma ve dokunma da temelde çalışıyor

Dinamik yükleme ve metrik optimizasyonunun tuzağı

  • Discourse, Reddit, Substack gibi sayfanın bir kısmını önce yükleyip kalanını dinamik olarak getiren sitelerde gerçek kullanılabilirlik, tablodaki puanlardan daha kötü
  • Yavaş cihazlarda kaydırma mesafesini öngörmek zor; fazla uzağa kaydırılırsa ek yükleme tetiklenip sayfa donabiliyor
  • Geçmişte kaydırılmış içeriği kaldıran sayfalar yavaş cihazlarda fiilen kullanılamaz hale geliyor
  • Dinamik yüklemeli sayfalarda tarayıcının hızlı Ctrl/Command+F aramasını doğrudan kullanmak zorlaşıyor ve özel arama uygulanması gerekiyor
    • Google Docs araması, son birkaç ayda ya da yaklaşık son bir yılda, belge yüklendikten hemen sonra kullanılamayacak kadar geç yükleniyor
    • Discourse araması yavaş veya çok hızlı olmayan cihazlarda hiçbir zaman iyi çalışmadı
  • Teoride başlangıçtaki CPU işi sonraki etkileşimleri hızlandırabilir; ancak test edilen sayfalarda ilk yükleme, sonraki yüklemeler ve yükleme sonrası etkileşimlerin tamamı yavaştı

LCP’nin oyunlaştırılması

  • LCP başlangıçta kullanıcının sayfanın ana içeriğini ne zaman gördüğünü tahmin etmeye yönelik bir metrikti; Chrome ölçümü ise daha çok ekrandaki büyük bir paint’in ne zaman gerçekleştiğine yakın
  • Bazı siteler kullanıcıya fayda sağlamayan büyük bir yükleme ekranını hızlıca göstererek LCPyi düşürüyor, ardından gerçek içeriği küçük güncellemelere bölerek LCPye yakalanmasını engelliyor
  • Discourse, Discourse Splash’ı açıkça devreye aldı ve yavaş yüklemelerde büyük splash ekranıyla LCPyi önemli ölçüde düşürdüğünü belirtti
  • Discourse’un resmi yanıtı, gerçek içerik banner’ı splash’ten büyükse bunun LCP açısından dezavantaj yarattığı yönündeydi
  • Faydalı içerik temelindeki LCP* ile Chrome’un ölçtüğü LCP arasında büyük fark görülen örnekler Wix ve Discourse oldu
    • Wix: M3 üzerinde 6x, M1 üzerinde 12x, Tecno Spark 8C üzerinde 3x
    • Discourse: M3 üzerinde 10x, M1 üzerinde 12x, Tecno Spark 8C üzerinde 4x

Performans optimizasyonunun iş etkisi

  • Büyük şirketlerde site ve uygulama performansını iyileştirmek, A/B testleriyle ölçülebilecek kadar büyük parasal değere sahipti
  • Uzun vadeli holdback’lerde de performans iyileştirmeleri büyüme ve elde tutma oranı üzerinde görece büyük etki yapan müdahaleler olarak göründü
  • Twitter’da kullanıcı gözlemlerine dayalı p99 gecikme süresi yalnızca India ve çeşitli African countries’de değil, United States’ta da yaklaşık 60s idi
  • Her ülkede yavaş cihaz veya bağlantıya sahip yeterince kullanıcı var; sınırlayıcı etken, tüm nüfusun ortalama cihaz/bağlantı dağılımından çok kullanıcı sabrına yakındı
  • Yavaş cihazlarda 60syi 50sye indiren bir iyileştirme, üst seviye cihaz kullanıcıları için de 5syi 4.5sye indirmek gibi etki yaratabilir; gelir, büyüme ve elde tutma üzerinde de etkisi olabilir

Düşük özellikli cihazları dikkate alan tasarım

  • Yavaş cihazlarda veya düşük bant genişlikli/kararsız bağlantılarda, çok sayıda içeriği tek seferde statik sayfa olarak yüklemek genellikle en iyi deneyimi sunuyor
  • Görsellerde uygun width, height, alt özniteliklerinin olması yardımcı oluyor; ancak progressive JPEG özellikle büyük bir fayda sağlamadı
  • Hızlı bağlantıya sahip yavaş cihazlarda hafif statik sayfalar iyi çalışıyor; performans gözetilerek yapılmış hafif dinamik sayfalar da çalışabilir
  • Ağır sayfalarda kaydırma sırasında ek yükleme ve aramayı ele geçirme, kullanılabilir etkileşim modelini bozuyor
  • Substack’te bir yazının LCPsi iPhone 8’de hızlı olabilir; ancak başlığın altına kaydırmak için sonraki sayfa yüklemesini 6s beklemek ve sonrasında da 1s~2s beklemek gereken örnekler var
  • Ters örnek olarak büyük düz HTML sayfaları düşük özellikli cihazlarda da görece iyi çalışıyor
  • Zig standard library documentation başlangıçta tüm kaynak kodunu getirip yerelde render ediyor; buna rağmen Tecno Spark 8C üzerinde 4.7s CPU kullandıktan sonra görece tepkisel kalıyor

Düşük gelirli kullanıcılar ve erişilebilirlik

  • Tecno Spark 8C, Nigeria’da USD 50-60, India’da yaklaşık USD 100-110 seviyesinde bulunabiliyor; ancak bu bölgelerde medyan hane gelirine oranı, ABD’deki mevcut nesil iPhone’dan çok daha yüksek
  • Dünya ölçeğinde Tecno Spark 8C en ucuz cihazlara yakın değil; Itel P32 de gerçekten kullanılan en düşük özellikli cihazlardan daha üst bir grupta
  • Alex Russell’a göre iOS pazar payı India’da %7, Latin America’da %6
  • Windows telemetrisine göre dizüstü ve masaüstü kullanıcılarının çoğunun, en yeni iPhone’dan daha yavaş olması muhtemel düşük özellikli cihazlar kullandığı görülüyor
  • Hükümlü veya denetimli serbestlik kapsamındaki kişilere verilen “lifeline” telefonlar arasında iPhone 6 veya iPhone 8 de var; ancak Itel P32den daha düşük cihazlar da çok ve veri limitleri küçük olduğundan limit bittikten sonra iş arama, sosyal yardım formları doldurma veya Maps kullanımı zorlaşabiliyor
  • Mobil uygulamalar iyi bağlantı varken önceden indirilebilir; ancak web uygulamaları her erişimde birkaç MB sıkıştırılmış JavaScript indirmek zorundaysa sınırlı bağlantılarda kullanılamaz

Deney koşulları ve sınırlamalar

  • Her site, mümkün olan “en temel” deneyim bulunacak şekilde ölçüldü
    • WordPress için mevcut varsayılan tema twentytwentyfour demosu kullanıldı
    • Shopify’da tema listesinde ilk görünen tema kullanıldı
    • Discourse, vBulletin, XenForo, phpBB, MyBB için resmi forum olarak aramada bulunan sayfalar kullanıldı
  • Bu çalışma, veri toplama ve analizi bir gün içinde yapılan kısa bir proje olarak yürütüldü; bu nedenle en yaygın temaları veya gerçek kullanıcı özelleştirmelerinin dağılımını yansıtmaz
  • Dizüstüler yaklaşık %60 pilde, güce bağlı olmadan, 20°C odada ısıl dengeye yakın bırakıldıktan sonra test edildi
  • Mobil cihazlar yaklaşık %100 şarjla, güce bağlı, başka uygulama ve sekme olmadan test edildi
  • Gerçek kullanıcılar aynı cihazlarda daha fazla uygulama ve arka plan işi nedeniyle çoğu zaman daha kötü performans görebilir
  • Boyutlar mobilde ölçüldü; mobil ve masaüstü farklı asset alıyorsa mobil asset boyutlarını yansıtır
  • CPU, ana iş parçacığı CPU süresi olarak ölçüldü; diğer iş parçacığı süreleri kaydedildi ancak metrikte kullanılmadı

Site bazında dikkat çeken örnekler

  • Wix, Tecno Spark 8C üzerinde kaydırmayı düzgün ve kararlı hale getiremiyor; Itel P32 üzerinde deterministik olmayan biçimde başarısız oluyor
  • Patreon’da kaydırma performansı ilk yükleme sayılarından daha kötü; eski yazıları bulmak zor olduğu için ayrı bir Patreon yazı dizini tutulacak kadar rahatsız edici
  • Discourse’ta LCP güçlü biçimde oyunlaştırılmış; M3 Max üzerindeki 1Gbps bağlantıda bile Chrome’un ölçtüğü LCP 115ms iken gerçek içerik 1.1sde yükleniyor
  • Bluesky, Itel P32 üzerinde boş ekran gösteriyor
  • Shopify’ın ilk iki gerçek kullanım örneği, test edilen demo sayfadan ikisi de çok daha yavaştı
  • Tumblr Itel P32 üzerinde JavaScript hatası veriyor; fakat bu sayede sayfa daha hızlı yükleniyor ve kaydırma ile bağlantıya tıklama çalışıyor
  • MyBB mobil sürüm sunmadığı için Google açısından dezavantajlı olabilir; ancak yavaş mobil cihazlarda kaydırma ve dokunma gerçekten iyi çalışıyor
  • Woo Commerce, yalnızca ilk yükleme performansıyla Shopify’la karşılaştırılması zor olduğu ve sepet/checkout gibi gerçek akışları da içeren ayrı bir karşılaştırma gerektiği için tablodan çıkarıldı

İlgili okumalar

1 yorum

 
GN⁺ 2024-03-17
Hacker News yorumları

  • Yakın zamanda nispeten yavaş bir Android telefon kullanınca, sadece metin ve görsellerden oluşuyor gibi görünen web sayfalarının bile yüklenmesinin gerçekten can sıkıcı olabildiğini gördüm
    Asıl darboğaz ağ değil, daha çok izleyiciler, reklamlar ve şişmiş JavaScript tarafı
    Yavaş eski telefonlarda mobil Firefox gibi tam teşekküllü tarayıcıların kendisi fazla ağır kaldığından Firefox Focus gibi hafif bir tarayıcı kullanmak zorunda kalıyorsunuz; ama uzantı kullanılamadığı için uBlock Origin de kullanılamıyor ve web deneyimi daha da kötüleşiyor
    Bazı siteler “standart” bir tarayıcı değilse şikâyet edip kullanılamaz hale geliyor, şirketler de bunun yerine uygulama yüklemeye zorluyor
    Eskiden yavaş cihazlar ve bağlantılar için sadeleştirilmiş sürümler vardı ama giderek kayboluyorlar; muhtemelen JavaScript şişkinliği olmadan reklam ve takip ağlarını döndürmek zor olduğu için

    • Reklam engelleme olmadan modern web’in işe yaramaz olması tam bir çıkmaz
      Rastgele reklamlarla doldurulmuş sonsuz kaydırmalı sayfalarda bu özellikle daha kötü
    • Standart bir tarayıcı kullansanız bile şirketler bazen sizi uygulamaya yöneltmek için web sitelerini bilerek bozuyor
      Yakın tarihli bir örnek olarak Nike web mağazası ödeme sırasında anlamsız bir hata gösterdi ve destek ekibi sadece “uygulamayı deneyin” dedi
      Avrupa’daki havayolu rezervasyon siteleri de büyük şirket web sitelerinin sık sık bozulmasına iyi bir örnek
      2024’te neredeyse sınırsız kaynağa sahip olup da çalışan bir web sitesi yapamamanın markaya olumsuz etkisi olmayacağını düşünmek tuhaf
    • O uygulamaların da büyük ihtimalle onda dokuzu, web sitesinin kısmi bir çevrimdışı kopyasını içeren bir tarayıcı kabuğundan ibaret
    • 10 yıl önce nokia.com ana sitesinin kodunu yazarken, kaynak yüklemenin yavaş olup olmadığını çeşitli şekillerde algılayıp ek özellikleri kapatan bayraklar ayarlamıştım
      Çünkü her ülkede çalışması gerekiyordu ve en yavaş telefonların önemli bir kısmı da o şirketin ürünleriydi
    • Hâlâ 2013 model bir MacBook Pro’m var; Apple’ın yaptığı en iyi klavye olduğu için saklıyorum
      Hızlı değil ama web sitelerini kullanırken zorluk çıkarmıyor; sadece yeni donanım kadar anlık tepki vermiyor, onun dışında gayet kullanılabilir
      Gerçi uBlock Origin kullanıyorum
      Bu Android cihazların gerçekten 11 yıllık giriş seviyesi bir MacBook’tan daha mı zayıf olduğunu merak ediyorum

  • Dan’in, dünyanın dört bir yanındaki eşitsizlik düzeyini hesaba katmak gerektiği yönündeki ana fikrine güçlü biçimde katılıyorum, ama buna Latin Amerika ve Güneydoğu Asya gibi orta gelirli ülkeler de dahil edilmeli
    Örneğin aylık veri kotası tek haneli GB seviyesinde olan ve RAM/CPU’su 10 yıl önceki ABD amiral gemisi cihazları düzeyinde kullanıcılar var
    Discourse’u hiç kullanamayacak durumda değiller ama deneyim büyük ihtimalle rahatsız edecek kadar yavaş
    Dan’in CPU/RAM/diskteki kademeli iyileşmelerin katılımı ölçülebilir şekilde artırdığını düşünmesinin başlıca nedeni de bence bu kullanıcı kitlesi
    Itel P32 gibi en ucuz cihazları kullananlar için Dan’in grafiği, kademeli optimizasyonların pek fayda sağlamadığını gösteriyor
    Yardımcı olabilecek şey; özelliklerden ve şıklıktan feragat edip mümkün olan en ince kodu sunan tamamen farklı bir istemci yapısı, yani alternatif bir hafif/temel mod olabilir
    Ancak bu yaklaşım da pek başarılı olamadı; çünkü ABD’li geliştiricilerin performans uğruna neyin korunup neyin atılacağına yanlış karar vermesi şeklinde aynı empati sorunu yeniden ortaya çıkıyor

    • Bunun neden “alternatif” bir seçenek olması gerektiğini anlamıyorum
      Discourse’un bugün PhpBB veya DLang forumlarına kıyasla gerçekte ne sunduğunu merak ediyorum
      Mobil uyumlu tasarım dışında, normal bir dünyada birkaç satır duyarlı CSS düzenlemesi yeterli olmalı
    • Yoksul bir Güneydoğu Asya ülkesinde yaşıyorum ve küçük veri paketleri kullanan insanlar verimli web siteleri sayesinde veri tasarrufu yapmıyor; her yerde bulunan Wi-Fi’ı kullanıyor
      Aylık 30 GB veri $3.64 ve bu da asgari ücretle yaklaşık 4-6 saatlik işe denk geliyor
      Daha önemli olan, insanların Batı’daki gibi veriyi hoyratça harcamaması
      Kafe, restoran, süpermarket ve AVM’lerin hepsinde ücretsiz Wi-Fi var ve çoğu kişi menüden önce Wi-Fi şifresini soruyor
      Web sitelerinin veriyi fazla hızlı tükettiğini söyleyen birini hiç görmedim ya da duymadım
      Bu, gelişmekte olan ülkelerde gerçekten yaşamayan insanların uydurduğu bir endişe gibi geliyor
      Burada verinin bitme nedeni web şişkinliği değil; TikTok, Instagram ve Facebook’ta video izlenmesi
    • Tüm siteler daha verimli olsa, uzman olmayan kullanıcıların “bilgisayarım yavaşladı, yenisini almalıyım” diye düşündüğü an gecikebilir; böylece dizüstü ve masaüstü PC’lerin ömrü de uzayabilir
      Bilgisayarlarla birlikte kurulu gelen bloatware için de aynı şey geçerli
      Kısa süre önce yeni bir dizüstü aldım ve bana $50’lık bir “ayar çekme” hizmeti teklif edildi
      Yeni araba bayisinin böyle bir teklif yaptığını hayal etmek bile tuhaf
    • Bir önceki nesil iPhone’larda bile bu sitelerin bazıları gerçekten katlanması zor
      Sinyalin kötü olduğu yerlerde sorun 10 kat büyüyor
      Mesele sabit başlıklar ve reklamlar yüzünden ekranın yalnızca üçte birinin görünmesi gibi karmaşık bir arayüz değil; sanki bir tasarım belgesi gibi görünene kadar rastgele bir araya getirilmiş web sitelerinin boyutu
      Düzgün yapılmış olsalar bile zaten şişkin olacak siteler, yavaş internet bağlantılarında kullanılamaz hale geliyor; yavaş donanımı ise hiç saymıyorum bile
      Anlatılan koşullarda internet kullanmanın nasıl hissettirdiğini hayal etmek zor; tek umudum, o insanların kendi bant genişliklerine ve cihazlarına uygun yerel siteler kullanıyor olması ve bizim maruz kaldığımız bu şişkin çöplükle uğraşmamaları
    • Kanada’da yaşıyorum, veri paketim de tek haneli GB seviyesindeydi ve neredeyse 10 yıllık bir amiral gemisi cihazdan yeni yükselttim
      Web sitelerinin çoğu neredeyse işkence gibi

  • Çoğunun suçu sadece yöneticilere ya da korkutucu büyük şirketlere atmasının ilginç olduğunu düşünüyorum
    Verimlilikten pek anlamayan ve anlamaya da niyeti yokmuş gibi görünen yetersiz web programcıları kitlesinin de büyük olduğunu geliştiriciler kabul etmiyor
    Kötü yazılım üretmeye zorlayan yöneticiler ya da şirket elitleri kadar, bu insanlar da bu acıklı web yazılımı dünyasından sorumlu

    • Böyle insanlarla çalıştım
      Ortaya çıkan HTML, CSS, JS çıktısının somut kısımlarını sorduğumda bana başka bir dil konuşuyormuşum gibi bakıyorlardı
      JavaScript framework dünyasından gelmişlerdi ve altında ortaya çıkan sonuç üzerine pek düşünmemişlerdi
      Benim yaklaşımım neredeyse tam tersidir: elde iyi yazılmış bir HTML+CSS+JS sitesine eşdeğer sonucu üreten, bakım yapılabilir asgari kod nedir diye sorarım
      Genelde ortaya çıkan çıktı birkaç basamak daha küçük olur
      Birisi bana 1000 tablo satırını gerçek zamanlı filtrelerken mobilde de hızlı yüklenip iyi çalışmasını nasıl sağladığımı sormuştu; ben de ilk istekte tüm veriyi gönderip filtreye uymayan verileri dinamik olarak gizlediğimi söylemiştim
      Web sunucusunun tek yaptığı aynı önbellek verisini herkese göndermekti ve sitede çalışan JavaScript de bundan ibaretti; bu yüzden onlara tuhaf derecede hızlı görünüyordu
      Onların framework tabanlı çözümündeki benzer tablo satırı HTML’sine baktığınızda, %80’inin hiç kullanılmayan boilerplate olduğunu görüyordunuz
      Web geliştirme fazla katılaştı ve birçok insan web teknolojilerinin özünden fazla uzaklaştı
    • Yaklaşık 5 yıl önce, kırsal Afrika insanlarının ürettiği şeyleri daha kolay satabilmesini sağlayan bir şirkete başvurmuştum
      Ana hedef kullanıcı ABD ya da AB’deyse, düşük donanımı ve kararsız, düşük bant genişlikli-yüksek gecikmeli bağlantıları aşırı optimize etmemek bir ölçüde anlaşılabilir olabilir
      Ama hedef kırsal Afrika ise agresif optimizasyon çok bariz bir gereklilik gibi görünüyordu
      Buna rağmen ana sayfa, CSS ile 500×1000 piksele küçültülmüş 2 MB’lık dev bir görsel yüklüyordu ve sonrası daha da kötüydü
      JS payload boyutunun tam olarak ne kadar olduğunu hatırlamıyorum ama birkaç MB’tı ve uygulamanın büyük bölümü klasik şablon tabanlı backend uygulaması gibi görünmesine rağmen frontend aşırı ağırdı
      Fikir güzel olduğu için başvurdum ama teknoloji korkunçtu
      İlk mülakat aşamasına bile geçemedim, bu yüzden neden böyle olduğunu bilmiyorum ama Batı Avrupalı geliştiricilerin bu konuda ne yaptıklarını gerçekten fark etmemeleri dışında bir açıklama hayal etmek zor
    • “Korkutucu büyük şirketlerde” çalışmış biri olarak, sorumluluğun %100 onlarda olduğunu söyleyebilirim
      Başlangıç noktası geliştirici değil bütçedir
      Üst yönetim teknik konulardan anlamıyorsa ya da mühendislik geçmişi yoksa genelde yeni özelliklere bütçe ayırırlar ama bakım ve teknik borç temizliği için ya çok az bütçe koyarlar ya da hiç koymazlar
      Bakım bütçesi olsa bile neredeyse tamamen daha ucuz yurt dışı bakım ekiplerine verilir
      Özellik ekibi 6 ay boyunca bir özellik geliştirir, sonra yurt dışındaki bakım ekibiyle 1 saatlik bir “KT session” yapıp kodu devreder
      Yurt dışı ekip özelliğe dair biraz bilgi edinir ama mevcut teknik borcu yönetmeye yetecek kadar değil; sadece sistemi ayakta tutacak kadar
      Bu döngü kurum içinde 100 ila 1000 kez tekrarlandığında, aslında en fazla 250 bin satır olması gereken frontend çok kısa sürede 2 milyon satıra çıkar
      Yeni özellik ekibine en iyi mühendisleri koysanız bile artık önceden yapılmış kutunun içinde çalışmak zorundadırlar
      Mockup ile öğeler uyuşmuyorsa sorun mockup’ın hatalı olması, UI kit’in yükseltilmiş olması ya da mevcut UI kit’in refactor edilmesi gerekliliği olabilir ama bunların hiçbiri için bütçe yoktur
      Bu yüzden ekibe, bir component’i kopyalayıp kendi özelliğine uyacak şekilde değiştirmesi söylenir
      Bakım ekibine devrederken de yeni ekip mevcut özellik çalışmalarına dokunmak istemediği için onları olduğu gibi bırakır
      Teknik olmayan yöneticiler farkı anlayamaz ve yıllar içinde ekipler yeni özellikleri uydurabilmek için kopyala-yapıştır yaptıkça kod tabanında “Button” adlı 50’den fazla component oluşur
    • Bu adil değil
      Ekipte verimliliğe önem veren yetkin geliştiriciler varsa ve daha verimli bir siteyi zorlayabilirlerse ya da en baştan daha verimli geliştirebilirlerse sayfa daha iyi olabilir
      Ama çoğunlukla mesele teşviklerdir
      Yönetim umursamıyorsa, programcıların verimliliği artırmak için ekstra zaman harcamak yerine işin yarı sürede çalışır hale gelmesini sağlayıp backlog’u eritmeye yönelmesi daha olasıdır
    • Genelde kötü web yazılımı kötü içerikle birlikte gelir
      Bu yüzden yavaş cihazlar saçmalıkları elemek için harika bir filtredir

  • Kısa süre önce 6 yıllık bir LG amiral gemisi telefondan yeni bir Galaxy’ye geçtim ve performans farkı çok büyüktü
    Böyle olmaması gerekirdi
    Çıkış döneminde son derece üst seviye bir cihazdı, o kadar da eski değil ve hâlâ yeni gibi çalışıyor
    Test için kullandığım Galaxy S9’ların da aynı sıkıntıları yaşadığını görünce bunun sadece benim telefonuma özgü olmadığını anladım
    Keşke testlere Amazon da dahil edilseydi
    Deneyimime göre Amazon web sitesi, 4 yıldan eski mobil cihazlarda en kötülerin de kötüsü
    Nispeten yeni üst düzey mobil donanımlarda bile düzenli kullandığım siteler arasında neredeyse kullanılamaz düzeyde olan tek siteydi

    • 7 yıllık iki Snapdragon 835 cihaz kullandıktan sonra RAM ve güncel Android sürümünün büyük fark yarattığını fark ettim
      LineageOS ile Android 14 yüklediğim OnePlus 5’i günlük cihaz olarak kullanıyorum ve oyun dışındaki işlerde kullanıcı deneyimi gayet yeterli
      Bu telefonda 6 GB RAM var; yani günümüz orta segment cihazlarına bile benziyor
      Tek şikâyetim pilini değiştirmek zorunda kalmam ve telefonu sökmenin uğraştırıcı olması
      Buna karşılık aynı SoC’ye, 4 GB belleğe ve Samsung modifikasyonları içeren stok Android 9’a sahip Galaxy S8 sürekli takılıyor
      2 GB bellek farkı etkili olabilir ama iki telefon arasındaki fark geceyle gündüz kadar büyük
      Bunun nedeni Android 14’ün bellek yönetiminin Android 9’dan çok daha iyi olması mı, yoksa Samsung’un yavaş ve şişkin yazılımının cihazı aşağı çekmesi mi bilmiyorum
      Her hâlükârda, birçok şirketin eski ve düşük segment cihazlarda test yapmaması sinir bozucu
      Dünya çapında kullanıcıları hedefliyorsanız, dünyanın büyük bölümünün en yeni amiral gemilerini kullanmadığını hesaba katmanız gerekir
    • Amazon’da JavaScript’i devre dışı bırakmayı denediniz mi diye merak ediyorum
      Aslında o kadar da kötü çalışmıyor
      Elbette buna mecbur kalınmaması gerektiği konusunda hemfikirim
    • Kısa süre önce Brezilya’daydım ve yeni telefonumu elimden kapıp kaçtılar; şu an yedek olarak 4 yıllık telefonumu kullanıyorum ve dürüst olmak gerekirse pek fark hissetmiyorum
      Ama Firefox’ta tüm reklam engelleyicileri kullanıyorum, muhtemelen bunun yardımı var
    • Bir Palm Phone’um var ve şu noktada onda web’de gezinmek neredeyse imkânsız diyebilirim
    • En güncel iOS 16 kullanan iPhone 8’de Amazon’la ilgili bir sorun yok

  • Günümüzde teknoloji, teknolojiye aşina olmayan insanlara karşı bile fazla kayıtsız.
    Bence bunun en tipik örneği akıllı telefonlar.
    Kendi cihazını neredeyse hiç kullanamayan ya da tamamen bilmeyen gerçekten çok insan gördüm ve onlara her şey kara büyü gibi görünüyor.
    En büyük sorun, görünmediği için yokmuş gibi olan jest navigasyonuna aşırı derecede bağımlı olunması.
    iPhone’daki jest çubuğu bir şekilde keşfedilebilir belki ama bildirim merkezi ya da denetim merkezi diye bir kavramları yok.
    Bu insanlar aptal değil; başka alanlarda benden çok daha iyi olabilirler.
    Teknolojideki sorun çaba eksikliği değil, sezgisel arayüz eksikliğidir.

    • Yeni bir iPhone alınca yanında dokümantasyon gelmemesi de yardımcı olmuyor.
      Gerçek belgelere bakmak için Apple sitesindeki dokümantasyon sayfasına kadar gitmek gerekiyor ve biraz daha derine inince ancak birkaç olası jesti kabaca gösteren bir sayfa çıkıyor.
      Hangi durumda hangi jestin kullanılacağına dair bir cümlelik örnekten fazlası yok.
      Üstelik bu yalnızca işletim sistemi için geçerli.
      Uygulamaların kaç tanesinin, kendi içlerindeki jest özelliklerinin nasıl kullanıldığını açıklayan dokümantasyon sunduğunu merak ediyorum.
      https://support.apple.com/guide/iphone/learn-basic-gestures-...
    • Kasetçaları da kullanamayan, daktiloda da zorlanacak gibi görünen orta yaş ve üzeri insanlar gördüm.
      Oysa onlar bu cihazların etrafında büyüdüler.
      Bu yüzden bunun yalnızca modern teknolojinin suçu olduğunu düşünmüyorum.
    • Dışarıdan bakınca, en azından gösterişli ürünlerdeki arayüzler herkese tek tip uyarlama anlayışıyla tasarlanıyor gibi görünüyor.
      Kullanıcının kendine uygun tasarımı ve etkileşimi seçmesine izin vermek yerine, tasarımcı ya da ürün sahibi tüm kullanıcılar için neyin en iyi olduğunu bildiğini varsayıyor.
    • Jest navigasyonuna aşırı bağımlılık akıllı telefonların genel sorunu değil, iPhone’a özgü bir sorun.
      Android’den geçtikten sonra en büyük şikâyetlerimden biri buydu.
      Geri düğmesi nerede, ana ekran düğmesi nerede, düğmelerin kendisi nerede hiç belli değil.
      Apple’ın minimalizm takıntısından gerçekten nefret ediyorum; bu telefon ölünce Android’e döneceğim.

  • Bu yazı masaüstünde 48 yaşındaki bana göre temelde okunması zor.
    Geliştirici araçlarında body içine aşağıdakileri ekleyince okunabilir hale geliyor:
    font-size: 18px;
    line-height: 1.5em;
    max-width: 38rem;
    Bunu yapınca ne kadar okunaklı ve güzel göründüğü ortaya çıkıyor.
    Dan Luu’nun yazılarını çok okurum ama her seferinde bunları değiştirmek zorunda kalıyorum.
    Cidden söylüyorum, teknisyenler: bir sayfayı daha okunabilir hale getirmek için sadece 64 bayt daha gerekiyor.

    • 53 yaşındayım ve yeni gözlük alma zamanımı en az 5 yıl geçmiş durumdayım; şu an bile gözlüğüm burnumun ucunda duruyor ve bazen açısını bile ayarlamam gerekiyor.
      O sayfa neredeyse sorun değildi; sadece CTRL + ile yakınlaştırmam yetti.
      O sayfa neredeyse saf metin ve neredeyse hiç etkileşim yok.
      Senin kullanım durumuna uygun bir çözümün var, benim de bana uygun çözümüm var.
      Görme engelli okurlar da kendi çözümleriyle erişebilir.
      Kaynak basit olduğu için erişilebilirlik çözümleri de makul ölçüde basit kalıyor.
      Bence Dan etkili iletişim kurmanın yolunu biliyor.
      Mesele bunu sade tutmak ve mutlaka gözle okunacağını varsaymamak.
      Kişi gösterimi kendi amacına göre kolayca değiştirebilir.
      Bu sunum biçimini beğenmiyorsan, okumadan önce kendin yeniden biçimlendirebilirsin.
      Dan, mesajını kolayca işlenebilen sade bir metin akışı olarak sunmuş oluyor.
    • Önerdiğin değişikliğin makul olduğunu düşünüyorum ama Dan Luu bu CSS kurallarını kendisi eklemiş olsaydı, burada düşük yoğunluk ve “aşırı boşluk” diye yakınan yorumlar olurdu.
      Luu’nun okur kitlesi genel olarak daha stilsiz bir yaklaşımı tercih etme eğiliminde olabilir.
    • Katılmıyorum.
      Kullanıcı pencere boyutunu, yazı tipi boyutunu, renkleri vb. kendi tercihine göre değiştirebilir.
      Bunu her dosya için tek tek yapmak gerekmez; birden fazla dosyaya uygulanabilen bir kullanıcı CSS dosyası ekleyip kullanmaya izin verilmelidir.
    • Yazı tipi çok küçükse tarayıcının varsayılan yazı tipi boyutunu değiştirebilirsin.
      Bu ayar Firefox’un varsayılan ayarlar sayfasında var.
      Bir web sitesi font-size: 18px; değerini zorunlu kılarsa, tarayıcıda daha büyük yazı tipi seçmiş kullanıcılar için yazı aslında daha da küçük görünebilir.
    • En az düzeyde CSS eklenmesi gerektiğine katılıyorum.
      Ancak tarayıcının okuma modunu da kullanabilirsin; geliştirici araçlarında birkaç adım dolaşmak yerine tek tık yeter.

  • Bu arada Raspberry Pi 3 üzerinde YouTube kullanılamıyor
    Son 1 yıl içinde bu hale geldi; ondan önce videoları yaklaşık 10~15 FPS ile “izlemek” mümkündü ve atölyede tamir videoları izlemek için yeterliydi
    İlk çıkan model olan Raspberry Pi Model B çıktığında depodaki 1080p videoları oynatabiliyor, YouTube izleyebiliyor ve oyun da çalıştırabiliyordu
    YouTube’un ne yaptığını, diğer servislerin de ne yaptığını bilmiyorum
    İklim krizini ve değişimi ciddiye alıyorsak Google ve Meta’nın bu tür numaralarını çok sıkı incelememiz gerekir
    Kâr uğruna CPU döngülerini yakmak — yani kabaca tahminle reklam teknolojisi yüzünden düşük güçteki cihazlarda YouTube’un bozulması — medyada ağır biçimde eleştirilmeli ve genel kullanıcı deneyimi daha kötü olsa bile daha verimli servisler kullanılmalı

    • Bunun nedeni donanımsal video kod çözme eksikliği olabilir mi diye düşünüyorum
      Pi3’te x264 donanım hızlandırması var ama YouTube bir süredir başka bir kodek kullanmaya başladı
    • YouTube kesinlikle ağırlaşıyor
      2021 model Intel MacBook Air’da bile orta düzey yük altında videolar rastgele takılıyor; eskiden böyle değildi
    • Tüm veriler, istemci cihazların enerji tüketiminin iklim değişikliğine katkı açısından neredeyse yuvarlama hatası seviyesinde olduğunu söylüyor
      İklim değişikliğini çözmek için orayı hedef almak, plastik pipetleri ya da poşetleri yasaklamak kadar anlamsız
    • Sitede gezinmek için Invidious kullanıyorum; gerçek videoyu ise obfuscation’ı çözüp gerçek stream URL’sini alan ve onu VLC’ye veren bir script ile izliyorum
      Bir başka referans noktası olarak, 10 yıl önceki YouTube o donanımda tamamen sorunsuz olurdu
      Suçlu genel web şişkinliği ve daha özelde JS içinde yaygınlaşan soyutlama canavarları
      “İklim krizi”ne hiç inanmayan birine bile zamanla ustalığın ve kalitenin kaybolduğunu, bu karmaşanın da bundan çıktığını söyleyebilirsiniz
      Bu yüzden bunun politik yelpazenin tamamında uzlaşılabilecek bir konu olduğunu düşünüyorum
    • Siteye ve kullanıcıya göre sayfa ağırlığını izleyen, isim verip utandıran bir izleme kuruluşuna ihtiyaç var
      Bu Consumer Reports tarzı olabilir ya da Nielsen reytingleri gibi çalışan bir eklenti olabilir

  • O Discourse tarafındaki kişi, ürünleri gerçekten yaşadığımız dünyaya göre değil, var olmasını istediği dünyaya göre tasarlayan tipik bir örnek
    Qualcomm SoC kullanan cihazlar milyarlarca adet var, olmaya da devam edecek ve üretilip satılacak
    Ne kadar şikâyet edilirse edilsin bu değişmeyecek
    Bunu kabul edip o cihazlara göre optimize etmek gerekiyor
    O cihazların kullanıcıları geliştiricilerin şikâyetleriyle ilgilenmez; yazılım çöküyorsa sadece beceriksiz yazılım geliştiricileri olduğunu düşünürler

    • Ya da “size göre değil” deme yolunu seçebilirsiniz

  • Normalde Dan Luu’nun yazılarını severim ama bu yazının bu kez hedefi ıskaladığını hissettim
    LCP/CPU tablosu iyiydi ama sonrasında koltuk psikolojisine benzer bir yere kayıyor
    Discourse kurucusunun birkaç rastgele yorumunu temel alıp okurdan yazılım mühendislerinin tutumlarını hayal etmesini istiyor
    Hatta Knuth’u bile tek çekirdek ile çok çekirdek performansı ve Itanium hakkındaki sözleri üzerinden aşağı çekmiş; oysa bu eski bir akademik tartışma noktası
    Yazı fazla yumuşak ve internet kavgalarına yaslandığı için sağlam durması zor geliyor

    • Ama gerçekten de böyle bir tutum yok mu?
      Discourse kurucusunun sözleri sadece bunu çok açıklayıcı biçimde ortaya koyuyor
      Son dönemde web kullandıysanız, durum hayal edilemeyecek kadar şişmiş halde; Google artık Largest Contentful Paint 2.4 saniye için hızlı diyebiliyor: https://blog.chromium.org/2020/05/the-science-behind-web-vit...
      Bu 4 yıl önceki veri, yani şimdi daha da kötü olmuş olması çok muhtemel
      Masaüstünde YouTube’un 2.5 MB CSS yüklemesinden, Vercel kurucusunun çok hızlı bir site diye övdüğü şeyin biraz kısıtlama uygulanınca 20 saniyede yüklenmesine kadar uzağa bakmaya gerek yok: https://x.com/dmitriid/status/1735338533303259571
    • Şirketlerin performansı ciddiye aldığını neredeyse hiç görmedim
      Frontend için basit bir API servisi yanıt süresi 500 ms olsa kimse alay etmiyor
      Kendi bulut maliyetinin ne kadar olduğunu bilip buna önem veren mühendis sayısının da ne kadar olduğu şüpheli
    • Knuth’un bir ölçüde haklı olduğunu düşünüyorum
      Bugünkü paralellik, uzmanlaşmış kullanım senaryoları ya da aynı tek iş parçacıklı programı birden çok veri öğesi üzerinde çalıştırma durumları dışında yazılımın %90’ında kullanılmıyor
      Hem programlama dilleri hem de donanım ince taneli paralelliği düzgün desteklemiyor ve klasik yazılımları paralel yaklaşımla hızlandırmak çok zor
    • Bunun nesi tartışma bilmiyorum
      Luu aslında oldukça cömert yazmış
      Knuth daha çok, onlarca yıl süren bedava öğle yemeğinin bittiğinden şikâyet ediyordu
    • Özeti bence oldukça iyi yapmış
      Jeff Atwood sadece örnek olarak seçilmiş
      Çok takipçili, tanınmış web geliştirme düşünce önderleri benzer görüşleri durmadan yayıyor ve pek çok takipçi de bunu olduğu gibi kabul ediyor

  • Tüm şirketler artık bunu umursamayı bıraktı; özellikle de standartların ve iyi web tasarımı pratiklerinin ön saflarında yer alan Google ve Apple gibi şirketler.
    Google kısa süre önce HTML Gmail'i kapattı; bu sürüm 2008 model 256MB RAM'li Android telefonlarda ve eski Firefox'ta bile hızlı ve sorunsuz çalışıyordu.
    Doğal olarak, yeni şişirilmiş JavaScript sürümü tarayıcıyı öldürüyor.
    Uç bir örnek olsa da düşük segment telefonlar 2GB RAM'e sahip ve artık bu tür cihazlarla web'de gezinirken makul performans beklemek zor.
    Mobil web berbat ve bu, kullanıcıları “native” uygulamalara itmek için kasıtlı yapılıyor.
    Çünkü bu, Apple ve Google gibi şirketlerin veri toplamasını ve reklam göstermesini kolaylaştırıyor.

    • Kısmen kesinlikle öyle, ama Amazon ya da Avrupa'nın büyük spor ve outdoor zinciri Decathlon için ne demeli, emin değilim.
      Siteleri mobilde korkunç; Decathlon ise yüksek performanslı olmayan masaüstü bilgisayarlarda bile korkunç.
      Üstelik uygulamalarını da özellikle öne çıkarmıyorlar; bu yüzden buna sadece beceriksizlik demek gerekiyor gibi.
      Geliştiriciler sanki her şeyi yalnızca backbone'a bağlı üst düzey cihazlarda test ediyor.
    • Google Perşembe günü kullanılmaya değer tek “ürününü” bitirdi.
      RIP Google
      Yeni Reddit kullanılamıyor, old Reddit ise fazla eski.
      Twitch, sohbet ve video akışı sorunları yüzünden ancak zar zor kullanılabiliyor.
      Liste uzayıp gidiyor.
      Son formülü zaten elinizdeyse, yapılan her değişiklik iş güvencesi için yapılan kötü bir değişikliğe dönüşür.
      Bir gün bu çamur topunun üzerindeki maymunlar işlerin ve paranın var olmadığını fark edecek, ama o zaman çok geç olacak.
      Hayır, o zaman şimdi.
      RIP Humans