Harry Roberts ile Çarpıcı Podcast Bölüm 34: Web Performansının Durumu Ne?

Bu bölümde, Web Performansından bahsediyoruz. 2021'de performans ortamı nasıl görünüyor? Öğrenmek için uzman Harry Roberts ile konuştum.

Notları göster

Harry, Mayıs 2021'de Smashing ile bir Web Performance Masterclass atölyesi yürütüyor. Yayınlandığı sırada, büyük erken indirimler hala mevcut.

• Twitter'da Harry
• Harry'nin danışmanlık sitesi CSS Wizardry
• %15 indirim dahil CSS Sihirbazlığını Hızlandırmak için Yaptığım Her Şey Video Kursu
• Danışmanlar için Sorular e-Kitabı %15 indirim dahil
• Web Vitals için Web.dev kılavuzu
• Drew'un favori OXO GoodGrips yumurta çırpıcısı

Haftalık güncelleme

• Web Tasarım Trendleri 2021: Suzanne Scacca tarafından yazılan Rapor
• Fortune Ikechi tarafından yazılan React Uygulamalarında Grommet Kullanımı
• John Agbanusi tarafından yazılan Ethereum Blockchain İçin Bir Node.js API Nasıl Oluşturulur
• Vitaly Friedman tarafından yazılan SmashingMag Performansını Nasıl Geliştirdik?
• Becca Kennedy tarafından yazılan Serbest Projelere Ne Zaman Hayır Demeli?

Transcript

Drew McLellan: İngiltere'de Leeds'ten bağımsız bir Web Performansı Danışmanı Danışmanıdır. Görevinde, dünyanın en büyük ve en saygın kuruluşlarından bazılarının müşterilerine daha hızlı ve daha güvenilir deneyimler sunmasına yardımcı olur. Davetli bir Google Geliştirici Uzmanı, Bulutlu Medya Geliştirici Uzmanı, ödüllü bir geliştirici ve uluslararası bir konuşmacıdır. Web performansı söz konusu olduğunda işini bildiğini biliyoruz, ancak 14 kolu ve yedi bacağı olduğunu biliyor muydunuz? Smashing arkadaşlarım, lütfen Harry Roberts'a hoş geldiniz. Merhaba Harry, nasılsın?

Harry Roberts: Hey, çok teşekkür ederim. Açıkça 14 kol, yedi bacak… hala her zamanki problemlerini ortaya koyuyor. Pantolon satın almak imkansız.

Drew: Ve bisikletler.

Harry: Evet. Valla benim üç buçuk bisikletim var.

Drew: Bu yüzden bugün seninle konuşmak istedim, ne yazık ki bisikletler hakkında değil, bu başlı başına eğlenceli olsa da. Sizinle web performansı hakkında konuşmak istedim. Bu benim kişisel olarak gerçekten tutkulu olduğum bir konu ama bu endişelendiğim alanlardan biri, gözümü topun üzerinden çekip başka bir işe girdiğimde ve sonra biraz performans çalışması yapmaya geri döndüğümde, Üzerinde çalıştığım bilginin gerçekten hızlı bir şekilde eskimesi konusunda endişeleniyorum… Web performansı bugünlerde algıladığım kadar hızlı hareket ediyor mu?

Harry: Bu… Bunu sadece sana iyi davranmak için söylemiyorum bile, bu çok iyi bir soru çünkü son zamanlarda bunun üzerine epeyce düşünüyorum ve bunun iki yarısı olduğunu söyleyebilirim. Müşterilere söylemeye çalışacağım bir şey, aslında o kadar hızlı hareket etmediğidir. Ağırlıklı olarak, ki bu benim her zaman kullandığım ses kaydı olduğundan, tarayıcıya bahse girebilirsiniz. Tarayıcıların çalışma şekillerini temelden değiştirmelerine gerçekten izin verilmiyor, çünkü elbette, korumaları gereken yirmi yıllık bir miras var. Bu nedenle, genellikle, tarayıcıya bahse girerseniz ve bu dahili öğelerin nasıl çalıştığını biliyorsanız ve asla değişmeyen TCP/IP'yi biliyorsanız… Yani oldukça kesin olarak belirlenmiş bazı şeyler, yani en iyi uygulama, genel olarak her zaman olacaktır. temellerin söz konusu olduğu en iyi uygulama.

Harry: İşin daha ilginç hale geldiği yer… Gittikçe daha fazla gördüğüm şey, site hızı sorunları söz konusu olduğunda kendimizi köşeye sıkıştırıyoruz. Yani aslında kendimiz için birçok sorun yaratıyoruz. Yani gerçekçi olarak bunun anlamı performans… hareketli kale direği, sanırım. Web'in manzarası veya topografyası ne kadar çok değişirse, oluşturulma şekli ve çalışma şeklimiz ne kadar değişirse, kendimize yeni zorluklar çıkarıyoruz. Bu nedenle, istemci üzerinde çok daha fazla çalışma yapmanın ortaya çıkışı, beş yıl önce çözeceğimizden farklı performans sorunları ortaya çıkarır, ancak bu performans sorunları, genel olarak beş yıl içinde değişmeyen tarayıcının dahili bileşenleriyle ilgilidir. Bu yüzden çoğu buna bağlı… Ve kesinlikle bunun iki açık tarafı olduğunu söyleyebilirim… Müşterilerimi tarayıcıya, standartlara dayanmasını tavsiye ediyorum, çünkü bunlar öylece değiştirilemezler, hedef direkleri gerçekten hareket etmez . Ancak elbette bunun daha modern ve belki biraz daha ilginç geliştirme uygulamalarıyla kaynaşması gerekiyor. Bu yüzden... Şey, "Her iki kampta da bir ayak" diyecektim ama yedi ayağımla... dört ve üç yapmam gerekecekti.

Drew: Temellerin değişmediğinden ve TCP/IP gibi şeylerin değişmediğinden bahsettiniz. Değişen şeylerden biri… “Son yıllarda” diyorum, bu aslında şimdi biraz geriye gidiyor, ancak, HTTP, çünkü istemciler ve sunucular arasında iletişim kurmak için bu protokolü HTTP'ye kurduk ve bu değişti ve sonra H2'yi elde ettik, o zaman hepsi ikili ve farklı. Ve bu pek çok şeyi değiştirdi... Performans nedenleriyle, mevcut sınırlamaların bazılarını ortadan kaldırmak içindi, ancak bu bir değişiklikti ve bu protokol için optimize etmemiz gereken yol değişti. Şimdi stabil mi? Yoksa yine değişecek mi, yoksa…

Harry: Yani hakkında daha fazla şey öğrenmek istediğim bir şey, sorunun ikinci yarısı, tekrar değişim. QUIC ve H3'e daha fazla bakmam gerekiyor ama müşterilerim için faydalı olmak için biraz fazla köşede. H2 söz konusu olduğunda, işler oldukça değişti ama gerçekten H2'nin çok fazla yanlış vaat olduğunu düşünüyorum ve aceleyle aşıldığına inanıyorum, ki bu H1'in piyasaya sürüldüğü düşünüldüğünde dikkate değer… Ve yani 1.1, 1997 idi, yani H2 üzerinde çalışmak için çok zamanımız var.

Harry: Sanırım birincil fayda, onu anlayan veya artık uçuş taleplerinde sınırsız olduğunu algılayan web geliştiricileri. Yani bir seferde altı gönderilmiş ve/veya altı uçuş sırasında istek yerine, potansiyel olarak sınırsız, sonsuz. Yine de gerçekten ilginç sorunlar getiriyor çünkü… görsel yardımlar olmadan tanımlamak oldukça zor ama H1 veya H2 çalıştırıyor olsanız da hala aynı miktarda bant genişliğine sahipsiniz, protokol bağlantınızı daha hızlı yapmaz. Bu nedenle, bir kerede 24 dosya isteyerek ağı doldurmanız oldukça olasıdır, ancak bunun için yeterli bant genişliğiniz yoktur. Yani aslında daha hızlı olamazsınız çünkü bir seferde bunun sadece bir kısmını yönetebilirsiniz.

Harry: Ayrıca düşünmen gereken şey dosyaların nasıl tepki verdiği. Ve bu, müşteri atölyeleri ve saire hakkında aldığım bir başka profesyonel ipucu. İnsanlar bir H2 şelalesine bakacaklar ve geleneksel altı gönderme isteği yerine 24'ü görebileceklerini görecekler. 24 istek göndermek aslında o kadar kullanışlı değil. Yararlı olan, bu yanıtların döndürülmesidir. Ve farkedeceğiniz şey, 24 istek gönderebileceğinizdir, bu nedenle şelalenizin sol tarafınız gerçekten güzel ve dik görünüyor, ancak hepsi oldukça kademeli, sıralı bir şekilde geri dönüyor çünkü bant genişliği miktarını sınırlamanız gerekiyor. tüm yanıtı aynı anda yerine getiremezsiniz.

Harry: Diğer bir şey de, eğer tüm yanıtları aynı anda yerine getirseydin, yanıtları bir araya getiriyor olurdun. Böylece her dosyanın ilk %10'unu alırsınız ve bir JavaScript dosyasının sonraki %20'si… %20'si işe yaramaz. JavaScript, %100'ü gelene kadar kullanılamaz. Yani göreceğiniz şey, aslında, cevaba baktığınızda bir H2 şelalesinin kendini gösterme şekli… Zaten daha çok H1'e benziyor, çok daha şaşırtıcı. Yani, H2, bence aşırı satıldı veya belki de mühendisler, ne kadar etkili olabileceğine dair sınırlar olduğuna inanmaya yönlendirilmedi. Çünkü varlıklarını aşırı derecede paylaşan insanları göreceksiniz ve onların yirmisi olabilir… 24 numarayı bırakalım. İki büyük JS dosyası yerine 24 küçük paketiniz olabilir. Hala oldukça sırayla dönecekler. Hepsi aynı anda gelmeyecek çünkü kendinize daha fazla bant genişliği yaratmadınız.

Harry: Ve diğer sorun, her isteğin sabit bir gecikme süresine sahip olmasıdır. Diyelim ki iki büyük dosya istiyorsunuz ve bu yüz milisaniyelik gidiş dönüş ve 250 milisaniyelik indirme, yani iki çarpı 250 milisaniye. 24 isteği çoğaltırsanız, 100 milisaniye olarak belirlediğimiz sabit gecikme süresine sahip olursunuz, yani şimdi 2400 milisaniye gecikme ve 24 kez… 250 milisaniye indirme yerine 25 milisaniyelik indirme diyelim, aslında daha uzun sürüyor çünkü gecikme sabit kalıyor ve siz bu gecikmeyi daha fazla istekle çarpıyorsunuz. Bu yüzden H2'nin bu sihirli mermi olduğunu okuyacak müşteriler göreceğim. Parçalayacaklar... Ah! Geliştirme sürecini basitleştiremediler, paketleme veya birleştirme vb. yapmamıza gerek yok. Ve nihayetinde daha yavaş olacak çünkü isteklerinizi yaymayı başardınız, ki bu söz verilmişti, ancak gecikmeniz sabit kalıyor, bu yüzden aslında tarayıcıda n kat daha fazla gecikmeniz var. Dediğim gibi, gerçekten zor, muhtemelen bunu görseller olmadan açıklamaya çalışmak anlamsız, ancak H2'nin insanların yapmasını umdukları şeyle karşılaştırıldığında kendini nasıl gösterdiği dikkate değer.

Drew: Parçalama işleminde hala bir faydası var mı? 24'ü bitmeden yürütmeye başlayın.

Harry: Ah, dostum, başka bir harika soru. Bu nedenle, kesinlikle, eğer işler doğru giderse ve kendini daha H1 görünümlü bir yanıtta gösterirse, fikir birinci dosya ilk, iki, üç, dört döner ve sonra geldikleri sırayla yürütülebilirler. Böylece, şeylerin aynı anda vardığından emin olarak toplam süreyi kısaltabilirsiniz. Şelale yerine bir web sayfasına bakarsak ve isteklerin aralıklı olduğunu fark ederseniz, bu kötü haber. Çünkü dediğim gibi, bir JavaScript dosyasının %10'u işe yaramaz.

Harry: Sunucu işini düzgün yaparsa ve gönderir, gönderir, gönderir, gönderir, gönderirse, daha hızlı olacaktır. Ve sonra, önbelleğe alma stratejinizin daha ayrıntılı olabileceğinin önemli avantajlarına sahip olursunuz. Tarih seçici widget'ınızdaki yazı tipi boyutunu güncellemeniz gerçekten can sıkıcı olurdu. H1 dünyasında, sitenizin geniş CSS'sinin belki de 200 kilovatlık büstünü önbelleğe almanız gerekir. Oysa şimdi, sadece büstü datepicker.css dosyasını önbelleğe alırsınız. Yani kesinlikle, kesinlikle çok değerli olan bunun gibi yan faydalarımız var.

Drew: Sanırım, sihirli bir şekilde tüm isteklerinizi aynı anda geri aldığınız senaryoda, bu müşteriyi potansiyel olarak boğacaktır, değil mi?

Harry: Evet, potansiyel olarak. Ve sonra gerçekte olan şey, müşterinin bir sürü kaynak planlaması yapması gerekecekti, böylece sonunda elde edeceğiniz şey, tüm yanıtlarınızın aynı anda geri döndüğü bir şelale olacak, o zaman arasında oldukça büyük bir boşluk olacaktı. gelen son yanıt ve yürütme yeteneği. İdeal olarak, JavaScript hakkında konuşurken, tarayıcının hepsini istek sırasında, temelde onları tanımladığınız sırayla istemesini, sunucunun hepsini doğru sırayla döndürmesini istersiniz, böylece tarayıcı çalıştırılabilir. onları doğru sırada. Çünkü, dediğiniz gibi, hepsi aynı anda geri dönerse, aynı anda çalıştırmak için büyük bir JavaScript'iniz olur, ancak yine de planlanması gerekir. Böylece bir dosyanın gelmesi ile kullanışlı hale gelmesi arasında saniyelere kadar şüpheniz olabilir. Yani, aslında, H1… Sanırım ideal olarak, peşinde olduğunuz şey H2 istek zamanlaması, H1 tarzı yanıtlar, o zaman işler geldikçe faydalı hale getirilebilir.

Drew: Yani temelde aşağı kayabilirmişsin gibi görünen bir yanıt şelalesi arıyorsun.

Harry: Evet, aynen.

Drew: Ama paraşüte ihtiyacın yok.

Harry: Evet. Ve bu gerçekten zor… Bunu yüksek sesle söylemek gerçekten önemsiz geliyor, ama H2'nin satılma şeklini göz önünde bulundurursak, bunu oldukça… zorlayıcı bulmuyorum çünkü bu, müvekkilimi kulağa aptalca geliyor… aptal… ama açıklanması oldukça zor onlara… H1'in nasıl çalıştığını düşünürseniz, o kadar da kötü değildi. Ve buna benzeyen yanıtlar alırsak ve "Ah evet, şimdi görebiliyorum". Bunu daha önce performans mühendislerine öğretmek zorunda kaldım. Benim yaptığımı yapan insanlar. Performans mühendislerine, istekler yapıldığında çok fazla aldırmadığımızı, yanıtların ne zaman işe yaradığını gerçekten önemsediğimizi öğretmek zorunda kaldım.

Drew: Özellikle son beş yılda işlerin oldukça hızlı ilerlemesinin nedenlerinden biri, performansın Google için büyük bir konu olmasıdır. Ve Google böyle bir şeyin arkasına ağırlık verdiğinde çekiş kazanıyor. Esasen performans, kullanıcı deneyiminin bir yönüdür, değil mi?

Harry: Oh, demek istediğim… bu gerçekten iyi bir podcast, bunu yarım saat önce düşünüyordum, sana söz veriyorum yarım saat önce bunu düşünüyordum. Performans, uygulanabilir erişilebilirliktir. Birinin içeriğinize erişme şansını garanti ediyor veya artırıyorsunuz ve bence erişilebilirlik her zaman sadece… Ah, ekran okuyucular, değil mi? Görmeyen insanlardır. Bir uygulama yerine bir web sitesi oluşturma kararları… kararlar daha çok bir izleyici kitlesine erişimdir. Yani evet, performans erişilebilirliktir, bu nedenle kullanıcı deneyimidir. Ve bu kullanıcı deneyimi, "Birisi sitenizi bile deneyimleyebilir mi" noktasına kadar gelebilir. Veya “Bu deneyim keyifli miydi? Bir düğmeye tıkladığımda, zamanında yanıt verdi mi?”. Bu yüzden %100 katılıyorum ve bence Google'ın buna ağırlık vermesinin bir çok nedeninin bu olduğunu düşünüyorum, çünkü kullanıcı deneyimini etkiliyor ve biri arama sonuçlarına güvenecekse, o kişiye denemek ve o kişiye bir site vermek istiyoruz. nefret etmeyecekler.

Drew: Ve bu… düşündüğünüz her şey, düşündüğünüz tüm avantajlar, kullanıcı deneyimi, artan etkileşim gibi şeyler, kesinlikle doğru değil mi? Kullanıcıyı yavaş bir deneyimden daha hızlı bir şekilde siteden uzaklaştıran hiçbir şey yoktur. Çok sinir bozucu, değil mi? Navigasyonun o kadar net olmadığını bildiğiniz bir siteyi kullanmak ve bir bağlantıya tıkladığınızda “İstediğim bu mu? Değil mi?" Ve sadece bu tıklamayı yapmanın maliyeti, sadece beklemek ve sonra geri düğmesine tıklamanız gerekiyor ve sonra o beklemek ve bu sadece... pes ediyorsunuz.

Harry: Evet ve mantıklı. Süpermarkete kıstırırsanız ve kesinlikle insanlarla dolu olduğunu görürseniz, minimum düzeyde yaparsınız. Orada çok para harcamayacaksın, içeri ve dışarı “Oh sadece süte ihtiyacım var” gibi. Oysa bu güzel bir deneyimse, “Ah, peki, ben buradayken göreceğim… Ah, evet onlarda… Ah, bunu yarın akşam pişireceğim” ya da her neyse. Bence hala, web'de otuz yıl, web için inşa eden insanlar bile mücadele ediyor, çünkü bu soyut. Gerçek bir mağazada sizi rahatsız edecek şeyin sizi çevrimiçi ortamda rahatsız edeceğini gerçekten düşünmek için mücadele ediyorlar ve oluyor ve istatistikler bunun olduğunu gösteriyor.

Drew: Sanırım çok erken günlerde, 90'ların sonlarını düşünüyorum, burada yaşımı gösteriyorum, web siteleri kurarken performansı çok düşündük ama performansı, insanların bağlantılarının olduğu bir bakış açısıyla düşündük. kullanmak çok yavaştı. Çevirmeli, modemler, telefon hatları üzerinden, 28K, 56K modemlerden bahsediyoruz ve bir noktada, stil görüntülerinde, görüntünün diğer tüm satırlarının bunu vermek için düz bir renkle boş bırakacağı bir eğilim vardı… eğer bunu bir jaluziden resme bakmak gibi düşünebilirsiniz. Ve bunu sıkıştırmaya yardımcı olduğu için yaptık. Çünkü diğer her satır sıkıştırma algoritması-

Harry: Tek bir işaretçiye daraltın.

Duru: Evet. Ve böylece hala elde edebiliyorken görüntü boyutunuzu önemli ölçüde küçülttünüz… Ve bir tasarım öğesi haline geldi. Herkes yapıyordu. Sanırım Jeffrey Zeldman bu yaklaşıma öncülük eden ilk kişilerden biriydi. Ama orada düşündüğümüz şey, öncelikle işleri ne kadar çabuk halledebileceğimizdi. Kullanıcı deneyimi için değil, çünkü düşünmüyorduk… Sanırım kullanıcı deneyimiydi çünkü esasen insanların sitelerimizden ayrılmasını istemiyorduk. Ancak, işleri gerçekten hızlı olacak şekilde optimize etmeyi değil, eğer mantıklıysa, gerçekten yavaş olmalarını önlemeyi düşünüyorduk.

Harry: Evet, evet.

Drew: Sonra, ADSL hatları gibi hızlar daha yaygın hale geldikçe, bu terimleri düşünmeyi bıraktık ve hiç düşünmemeye başladık. Ve şimdi mobil cihazları kullandığımız ve sınırlı bağlantılara ve belki de daha yavaş CPU'lara sahip oldukları bir durumdayız ve bunu tekrar düşünmek zorundayız, ancak bu sefer bir avantaj elde etmek açısından. İşin kullanıcı deneyimi tarafının yanı sıra, maliyetler ve kar etme yeteneği açısından gerçek ticari faydaları olabilir. Değil mi?

Harry: Evet, harika. Demek istediğim, nasıl söyleneceğinden emin değilim. Burada ayağıma ateş etmek değil, denediğim ve müşterilere vurguladığım bir şey, site hızının size rekabet avantajı sağlayacağı, ancak bu size rekabet avantajı sağlayabilecek tek şey. Kimsenin satın almak istemediği bir ürününüz varsa, sitenizin ne kadar hızlı olduğunun bir önemi yoktur. Ve aynı şekilde, biri gerçekten dünyanın en hızlı web sitesini istiyorsa, resimlerinizi silmeniz, CSS'nizi silmeniz, JavaScript'inizi silmeniz ve ardından kaç ürün anlattığınıza bakmanız gerekir, çünkü site hızının faktör olmadığını garanti ederim. Ancak araştırmalar, hızlı olmanın milyonlara varan büyük faydaları olduğunu göstermiştir. Konuştuğumuz sırada bir müşteriyle çalışıyorum. Belirli bir sayfayı bir saniye daha hızlı hale getirebilirlerse veya daha doğrusu boyama için en büyük içerikleri bir saniye daha hızlıysa, bunun yılda 1,8 milyon değerinde olduğunu düşündük, bu da… bu çok büyük bir rakam.

Drew: Bu neredeyse ücretini ödeyecekti.

Harry: Hey! Evet, neredeyse. Onlara “Bakın, iki yıl sonra bunların hepsi ödenecek” dedim. Başıboş olacaksın”. Keşke. Ama evet, müşteriye yönelik yönü… üzgünüm, müşteriye yönelik yönü, eğer bir E-Com siteniz varsa, daha fazla para harcayacaklar. Bir yayıncıysanız, daha fazla makale okuyacaklar veya daha fazla dakika içerik görüntüleyecekler veya ne yaparsanız yapın, ölçtüğünüz KPI'nızdır. Smashing sitesinde olabilir, hemen çıkmamış olabilirler, aslında birkaç makaleye daha tıklamış olabilirler çünkü biz bunu gerçekten kolay ve hızlı hale getirdik. Ve sonra daha hızlı sitelerin çalıştırılması daha ucuzdur. Önbelleğe alma stratejinizi sıraladıysanız, insanları sunucularınızdan uzak tutacaksınız. Varlıklarınızı optimize ederseniz, sunucunuzdan gelmesi gereken her şeyin ağırlığı çok daha az olacaktır. Çalıştırmak çok daha ucuz.

Harry: Mesele şu ki, oraya gitmenin bir bedeli var. Sanırım Scott Jehl muhtemelen en çok söylenenlerden birini söyledi… Ve ilk önce ondan duydum, bu yüzden onu bulduğunu varsayacağım ama “Hızlı bir web sitesi yapmak kolay ama web sitesi yapmak zor” demiş. hızlı". Ve bu çok kısa. Çünkü web performansının yapılacaklar listesinde aşağı itilmesinin nedeni, bir müşteriye “Sitenizi bir saniye daha hızlı yaparsam, yılda fazladan 1,8 milyon kazanacaksınız” diyebilmenizdir veya olabilir "Ödeme sayfanıza Apple Pay'i eklediyseniz, fazladan beş milyon kazanacaksınız." Yani her şey web performansı ile ilgili değil ve belirleyici faktör değil, özellikle E-Com çevrimiçi için çok daha büyük bir stratejinin parçası. Ama kanıt şu ki, perakende müşterilerim, E-Com müşterilerim ile ilk elden ölçtüm. Bunun için durum tam orada, kesinlikle haklısın. Bu rekabet avantajı, size daha fazla para kazandıracak.

Drew: Geçmişte, yine geçmişe dönüyorum, ancak Steve Souders gibi insanlar web performansı hakkında gerçekten yazmaya ve konuşmaya başlayan ilk kişilerden bazılarıydı. Ve Steve gibi insanlar temelde "Tüm kazanımların tarayıcıda olduğu arka uç altyapısını unutun, ön uçta, her şeyin yavaş olduğu yer orası" diyordu. 15 yıl sonra hala böyle mi?

Harry: Evet, evet. Testi o zamanlar ve şimdi arasında yeniden yaptı ve boşluk gerçekten genişledi, bu yüzden aslında kablo üzerinden daha maliyetli. Ancak bunun bir karşılığı var, o da gerçekten kötü bir arka uç performansınız varsa, kapıdan yavaşça çıkarsanız, ön uçta geri çekebileceğiniz çok şey var. Şu anda bir müşterim var, ilk bayt süreleri 1.5 saniye. Bu nedenle asla 1,5 saniyeden daha hızlı render alamayız, bu yüzden bu bir üst sınır olacak. Yine de ön uçta zamanı geri alabiliriz, ancak ilk bayt için gerçekten çok kötü bir zamanınız varsa, arka uç yavaşlamalarınız varsa, ön uç performans çabalarınızın sizi ne kadar hızlı getirebileceğinin bir sınırı vardır. Ama kesinlikle.

Harry: Ancak bu değişiyor çünkü… Hayır, hayır değişmiyor sanırım, daha da kötüye gidiyor. Müşteriye daha fazla baskı yapıyoruz. Eskiden “Sunucunuz bu kadar hızlı ama sonrasında bir sürü soru işaretimiz var” durumuydu. çünkü bunu her zaman duyuyorum “Tüm kullanıcılarımız WiFi üzerinden çalışıyor. Hepsi bizim ofisimizden çalıştığı için masaüstü makineleri var.” Hayır, şimdi hepsi evden çalışıyor. Seçim yapamıyorsun. İşte tüm soru işaretlerinin geldiği yer, yavaşlamaların olduğu, gerçekten kontrol edemediğiniz yer. Bundan sonra, şimdi müşteriye daha fazla yükleme eğiliminde olduğumuz gerçeği. Bununla, istemcideki tüm çalışma sürelerini kastediyorum. Tüm uygulama mantığınızı yine de bir sunucunun dışına taşıdınız, bu nedenle ilk bayta kadar geçen süreniz çok, çok az olmalıdır. Bir CDM'den benimkine bazı paketler gönderme durumu olmalı… ama kendi sunucularınızı belirleyebilmekten, birinin web sitenizi görüntülemeye çalıştıkları aynı makinede Netflix'i çalıştırmadığını ummaya geçtiniz. .

Drew: Bu, siteleri tasarlama şeklimiz hakkında gerçekten iyi bir nokta ve bence geleneksel en iyi uygulama her zaman her türlü tarayıcıyı, her türlü bağlantı hızını, her türlü ekran boyutunu denemeniz ve sağlamanız gerektiğidir, çünkü bunu yapmazsınız. Kullanıcının ne bekleyeceğini bilmiyor. Ve dediğiniz gibi, insanların "Hayır, tüm kullanıcılarımızın iş için verilen masaüstü makinelerinde olduğunu biliyoruz, bu tarayıcıyı çalıştırıyorlar, bu en son sürüm, LAN'a bağlılar" dediği senaryolarınız var. ama sonra şeyler olur. Web uygulamalarına sahip olmanın en büyük yararlarından biri, iş gücümüzü aniden evlerine geri dağıtmak gibi şeyler yapabilmemiz ve onların çalışmaya devam edebilmeleridir, ancak bu yalnızca mühendisliğin kalitesi, o zaman birisinin dönen biri olacak şekilde olması durumunda geçerlidir. Üzerinde IE11 veya her neyse, işin kalitesi orada olsun, bu aslında web'in gerçekten erişilebilir bir ortam olma potansiyelini yerine getirdiği anlamına gelir.

Drew: Dediğiniz gibi, tarayıcıya giderek daha fazla şey aktarma eğilimi var ve tabii o zaman tarayıcı yavaşsa, yavaşlık burada olur. Merak etmelisiniz “Bu iyi bir trend mi? Bunu yapmalı mıyız?” Özellikle düşündüğüm bir sitem var, bunun neredeyse %100 sunucu tarafından oluşturulduğunu fark ettim. Çok az JavaScript var ve ışık hızında. Her gittiğimde “Oh, bu hızlı, bunu kim yazdı?” Diye düşünüyorum. Ve sonra "Ah evet, bendim" fark ediyorum.

Harry: Bunun nedeni localhost'ta olmanız, hızlı hissetmesine şaşmamalı. Bu sizin geliştirici siteniz.

Drew: O zaman, benim günlük işim, tek sayfalık uygulamamızı oluşturuyoruz ve bu durumda sunucunun darboğazı olduğu için işleri sunucudan uzaklaştırıyoruz. Tarayıcıda olmanın daha performanslı olduğunu söyleyebilir misiniz? Yoksa sunucuda olmak için daha mı performanslı? Sadece bir vaka bazında ölçmek ve almakla ilgili bir durum mu?

Harry: Bence bağlamınızın çok, çok, çok farkında olmalısınız ve… bence gerçekten bir hata… insanların “Ah, blogum birinin tarayıcısında görüntülenmeyi hak ediyor” dediği narsisizm. Hemen çıkma oranı %89 olan blogumun tarayıcıda kendi çalışma zamanına ihtiyacı var, çünkü sonraki gezinmelerin hızlı olması için ihtiyacım var, sadece bir… temelde bir veri farkı almak istiyorum.” Zaten kimse bir sonraki makalene tıklamıyor dostum, bir çalışma zamanını borunun aşağısına itme. Bu nedenle, bağlamınızın çok farkında olmanız gerekir.

Harry: Ve biliyorum ki… Jeremy Keith bunu dinliyorsa, muhtemelen beni vuracak, ama diyebilirim ki, bir web sitesi ile bir web uygulaması arasında bir fark var ve bunun tanımı çok, çok bulanık. Ancak, yoğun bir şekilde okuma ve yazma uygulamanız varsa, yani veri girdiğiniz, verileri manipüle ettiğiniz, vb. Temelde sitem bir web uygulaması değil, bir web sitesi, salt okunur, kesinlikle web sitesi kampına koyacağım. Muhasebe yazılımım gibi bir şey bir web uygulamasıdır, diyebilirim ki bir web uygulamasıdır ve biraz önyükleme süresi maliyetine maruz kalmaya hazırım çünkü orada 20 dakika, bir saat, her neyse orada olacağımı biliyorum. Yani biraz bağlama ihtiyacınız var ve yine, belki narsisizm biraz sert ama gerçek bir “Bu gazeteyi müşteri taraflı bir uygulama haline getirmemiz gerekiyor mu?” Hayır, yapmazsın. Hayır, yapmazsın. İnsanlarda reklam engelleyici var, insanlar zaten banliyö gazete sitelerini sevmiyor. Muhtemelen makaleyi okumayacaklar ve Facebook'ta bunun hakkında rant bile etmeyecekler. İstemci tarafından oluşturulan bir uygulama olarak böyle bir şey oluşturmayın, uygun değildir.

Harry: Dolayısıyla, müşteriye daha fazla odaklanmanın kesinlikle yardımcı olacağı bir nokta olduğunu düşünüyorum ve o zaman, çalkantıya karşı daha az hassasiyetiniz olur. Yani herhangi bir iletişim türü, örneğin, bir site için bir an için bir denetim yapıyorum… Bence bu bir E-Com sitesi ama %100 istemcide. JavaScript'i devre dışı bırakırsınız ve hiçbir şey görmezsiniz, yalnızca boş bir div id=“app”. E-Com... herhangi bir konuda çok hassassınız. Ödeme akışınız bile kurnazca yanlış, başka bir yere gidiyorum. Çok yavaş, başka bir yere gidiyorum. Birinin o uygulamaya bir süreliğine katılmaya istekli olduğu bir bağlama sahip değilsiniz.

Harry: Photoshop. Photoshop'u açıyorum ve 45 saniyelik bir açılış ekranı alacağını bilmekten oldukça mutluyum çünkü orada olacağım… temelde 45 saniye, 45 dakikaya değer. Ve tanımlaması çok zor, bu yüzden müşterileri “Lütfen bunu yapmayın” diye ikna etmekte gerçekten zorlanıyorum çünkü “Kullanıcınızın orada ne kadar kalacağını düşünüyorsunuz” diyemem. Hemen çıkma oranınızın %89'u ikinci bir sayfa görüntüleme için optimize etmiyorsa, bunu proxy'den yapabilirsiniz. Önce bu hemen çıkma oranını düşürün. Kesinlikle bir bölünme olduğunu düşünüyorum ama şunu söyleyebilirim ki çoğu insan bu çizginin yanlış tarafındadır. Çoğu insan istemciye orada olmaması gereken şeyleri koyar. Örneğin CNN, bir JavaScript uygulaması tamamen başlatılıncaya kadar CNN web sitesinde tek bir başlığı okuyamazsınız. Sunucunun oluşturduğu tek şey, insanların umursamadığı tek şey olan üstbilgi ve altbilgidir.

Harry: Ve öyle hissediyorum ki... Bu noktaya nasıl geldiğimizi bilmiyorum. Asla daha iyi bir seçenek olmayacak. Etkili bir şekilde işe yaramaz bir sayfa teslim ediyorsunuz ve ardından “Harika, ben gidip bir web uygulaması olan şeyi getireceğim ama onu tarayıcıda çalıştıracağız, sonra gidip bir başlık isteyeceğim” demek zorunda kalırsınız. , o zaman başlayabilirsin… oh, gittin.” Bu beni gerçekten çok rahatsız ediyor.

Harry: Ve bu kimsenin suçu değil, bence bu tür bir JavaScript ekosisteminin emekleme dönemi, etrafındaki hype ve ayrıca, bu kulağa gerçekten sert gelecek ama… Temelde çok fazla safça uygulama. Elbette, Facebook React'i icat etti ve her neyse, onlar için çalışıyor. 10 kişiden 9'u Facebook ölçeğinde çalışmıyorsunuz, 100 kişiden 95'i muhtemelen en zeki Facebook mühendisleri değilsiniz ve bu gerçekten, gerçekten zalimce ve söylemesi korkunç geliyor ama sadece... Hiçbiri bu şeyler varsayılan olarak hızlıdır. Bunları düzeltmek için bunların çok, çok zarif bir uygulamasına ihtiyacınız var.

Harry: Eski sevgilimle bu tartışmayı yapıyordum... 10 yıl önce Sky'da bulunduğum takımın baş mühendislerinden biriydi. Geçen gün onunla bunun hakkında konuşuyordum ve bir istemci tarafından oluşturulan uygulamayı hızlı hale getirmek için çok çalışması gerekiyordu, oysa sunucu tarafından oluşturulan bir uygulamayı hızlı hale getirmek için hiçbir şey yapmanıza gerek yok. Sadece tekrar yavaşlatmamalısın. Ve bir sürü gül renkli camlar, saflık, pazarlama var gibi hissediyorum… Sesim o kadar kasvetli ki, burada gerçekten insanları kaybetmeye başlamadan önce devam etmemiz gerekiyor.

Drew: Bir endüstri olarak bazen kullanıcı deneyiminden çok geliştirici deneyimine odaklanma eğilimimiz olduğunu düşünüyor musunuz?

Harry: Bir bütün olarak değil, ama bence bu sorun beklediğiniz bir yerde ortaya çıkıyor. Eğer eşitsizliğe bakarsanız… Bunu gördünüz mü bilmiyorum ama gördünüz mü, nabzınız üzerinde çok fazla parmağınız var gibi görünüyor, HTTP arşivinin hangi çerçeveler ve çerçeveler hakkındaki verileri arasındaki eşitsizlik. JavaScript kitaplıkları, JavaScript anketinin durumuna karşı vahşi olarak kullanılır, JavaScript anketinin durumunu izlerseniz, "Ah evet, geliştiricilerin %75'i React kullanıyor", sitelerin %5'inden azı React kullanıyor. Bu yüzden, toplu olarak, bunun bir sorun olduğunu düşünmüyorum, ancak beklediğiniz alanlarda, örneğin bir çerçeveye yoğun bağlılık, örneğin geliştirici deneyimi… muhtemelen kullanıcıdan önce müjdelenir. Geliştirici deneyiminin gözden kaçırılmaması gerektiğini düşünüyorum, yani her şeyin bir bakım maliyeti vardır. Senin araban. “Şey, bu anahtarı, o işlevselliği bir tamirciden saklarsak, o tamircinin tamir etmesi çok daha uzun sürer, bu yüzden böyle şeyler yapmayız” diye tasarlanırken bir karar vardı. Dolayısıyla, ergonomi ve kullanılabilirlik arasında bir denge olması gerekiyor, bunun önemli olduğunu düşünüyorum. Öncelikle geliştirici deneyimine odaklanmanın beni şaşırttığını düşünüyorum. Sizin için optimize etmeyin, müşteriniz için optimize edin, müşteriniz size ödeme yapar, tersi olmaz.

Drew: Yani, herkesin “Oh, bunu kullanmalısın, şunu yapmalısın” dediğini gördüğünüzde, çevrimiçi yankı odası gerçekliği tam olarak temsil etmiyor, o zaman bu aslında insanların çok küçük bir yüzdesi.

Harry: Doğru ve bu iyi bir şey, güven verici. Yankı odası… Bu tür bir monokültüre sahip olmak sağlıklı değil, eğer buna öyle demek isterseniz. Ama aynı zamanda… ve bunu birçok çalışmamda, birçok geliştiricide gördüm… Danışman olarak, birçok farklı şirketle çalışıyorum. Birçok insan WordPress'te harika işler yapıyor. Ve WordPress, web'in %24'üne güç sağlar. Ve arka uçta WordPress veya PHP gibi bir şeyde, özel kodda, her ne ise, çalışan böyle bir geliştirici için biraz “Ah, sanırım herkes React kullanıyor ve biz değiliz” gibi hissetmenin oldukça kolay olabileceğini hissediyorum. ” ama aslında hayır. Herkes React'ten bahsediyor ama sen hala akıştasın, hala çoğunluktasın. Sessiz çoğunluğu bulmak oldukça güven verici.

Drew: Statik site oluşturuculara ve ardından siteleri tamamen bir CDN'de barındırmaya yönelik eğilim, bir tür JAMstack yaklaşımı, sanırım yazılım türü siteler yerine bu tür yayıncılık türü sitelerden bahsettiğimizde, sanırım bu gerçekten sağlıklı bir eğilim , düşünür müsünüz?

Harry: Bunu kesinlikle seviyorum. Eskiden SSG'ye "flap dosyası" dediğimizi hatırlıyorsunuz, değil mi?

Duru: Evet.

Harry: Yani, Jekyll'e flep dosyası web sitesi dendiğinde, Jekyll'de CSS Sihirbazlığı kurdum. But now we service our generator, huge, huge fan of that. There's no disadvantage to it really, you pay maybe a slightly larger up front compute cost of pre-compiling the site but then your compute cost is… well, Cloudflare fronts it, right? It's on a CDN so your application servers are largely shielded from that.

Harry: Anything interactive that does need doing can be done on the client or, if you want to get fancy, what one really nice approach, if you are feeling ambitious, is use Edge Side Includes so you can keep your shopping cart server rendered, but at the edge. You can do stuff like that. Tremendous performance benefits there. Not appropriate for a huge swathe of sites, but, like you say, if we're thinking publishing… an E-Com site it wouldn't work, you need realtime stock levels, you need… search that doesn't just… I don't know you just need far more functionality. But yeah, I think the Smashing site, great example, my site is an example, much smaller than Smashing but yeah, SSG, flap filers, I'm really fond of it.

Drew: Could it work going deeper into the JAMstack approach of shifting everything into the client and building an E-Commerce site? I think the Smashing E-Commerce site is essentially using JavaScript in the client and server APIs to do the actual functionality as service functions or what have you.

Harry: Yeah. I've got to admit, I haven't done any stuff with serverless. But yeah, that hybrid approach works. Perhaps my E-Commerce example was a bit clunky because you could get a hybrid between statically rendering a lot of the stuff, because most things on an E-Com site don't really change. You filter what you can do on the client. Search, a little more difficult, stock levels does need to go back to an API somewhere, but yeah you could do a hybrid for a definite, for an E-Com site.

Drew: Okay, so then it's just down to monitoring all those performance metrics again, really caring about the network, about latency, about all these sorts of things, because you're then leaning on the network a lot more to fetch all those individual bits of data. It hosts a new set of problems.

Harry: Yeah, I mean you kind of… I wouldn't say “Robbing Peter to pay Paul” but you are going to have to keep an eye on other things elsewhere. I've not got fully to the bottom of it, before anyone tweets it at us, but a client recently moved to an E-Commerce client. I worked with them two years ago and that site was already pretty fast. It was built on… I can't remember which E-Com platform, it was .net, hosted on IIS, server rendered, obviously, and it was really fast because of that. It was great and we just wanted to maintain, maybe find a couple of hundred milliseconds here and there, but really good. Half way through last year, they moved to client side React for key pages. PP… product details page, product listing page, and stuff just got marketable slower lower, much slower. To the point they got back in touch needing help again.

Harry: And one of the interesting things I spotted when they were putting a case for “We need to actually revert this”. I was thinking about all the…what's slower, obviously it's slower, how could doing more work ever be faster, blah blah blah. One of their own bullet points in the audit was: based on projections, their yearly hosting costs have gone up by a factor of 10 times. Because all of a sudden they've gone from having one application server and a database to having loads of different gateways, loads of different APIs, loads of different microservers they're calling on. It increased the surface area of their application massively. And the basic reason for this, I'll tell you exactly why this happened. The developer, it was a very small team, the developer who decided “I'm going to use React because it seems like fun” didn't do any business analysis. It was never expected of them to actually put forward a case of how much is it going to cost the dude, how much is it going to return, what's the maintenance cost of this?

Harry: And that's a thing I come up against really frequently in my work and it's never the developer's fault. It's usually because the business keeps financials away from the engineering team. If your engineers don't know the cost or value of their work then they're not informed to make those decisions so this guy was never to know that that was going to be the outcome. But yeah, interestingly, moving to a more microservice-y approach… And this is an outlier, and I'm not going to say that that 10 times figure is typical, it definitely seems atypical, but it's true that there is at least one incident I'm aware of when moving to this approach, because they just had to use more providers. It 10x'ed their… there's your 10 times engineer, increased hosting by 10 times.

Drew: I mean, it's an important point, isn't it? Before starting out down any particular road with architectural changes and things about doing your research and asking the right questions. If you were going to embark on some big changes, say you've got a really old website and you're going to structure it and you want it to be really fast and you're making all your technology choices, I mean it pays, doesn't it, to talk to different people in the business to find out what they want to be doing. What sort of questions should you be asking other people in the business as a web developer or as a performance engineer? Who should you be talking to you and what should you be asking them?

Harry: I've got a really annoying answer to the “Who should you be talking to?” And the answer is everyone should be available to you. And it will depend on the kind of business, but you should be able to speak to marketing “Hey, look, we're using this AB testing tool. How much does that cost as a year and how much do you think it nets as a year?” And that developer should feel comfortable. I'm not saying developers need to change their attitude, what I mean is the company should make the developers able to ask those kind of questions. How much does Optimizely cost as a year? Right, well that seems like a lot, does it make that much in return? Okay, whatever we can make a decision based on that. That's who you should be talking to and then questions you should ask, it should be things like…

Harry: The amount of companies I work will, they won't give their own developers to Google Analytics. How are you meant to build a website if you don't know who you're building it for? So the question should be… I work a lot with E-Com clients so every developer should things like “What is our average order value? What is our conversion rate? What is our revenue, how much do we make?” These things mean that you can at least understand that “Oh, people spend a lot of money on this website and I'm responsible for a big chunk of that and I need to take that responsibility.”

Harry: Beyond that, other things are hard to put into context, so for me, one of things that I, as a consultant, so this is very different to an engineer in the business, I need to know how sensitive you are to performance. So if a client gives me the average order value, monthly traffic, and their conversion rate, I can work out how much 100 milliseconds, 500 a second will save them a year, or return them, just based on those three numbers I can work out roughly “Well a second's worth 1.8 mil”. It's a lot harder for someone in the business to get all the back information because as a performance engineer it's second nature to me. But if you can work that kind of stuff out, it unlocks a load of doors. Okay, well if a second's work this much to us, I need to make sure that I never lose a second and if I can, gain a second back. And that will inform a lot of things going forward. A lot of these developers are kept quite siloed. “Oh well, you don't need to know about business stuff, just shut up and type”.

Drew: I've heard you say, it is quite a nice soundbite, that nobody wants a faster website.

Harry: Yeah.

Drew: What do you mean by that?

Harry: Well it kind of comes back to, I think I've mentioned it already in the podcast, that if my clients truly wanted the world's fastest website, they would allow me to go in and delete all their JavaScript, all their CSS, all their images. Give that customer a Times New Roman stack.

Harry: But fast for fast sake is… not chasing the wrong thing but you need to know what fast means to you, because, I see it all the time with clients. There's a point at which you can stop. You might find that your customer's only so sensitive to web perf that it might mean that getting a First Contentful Paint from four seconds to two seconds might give you a 10% increase in revenue, but getting from that two to a one, might only give you a 1% increase. It's still twice as fast, but you get minimal gains. So what I need to do with my clients is work out “How sensitive are you? When can we take our foot off the gas?” And also, like I said, towards the top of the show… You need to have a product that people want to buy.

Harry: If people don't want to buy your product, it doesn't matter how quickly you show them it, it'll just disgust them faster, I guess. Is your checkout flow really, really, really seamless on mobile, for example. So there's a number of factors. For me, and my clients, it'll be working out a sweet spot, to also working out “If getting from here to here is going to make you 1.8 mil a year, I can find you that second for a fraction of that cost.” If you want me to get you an additional second on top of that, it's going to get a lot harder. So my cost to you will probably go up, and that won't be an extra 1.8, because it's not lineal, you don't get 1.8 mil for every one second.

Harry: It will tail off at some point. And clients will get to a point where… they'll still be making gains but it might be a case of your engineering effort doubles, meaning your returns halve, you can still be in the green, hopefully it doesn't get more expensive and you're losing money on performance, but there's a point where you need to slow down. And that's usually things that I help clients find out because otherwise they will just keep chasing speed, speed, speed and get a bit blinkered.

Drew: Yeah, it is sort of diminishing returns, isn't it?

Harry: That's what I was look for-

Duru: Evet.

Harry: … diminishing returns, that's exactly it. Yeah, exactly.

Drew: And in terms of knowing where to focus your effort… Say you've got the bulk of your users, 80% of your users are getting a response within two, three seconds, and then you've got 20% who may be in the long-tail that might end up with responses five, ten seconds. Is it better to focus on that 80% where the work's really hard, or is it better to focus on the 20% that's super slow, where the work might be easier, but it's only 20%. How do you balance those sorts of things?

Harry: Drew, can you write all podcast questions for everyone else? This is so good. Well, a bit of a shout out to Tim Kadlec, he's done great talks on this very topic and he calls it “The Long-Tail of Web Performance” so anyone listening who wants to look at that, Tim's done a lot of good firsthand work there. The 80, 20, let's just take those as good example figures, by the time you're dealing with the 80th percentile, you're definitely in the edge cases. All your crooks and web file data is based around 75th percentile. I think there's a lot of value investing in that top 20th percentile, the worst 20%. Several reasons for this.

Harry: First thing I'm going to start with is one of the most beautiful, succinct soundbites I've ever heard. And the guy who told me it, I can guarantee, did not mean it to be this impactful. I was 15 years old and I was studying product design, GCSE. Finally, a project, it was a bar stool so it was a good sign of things to come. And we were talking about how you design furniture. And my teacher basically said… I don't know if I should… I'm going to say his name, Mr. Brocklesby.

Harry: Saygı duydu ama çocuklardan biriydi, hepimiz onu gerçekten sevdik. Ama her boyutta devasaydı. 1.80 boyunda, ama sadece iri bir delikanlı. Büyük, büyük, büyük, büyük adam. Ve bize dedi ki, "Bir kapı aralığı tasarlayacak olsanız, ortalama bir insan için tasarlar mıydınız?" Ve 15 yaşındaki beyinler “Pekala evet, eğer herkes kabaca 5'9 ise evet” diyor. “Eh, hemen, Harry o kapıyı kullanamaz” gibiydi. Ortalama bir insan için tasarım yapmıyorsunuz, çoğu insan için faydalı olmasını istediğiniz için ekstremiteler için tasarlıyorsunuz. Sıradan bir insan için bir sandalye tasarladıysanız, Bay Brocklesby buna sığmazdı. Bu yüzden bana gerçekten, gerçekten bir yaştan, ekstremitelerinize kadar tasarım öğretti.

Harry: Ve bunun web performansında gerçekten ilginç hale geldiği yer… Bir merdiven hayal ederseniz ve merdiveni bot tarafından alırsanız… Tamam, az önce metaforumun olabileceğini fark ettim… Buna sadık kalacağım ve buna gülebilirsiniz. ben sonra. Bir merdiven hayal edin ve merdiveni alt basamaklardan yukarı kaldırın. Ve bu senin en kötü deneyimlerin. Kaldırmak için merdivenin en alt basamağını seçiyorsunuz. Tüm merdiven onunla birlikte gelir, yükselen bir gelgit tüm tekneleri yüzer gibi. Metaforun işe yaramamasının nedeni, en üst basamaktan bir merdiven alırsanız, her şey aynı zamanda kalkar, o bir merdivendir. Ve ben onu bir ip merdivene çevirsem bile bu metafor işe yaramıyor, çünkü o zaman bir ip merdiven, alt basamağı kaldırıyorsun ve hiçbir şey olmuyor ama… Demek istediğim, eğer 90. yüzdelik dilimin için deneyimi geliştirebiliyorsan, bunu yüzde 10'luk dilimin için kaldır, değil mi?

Harry: Ve bu yüzden müşterilere söylüyorum, bana "Ah, pekâlâ, kullanıcılarımızın çoğu iPhone'larda 4G kullanıyor" gibi şeyler söyleyecekler, bu yüzden tamam, tamam ve Android'de 3G'yi test etmeye başlıyoruz, "Hayır, hayır, kullanıcılarımızın çoğu iPhone” tamam… bu, ortalama kullanıcınızın daha iyi bir deneyim yaşayacağı anlamına gelir, ancak zaten 50. yüzdelik dilimde olmayan herkes daha da geride kalır. Bu yüzden beklentileri oldukça düşük tutarak çıtayı kendiniz için oldukça yükseğe ayarlayın.

Harry: Üzgünüm, kısa sorulara gerçekten uzun cevaplar vermek gibi gerçekten kötü bir alışkanlığım var. Ama bu harika bir soruydu ve özetlemek gerekirse, o uzun kuyruğa bakmak istediğinize kesinlikle %100 katılıyorum, buna bakmak istiyorsunuz… 80. yüzdelik diliminiz çünkü tüm deneyimleri üzerine alırsanız siteye gidin ve medyana bakın ve medyanı iyileştirin, bu zaten oldukça memnun olan insanlar için daha da iyi hale getirdiğiniz anlamına gelir. İnsanların %50'sinin etkin bir şekilde görmezden gelinmesi doğru bir yaklaşım değildir. Ve evet, her zaman Bay Brocklesby'nin bana “Ortalama insan için tasarım yapma çünkü o zaman Harry kapıyı kullanamaz” dediği geliyor. Oh, dinleyen varsa, 193 santimetreyim, yani oldukça zayıfım, işte bu.

Drew: Ve tüm o kollar ve bacaklar.

Harry: Evet. Burada da iyi bir tane daha var. Kız arkadaşım kısa süre önce iOS'taki erişilebilirlik ayarlarını keşfetti… bu yüzden herkesin telefonu sessizde, değil mi? Aslında kimsenin çalan bir telefonu yok, herkes sessizde. “Ah, bilirsiniz, bir mesaj aldığınızda flaş yanıp sönecek şekilde ayarlayabilirsiniz. Ve telefonun arkasına iki kez dokunursanız, bir ekran görüntüsü alacak.” Ve bunlar erişilebilirlik ayarlarıdır, bunlar o 95. yüzdelik dilim için tasarlanmıştır. Yine de “Oh, bu gerçekten faydalı” gibi.

Harry: OXO Good Grips ile aynı. OXO Good Grips, mutfak gereçleri. Mutfakta onlardan bir sürü var. Kurucunun karısının artriti olduğu ve daha rahat mutfak eşyaları yapmak istediği için tasarlandılar. Yüzde 99'luk dilim için tasarladı, çoğu insanda artrit yok. Ama yüzde 99'luk dilim için tasarlarken, istemeden de olsa herkes "Aman Tanrım, neden tüm patates soyucuları bu kadar rahat olamıyor?" der. Ve gerçekten, gerçekten gibi hissediyorum… İyi hissettiren veya anekdotlardan hoşlandığım, bu tür senaryolarda anlatmayı seviyorum. Ama evet, onlar için optimize ederseniz... Yükselen bir gelgit tüm tekneleri yüzer ve bu nedenle insanların kuyruk ucunu optimize eder ve bunun üzerinde çok daha mutlu müşteriler yakalarsınız.

Drew: OXO Good Grips manuel el çırpıcınız var mı?

Harry: İstemiyorum . Değilim, iyi mi?

Drew: Şuna bak. Bu çok iyi.

Harry: Geçen hafta parmağımın ucunu kesen OXO Good Grips mandolin dilimleyicim var.

Drew: Evet, onlardan birine yaklaşmayacağım.

Harry: Evet, bu benim kendi aptal hatam.

Drew: Bu uzun kuyruk için catering ile ilgili kendi deneyimimden başka bir örnek, şu anda üzerinde çalıştığım projede, uzun kuyruk tam sonunda, en yavaş performansa sahip insanlar var, ama eğer bu müşterilerin kim olduğuna bakarsanız, onlar işletme için en değerli müşterilerdir-

Harry: Tamam.

Drew: … çünkü onlar en fazla veriye sahip en büyük kuruluşlar.

Harry: Doğru.

Drew: Ve böylece darboğazlarla karşılaşıyorlar çünkü bir sayfada görüntülenecek çok fazla veri var ve bu kullanım durumuna yardımcı olmak için bu sayfaların biraz yeniden düzenlenmesi gerekiyor. Yani en yavaş deneyime sahipler ve iş söz konusu olduğunda, en çok parayı ödüyorlar ve gerçekten hızlı bir deneyime sahip olan tüm insanlardan çok daha fazla fark yaratıyorlar çünkü onlar ücretsiz kullanıcılar. küçük miktarda veri ve hepsi güzel çalışıyor ve hızlı.

Harry: Bu büyüleyici bir boyut, değil mi? Aslında, ben de benzer bir şey yaşadım… Az önce tanımladığınız gibi iş etkisine yakın hiçbir yerde olmadım, ancak birkaç yıl önce bir müşteriyle çalıştım ve CEO'ları, siteleri yavaş olduğu için iletişime geçti. Yavaş, yavaş, yavaş gibi. Aynı zamanda gerçekten iyi bir adam, o sadece gerçekten iyi bir dünya adamı, ama akıl hocalığı yapıyor, tıpkı zenginler gibi. Ve en son iPhone'a sahip, bunu karşılayabilir. O bir multimilyoner, zamanının çoğunu geldiği yer olan Avustralya ile şu anda ikamet ettiği Estonya arasında uçarak geçiriyor.

Harry: Ve birinci sınıf uçuyor, tabii ki öyle. Ancak bu, zamanının çoğunu güzel, parlak iPhone 12 Pro Max'te, her ne olursa olsun, uçak WiFi'sinde olduğu anlamına geliyor, ki bu korkunç. Ve sitenin sahibi olduğu ve onu çok kullandığı bu gerçekten şaşırtıcı yan yanaydı, kullandığı bir site. Ve onu zorluyordu... Yani kolayca en zengin müşterileri CEO'larıydı. Ve Joe Public'ten daha kötü bir bağlantıya sahip olduğu bu tuhaf ayrıcalıklı konumda çünkü Singapur'un yukarısında bir yerde bir Quantas uçuşunda boynuna şampanya dökülüyor ve mücadele ediyor. Ve bu gerçekten büyüleyici bir içgörüydü… Ah evet, çünkü yüzde 95'iniz var, temelde her iki yöne de gidebilir.

Drew: Evet, bir elinizde bir kadeh şampanya olan bir siteyi kullanmak için optimizasyon yapmaya başladığınızda, “Belki biraz yoldan çıkmaya başlıyoruz” diye düşünüyorsunuz.

Harry: Evet, aynen.

Drew: Performans ölçümü hakkında biraz konuştuk ve performans çalışmasıyla ilgili kendi deneyimime göre, sorunların nerede olduğunu belirleyebilmeniz için her şeyi ölçmek gerçekten çok önemlidir. farklı bir şey yaratıyorsunuz ve ne kadar fark yaratıyorsunuz. Sitelerimizin performansını ölçmek için nasıl bir yol izlemeliyiz? Hangi araçları kullanabiliriz ve nereden başlamalıyız?

Harry: Ah dostum, başka bir harika soru. Dolayısıyla, site hızını sabitlemek için ne kadar zaman, kaynak ve eğilim olduğuna bağlı olarak bir dizi yanıt var. Bu yüzden, müşteriyle deneyeceğim ve yapacağım şey… Bazı kullanıma hazır metrikler gerçekten çok iyi. Yükleme süresi, artık bunu umursamayın. Çok, çok, çok… Yani, yükleme süreniz 120 saniyeyse bu iyi bir proxy, tahmin ediyorum çok hızlı bir web siteniz yok, ancak çok belirsiz ve gerçekten müşteriye dönük değil. Aslında hayati bilgilerin doğru yönde gerçekten iyi bir adım olduğunu düşünüyorum çünkü kullanıcı deneyimini ölçüyorlar ancak teknik girdilere dayanıyorlar. En Büyük İçerikli Boyama, görsel olarak gerçekten güzel bir şeydir, ancak oradaki teknik şeyler kritik yolunuzun engelini kaldırır, kahraman görsellerinin hızlı bir şekilde ulaştığından emin olun ve web yazı tipi stratejinizin düzgün olduğundan emin olun. Bu metriklerde teknik bir alt akıntı var. Bunlar raftan gerçekten çok iyi.

Harry: Ancak, müşterilerin zamanı varsa, genellikle zamanıdır, çünkü verileri yakalamak istiyorsunuz ancak verileri gerçekten yakalamak için zamana ihtiyacınız var. Bu yüzden müşterilerle yapmaya çalıştığım şey, "Bak, önümüzdeki üç ay boyunca birlikte çalışamayız çünkü tamamen doluyum. Yani, yapabileceğimiz şey, sizi gerçekten hızlı bir şekilde Speedcurve'un ücretsiz bir deneme sürümüyle ayarlamak, bazı özel metrikler oluşturmak”, yani bir yayıncı müşteri, bir gazete için, “Şu anda gazetenin manşeti ne kadar hızlıydı?” makale işlendi mi? Makalenin ana görseli ne kadar çabuk işlendi?” Bir E-Ticaret müşterisi için ölçmek istiyorum, çünkü açıkçası pasif olarak başlat gibi şeyleri ölçüyorsunuz. Herhangi bir performans izleme yazılımını kullanmaya başladığınızda, gerçek performans ölçümlerinizi ücretsiz olarak yakalarsınız. Yani First Contentful Paint'iniz, En Büyük İçerikli'niz vb. Gerçekten yakalamak istediğim şey, bir iş olarak onlar için önemli olan şeyler.

Harry: Yani, şu anda ilişki kurabildiğimiz bir E-Com müşterisi ile çalışıyoruz... Başlamanız ne kadar hızlı olursa, sepete ekleme olasılığı nedir. Onlara bir ürünü daha erken gösterebilirseniz, satın alma olasılıkları daha yüksektir. Ve bu, kurmak için çok çaba gerektirir, bu, gerçekten hırslı olan müşteriler için bir tür zorlu hedeftir, ancak gerçekten ölçmek istediğiniz herhangi bir şey, çünkü dediğim gibi, gerçekten En Büyük olanı ölçmek istemezsiniz. Contentful Paint, gelirinizi ölçmek mi istiyorsunuz ve bu, Large Contentful Paint'ten mi etkilendi? Bu nedenle, kapsamlı hedef, nihai şey, o iş için bir KPI olarak göreceğiniz herhangi bir şey olacaktır. Gazetelerde birisi makaleyi ne kadar aşağı kaydırmış olabilir? Ve bu, ilk giriş gecikmesiyle herhangi bir şekilde ilişkili mi? CLS düşükse insanlar daha fazla makale okudu mu? Ancak özel, özel metrikler yapmaya başlamadan önce, dürüst olmak gerekirse, web vitals'ın başlamak için gerçekten iyi bir yer olduğunu ve aynı zamanda oldukça iyi bir şekilde normalleştirildiğini düşünüyorum. Bu bir... Kelimenin ne olduğunu bilmiyorum. Sanırım en düşük ortak payda, sektördeki herkesin artık bu seviyedeki oyun alanında performansı tartışabileceği yer.

Harry: Bir sorunum var ve aslında vitals ekibiyle bir toplantı ayarlamam gerekiyor, ayrıca Lighthouse'un gerçekten harika olduğunu düşünüyorum, ancak CLS web vitals'ın %33'ü. LCP, FID, CLS'niz var. CLS, hayati değerlerinizin %33'üdür. Vitals, normalde pazarlama ekibinizin, analiz departmanınızın önüne gelen şeydir, çünkü arama konsolunda açılır, arama sonuçları sayfaları bağlamında bahsedilir, ancak vitals söz konusu olduğunda, ağır bir ağırlığınız var, %33, üçte biri hayati değer CLS, Lighthouse puanımızın sadece %5'i. Yani elde edeceğiniz şey, Lighthouse etrafında inşa eden geliştiriciler, çünkü takımlara entegre edilebiliyor, bu bir laboratuvar metriği. Vitals alan verileridir, romdur.

Harry: Yani, pazarlama ekibinizin "CLS gerçekten kötü" dediğini ve geliştiricilerin "DevTools'un bana verdiği Lighthouse puanının %5'i, puanın %5'i" diye düşünmesini sağlayan büyük bir kopukluk var. bu Lighthouse CLI bize CircleCI'da veriyor” veya ne kullanıyorsanız kullanın, yine de pazarlama ekibi için önemsediklerinin %33'ü. Yani sorun biraz bağlantı kopukluğu çünkü Lighthouse'un çok değerli olduğunu düşünüyorum, ancak hayati değerlerde CLS'nin puanınızın %33'ü olduğu bu oldukça büyük farkı nasıl uzlaştırdıklarını bilmiyorum… iyi, puan değil çünkü siz Gerçekten bir tane yok ve Lighthouse sadece %5 ve bu tartışmayı sorunsuz hale getirebilmemiz için hala düzeltilmesi gereken şeyler var.

Harry: Ama yine, kısa bir soruya uzun cevap. Vital gerçekten çok iyi. LCP, CLS ile aynı teknik çözümlere indirgenebilecek iyi bir kullanıcı deneyimi metriğidir. Bu yüzden bunun gerçekten iyi bir başlangıç ​​noktası olduğunu düşünüyorum. Bunun ötesinde, özel metrikler. Müşterilerime getirmeye çalıştığım şey, sitelerinin ne kadar hızlı olduğunu gerçekten umursamadıkları, sadece dünden daha fazla para kazanmalarını umursadıkları ve eğer kazandıysa, hızlı çalıştığı için mi? Daha az yaptıysa, daha yavaş çalıştığı için mi? İki saniyelik mistik bir LCP'yi kovalamalarını istemiyorum, optimal LCP'yi kovalamalarını istiyorum. Ve bu aslında düşündüğünüzden daha yavaş olduğu ortaya çıkarsa, o zaman her neyse, sorun değil.

Drew: Yani, sadece ilgilenen web geliştiricisi için… Speedcurve gibi araçlara harcayacak bütçeleri yok, iyi bir ölçüm elde etmek için Lighthouse gibi araçları sadece tarayıcılarında çalıştırabilirler… Google gibi şeyler mi? Analizler bu seviye için faydalı mı?

Harry: Öyleler ve daha kullanışlı hale getirilebilirler. Analytics, uzun yıllardır temel performans bilgilerini ele geçirdi. Ve bu DNS zamanı, TCP ve TLS, ilk bayt zamanı, sayfa indirme zamanı, ki bu bir proxy olacak… neyse, her neyse, sadece sayfa indirme zamanı ve yükleme zamanı olacak. Yani oldukça hantal ölçütler. Ama bu iyi bir başlangıç ​​noktasıdır ve normalde bir müşteriyle başladığım her projede, eğer New Relic veya Speedcurve ya da her neyse, yoksa, sadece “Pekala, analizlerinize bir göz atayım” diyeceğim çünkü yapabilirim. en azından durumu oradan vekil. Ve asla Speedcurve veya New Relic veya Dynatrace gibi bir şey kadar iyi olmayacak. Özel metrikleri gerçekten, gerçekten, gerçekten çok kolay bir şekilde analitiklere gönderebilirsiniz. Dinleyen biri gönderebilmek isterse… örneğin benim sitem. "Makalelerimden birinin başlığını ne kadar hızlı okuyabiliyorsun? Hakkında sayfası resmi hangi noktada oluşturuldu? Beni işe almanız için size yalvaran harekete geçirme çağrısı hangi noktadaydı? Bu ne kadar sürede ekrana yansıtılıyor?” Bu verileri yakalamak gerçekten önemsiz ve analitiklere göndermek neredeyse önemsiz. Bu nedenle, herhangi biri sitemdeki kaynağı görüntülemek isterse, kapanış gövde etiketine ilerleyin ve analiz snippet'ini bulun, özel verileri yakalamanın ve bunu analitiklere göndermenin benim için ne kadar kolay olduğunu göreceksiniz. Ve analitik kullanıcı arayüzünde hiçbir şey yapmanıza gerek yoktur. Normalde özel raporlar oluşturmanız, verileri çıkarmanız ve bunları sunulabilir hale getirmeniz gerekir. Bunlar, Google Analytics'te birinci sınıf vatandaştır. Bu nedenle, özel analizleri yakalamaya başladığınız an, gösterge panosunun buna ayrılmış bir bölümü vardır. GA'nın kendisinde herhangi bir kurulum, ağır bir yük yoktur, bu nedenle bu gerçekten önemsizdir ve müşterilerin gerçek bir bütçesi varsa veya belki onlara özel izlemenin gücünü göstermek istersem, "Ah evet, söz veriyorum" demek istemiyorum Gerçekten iyi olacak, Speedcurve için 24 bin alabilir miyim?” Sadece “Bak, bu ilkel” diyerek başlayabilirim. Şimdi burada olasılıkları görelim, şimdi belki sizi Speedcurve gibi bir şeye yükseltmeye ikna edebiliriz.”

Drew: Bir şeyin ne kadar hızlı olması gerektiğine veya bir değişikliğin ne gibi bir etkiye sahip olması gerektiğine dair içgüdülerimin yanlış olabileceğini sık sık fark ettim. Bir değişiklik yapacağım ve işleri daha hızlı hale getirdiğimi düşüneceğim ve sonra onu ölçeceğim ve aslında işleri yavaşlattım. Web perf konusunda saçmaladığım tek şey ben miyim?

Harry: Hiç de değil. Buna gerçekten uygun bir örneğim var. Ön yükleme… ön yüklemeyi duymamış herkes için gerçekten hızlı bir giriş, belirli varlıkları web'e yüklemek doğal olarak çok yavaştır ve buradaki iki ana aday, CSS'deki arka plan resimleri ve web yazı tipleridir, çünkü bir arka plan resmini indirmeden önce, HTML'yi indirmek, ardından CSS'yi indirmek ve ardından CSS "Ah, ana sayfadaki bu div'in bu arka plan görüntüsüne ihtiyacı var" diyor. Bu yüzden, doğası gereği çok yavaş çünkü aradaki tüm CSS zamanına sahipsiniz. Ön yükleme ile, HTML'de head etiketine "Hey, henüz bilmiyorsun ama güven bana, bu resme gerçekten çok çok çok yakında ihtiyacınız olacak" yazan bir satır koyabilirsiniz. Böylece HTML'ye bu indirmeyi önceden başlatan bir ön yükleme koyabilirsiniz. CSS'nin arka plan görüntüsüne ihtiyacı olduğunda, "Oh harika, onu zaten aldık, bu çok hızlı" gibi olur. Ve bu, bu web perf Mesih olarak lanse ediliyor… İşte olay ve size söz veriyorum, geçen hafta bu tweet'i attım ve o zamandan beri iki kez haklı çıktım. İnsanlar önyüklemeyi ve verdiği sözü duyarlar ve ayrıca Lighthouse tarafından çok yoğun bir şekilde desteklenir, teorik olarak sitenizi daha hızlı hale getirir. İnsanlar önyükleme fikriyle o kadar evleniyor ki, çalışmadığını kanıtlayabilsem bile bir daha kaldırmayacaklar. Çünkü “Hayır, ama Deniz Feneri dedi.” Şimdi bu, teorinin sağlam olduğu şeylerden biri. Daha önce indirmek yerine web yazı tipinizi beklemeniz gerekiyorsa, daha hızlı şeyler göreceksiniz. Sorun şu ki, web'in gerçekte nasıl çalıştığını düşündüğünüzde, ilk tıkladığınız herhangi bir sayfa, vurduğunuz herhangi bir yepyeni alan, sınırlı bir bant genişliğiniz var ve tarayıcı bu bant genişliğini çok akıllıca harcıyor. HTML'nizi gerçekten hızlı bir şekilde inceleyecek ve bir alışveriş listesi oluşturacaktır. En önemli şey CSS, sonra bu jQuery, sonra bu… ve sonraki birkaç şey şunlar, bunlar ve bunlar daha az öncelikli. HTML'nizi ön yüklemelerle yüklemeye başladığınızda, tarayıcıya “Hayır, hayır, hayır, bu artık alışveriş listeniz değil dostum, bu benim. Gidip bunları almalısın.” Bu sınırlı bant genişliği miktarı hala sınırlıdır, ancak daha fazla varlığa harcanmaz, bu nedenle her şey marjinal olarak yavaşlar. Geçen hafta bunu iki kez yuhalamak zorunda kaldım ve insanlar hala "Evet ama hayır, çünkü daha erken indiriliyor" diyor. Hayır, daha erken isteniyor, ancak CSS'nizden bant genişliği çalıyor. Web yazı tiplerinizin CSS'nizden bant genişliği çaldığını tam anlamıyla görebilirsiniz. Yani sayıları takip etmek zorunda olduğunuz şeylerden biri. Daha önce büyük ölçekli bir istemcide yaptım. Bunu dinliyorsanız, bu müşteriyi duymuşsunuzdur ve ben oldukça ısrarcıydım, “Hayır, hayır, başlık etiketleriniz yanlış sırada çünkü olması gerektiği gibi ve onları bu dosyada bulundurmanız gerekiyor. sipariş çünkü teorik olarak bunun ipuçlarını veriyor…” Müşteriye ne olduğumu bile biliyordum, kendimi bir aptala hazırladığımı biliyordum. Tarayıcıların çalışma şekli nedeniyle daha hızlı olması gerekir. Milyonlarca insan için bu değişikliği, hileyi yapıyorum ve yavaşladı. Daha yavaş oldu. Ve orada oturup öfkeyle ısrar etmem “Hayır ama tarayıcılar böyle çalışır” işe yaramaz çünkü çalışmıyor. Ve biz onu geri aldık ve ben "Üzgünüm! Yine de bunun için sana fatura keseceğim!” Yani hiç sen değilsin.

Drew: Bu numaraları takip et.

Harry: Evet, aynen. "Aslında senden daha fazla ücret almam gerekiyor çünkü onu geri almak için zaman harcadım, daha uzun sürdü." Ama evet, kesinlikle haklısın, bu sen değilsin, o şeylerden biri… Bunu çok daha küçük bir ölçekte birkaç kez yaptım, burada “Eh, bu teorik olarak işe yaramalı” diyeceğim ve işe yaramıyor. 'T. Sadece gerçek dünyada neler olduğunu takip etmelisin. Bu nedenle bu izleme gerçekten önemlidir.

Drew: Ortam değiştikçe ve teknoloji geliştikçe Google, işleri daha hızlı hale getirmemize yardımcı olan yeni teknolojiler sunuyor, değişikliklere ayak uydurabilmemizin iyi bir yolu var mı? Web performansı söz konusu olduğunda becerilerimizi güncel tutmak için bakmamız gereken herhangi bir kaynak var mı?

Harry: Tüm "Google yapımı" konusunu hızlıca ele almak için... Birazcık dilin ağzında olduğunu biliyorum ama buna odaklanacağım. Sanırım başlangıca doğru, tarayıcıya bahis yapın. Örneğin, AMP gibi şeyler, en iyi ihtimalle, bir çözümün sonradan düşünülmesidir. Hızlı bir site oluşturmanın yerini hiçbir şey tutamaz ve AMP gibi şeyleri kullanmaya başladığınız anda bu standart dışı standartlara bağlı kalmalısınız, AMP ekibinin merhameti fikrini değiştiriyor. Bir müşterim, AMP'nin izin verilenler listesindeki bir yazı tipi sağlayıcısından bir yazı tipini lisanslamak için bir servet harcadı, sonra bir noktada, AMP "Aslında hayır, bu yazı tipi sağlandı, şimdi onları engelleyeceğiz" kararına vardım. kim AMP'ye ve bu yazı tipi sağlayıcısına büyük yatırım yaptı ve “Peki, tüm AMP çalışmalarını geri mi alacağız yoksa bu çok büyük sayıyı yılda bir web yazı tipinde mi harcıyoruz” falan, falan, falan seçmek zorunda kaldı. Bu yüzden herhangi birine karşı çok dikkatli olurdum… Ben bir Google Developer uzmanıyım ama herhangi bir tıkama emri bilmiyorum… Kritik olabilirim ve diyebilirim ki… tek boyutlu olarak selamlanan şeylerden kaçının -her şeye uyan çözüm, AMP gibi şeyler.

Harry: Ve bir saniyeliğine başka birinin üzerine atlamak için Cloudflare, çabasında AMP benzeri olan Roket Yükleyici adında bir şeye sahip. “Ah, CDN'nizdeki bu şeyi açın, sitenizi daha hızlı hale getirecek” gibi tasarlanmıştır. Ve aslında, ilk etapta sitenizi düzgün bir şekilde oluşturmanın yerini alıyor. Yani… işin bu yönünü ele almak için, mümkün olduğunca bağımsız kalmaya çalışın, tarayıcıların nasıl çalıştığını öğrenin, bu da Chrome monokültürünün hemen Google'ın kucağına döndüğünüz anlamına gelir, ancak tarayıcıların nasıl çalıştığını bilin, bazı temel ideolojilere bağlı kalın. Bir site kurarken, bir sayfaya bakın. Bu ister Figma'da, ister Sketch'de, isterse her nerede ise, tasarıma bakın ve “Bir kullanıcının ilk görmek istediği şey bu, bu yüzden bunun önüne hiçbir şey koymayacağım. Bu ana resmi tembelce yüklemeyeceğim çünkü bu çok saçma, bunu neden yapayım?” Bu yüzden sadece "Kullanıcının ilk olarak ne olmasını istersiniz?" diye düşünün. Bir E-Com sitesinde, o ürün resmi olacak, muhtemelen aynı anda gezinecek, ancak ürünün incelemeleri, ürünün Q ve A'sı, tembelce yükleyin. Bunu JavaScript'in arkasına sıkıştırın.

Harry: Hangi teknolojiyi okuyor olursanız olun, size hizmet edecek belirli temel çalışma yöntemleri, "Müşterinizin öncelik verdiği şeylere öncelik verin". Bunun üzerinde daha fazla çalışma yapmak daha hızlı olacaktır, bu yüzden işleri bunun önüne koymayın, daha sonra insanların farkında olması için daha taktiksel şeyler yapın, takip edin… ve tekrar, doğrudan Google'a dönün, ancak web.dev çerçeve agnostiği, yığın agnostik içgörüler için olağanüstü bir kaynak olduğunu kanıtlıyor… Dolayısıyla, hayati bilgiler hakkında bilgi edinmek istiyorsanız, PWA'lar hakkında bilgi edinmek istiyorsunuz, bu nedenle web.dev gerçekten harika.

Harry: Aslında çok az performans odaklı yayın var. Calibre'nin e-postası, bence iki haftada bir yapılan mükemmel e-postası olağanüstü, gerçekten iyi bir özet. Genel olarak web platformuna bir göz atın, bu yüzden Performans Çalışma Grubu var, GitHub teklifleriyle ilgili bir sürü şeyleri var. Tekrar, Google'a geri dönelim, ancak hiç kimse bu web sitesini ve olağanüstü durumunu bilmiyor: chromestatus.com. Size Chrome'un tam olarak ne üzerinde çalıştığını, diğer tarayıcılardan gelen sinyallerin neler olduğunu söyler, bu nedenle öncelikli ipuçlarında işin ne olduğunu görmek istiyorsanız, gidip ilgili tüm hata izleyicilere bağlantılar alabilirsiniz. Chrome Durumu size her biri için kilometre taşlarını gösterir… “Bu MAT8'de çıkıyor, bu '67'de yayınlandı” ya da her neyse, bu oldukça teknik bilgiler için gerçekten iyi bir şey.

Harry: Ama bu şeye geri dönüp duruyorum ve muhtemelen "İhtiyar Bulut'a bağırıyor" gibi konuştuğumu biliyorum ama temel bilgilere bağlı kalın, şimdiye kadar kazandığım neredeyse her pound veya dolar, euro, müşterilere öğretiyor “Tarayıcının bunu zaten yaptığını biliyorsun, değil mi” veya “Bunun daha hızlı olamayacağını biliyorsun” ve bu benim için gerçekten doğru geliyor… Ekstra teknoloji satarak hiçbir zaman bir kuruş kazanmadım. Kazandığım her para, çıkarmak, çıkarmakla ilgili. Kendinizi sitenizi daha hızlı hale getirecek şeyler eklerken buluyorsanız, yanlış yoldasınız.

Harry: Duruma göre, büyük reklamcılık/arama motoru/tarayıcı şirketinin adını vermeyeceğim, isimlerini vermeyeceğim ve JavaScript çerçevesinin adını vermeyeceğim ama şu anda çok, çok büyük, çok popüler bir JavaScript çerçevesiyle aktif olarak zarar veren bir şeyi kaldırma veya çok sayıda web sitesinin performansına zarar verebilecek bir şeyi isteğe bağlı olarak kaldırma hakkında tartışmalar. Bu büyük şirketten birileri "Ah, biz devreye gireceğiz..." dediler, çünkü biraz araştırma yaptılar… ve "Bu şeyi kaldırmak için bir seçeneğe ihtiyacımız var çünkü burada ve burada görebilirsiniz, ve burada bu siteyi yavaşlatıyor.” Ve çözümleri daha fazlasını eklemekti, "Ah ama bunu da yaparsanız, o zaman bundan kaçınabilirsiniz" ve "Hayır, hayır, bir siteyi daha hızlı hale getirmek için daha fazlasını eklemek yanlış çözüm olmalı" gibi. Daha hızlı bir site elde etmek için daha fazla kod gerekiyorsa, kesinlikle yanlış yöne gittiğinizi görebilirsiniz.”

Harry: Çünkü başlamak hızlıydı ve eklediğiniz her şey onu yavaşlatıyor. Ve daha hızlı hale getirmek için daha fazlasını ekleme fikri, daha hızlı bir web sitesinde kendini gösterse de, bu konuda yanlış bir yol. Dibe doğru bir yarış. Üzgünüm, gerçekten gerginim, bir süredir rant atmadığımı söyleyebilirsin. Diğer bir şey de bu, kendinizi bir siteyi daha hızlı hale getirmek için özellikler eklerken bulursanız, muhtemelen yanlış yöne gidiyorsunuzdur, bir şeyleri kaldırmaktan daha hızlı hale getirmek çok daha etkilidir.

Drew: “CSS Sihirbazlığını Hızlandırmak İçin Yaptığım Her Şey” adında bir video kursu hazırladınız.

Harry: Evet!

Drew: Geleneksel çevrimiçi video kurslarından biraz farklı, değil mi?

Harry: Öyle. Dürüst olacağım, kısmen… Tembellik demek istemiyorum ama çok katı olması gereken ve sizi sıfırdan kahramana götüren bir müfredat tasarlamak istemedim çünkü bunun için harcanan zaman çok büyük ve zaman var mıydı bilmiyordum. Bu yüzden, kullanıma hazır malzemeye sahip olmak istedim, "İşte bir tarayıcı ve işte nasıl çalışır" ile başlamaması için, kendimi bu konuda konuşurken ekrana yansıttım, bu yüzden en azından farkında olmanız gerekiyor web perf temelleri, ancak bunlar hack'ler, profesyonel ipuçları ve gerçek hayattan örnekler.

Harry: Ve tam bir müfredat yapmama gerek olmadığı için fiyatı çok aşağıya indirebildim. Yani sizi sıfırdan kahramana götürecek 10 saatlik büyük bir kurs değil, uygun gördüğünüz gibi girip çıkıyor. Temelde sadece siteme bakıyor, bu da istikrarsız şeyler için mükemmel bir oyun alanı ya da… orada deneme yapmak benim için çok düşük risk. Bu yüzden sadece video serisi yaptım. Kaydetmek çok eğlenceliydi. Sadece kendi sitemi yıkıyorum ve “İşte bu böyle çalışıyor ve işte bunu nasıl kullanabilirsiniz” hakkında konuşuyorum.

Drew: Bence farklı problemleri çözmeye ayrılması gerçekten harika. Görüntüleri optimize etme veya başka bir şey hakkında daha fazla bilgi edinmek istersem, "Doğru, arkadaşım Harry bu konuda ne diyor?" diye düşünebilir, görüntülerle ilgili videoya dalıp gidebilirim. Bu şekilde gerçekten erişilebilir, saatlerce ve saatlerce oturmak zorunda değilsiniz, sadece istediğiniz kısma gidebilir ve öğrenmeniz gerekenleri öğrenebilir ve sonra çıkabilirsiniz.

Harry: Sanırım daha fazla tutmaya çalıştım… Katı bir müfredat yapmamanın faydası, önce belirli bir videoyu izlemenize gerek yok, giriş yok, sadece “Git ve etrafa bak ve ilginç bulduklarını gör” bu, LTP sorunlarından muzdarip birinin “Ah, işte bu klasöre dalmak zorundayım” gibi olduğu veya CSS sorunları yaşıyorsa, o klasöre dalabileceği anlamına geliyordu. Açıkçası hiç istatistiklerim yok, ancak kurslarda yüksek bir terk oranı olduğunu hayal ediyorum, çünkü bir şeyi kaçırırsanız diye üç saatlik girişte zorlanmanız gerekiyor ve bu "Ah, biliyor musunuz, yapamam. Bunu her gün yapmaya devam et” ve insanlar birçok kursu bırakabilir. Yani benim düşüncem sadece dalmaktı, önceki üç saati görmene gerek yok, gidip istediğini bulabilirsin. Ve geri bildirim gerçekten çok ama gerçekten… Aslında yapacağım şey şu ki, henüz yok, ama aramadan hemen sonra yapacağım, SMASHING15 indirim kodunu kullanan herkes %15 indirim alacak ondan.

Drew: Yani neredeyse kursun kendisini performansı optimize etmiş gibisin, çünkü doğrudan istediğin kısma gidebilirsin ve tüm müzakereleri yapmak zorunda değilsin ve-

Harry: Evet, istemeden ama bunun için kredi alacağım.

Drew: Yani, web performansı hakkında her şeyi öğreniyorum, son zamanlarda ne öğreniyorsun, Harry?

Harry: Teknik şeyler… pek sayılmaz. “Öğrenecek” listemde çok şey var, bu yüzden QUIC, H3 türü şeyler hakkında biraz daha fazla bilgi edinmek istiyorum, ancak İngiltere'deki ilk karantina sırasında bir E-Kitap yazdım ve öğrendim Sadece HTML ve CSS oldukları için çok eğlenceli olan E-Kitaplar nasıl yapılır ve bu konuda yolumu biliyorum, bu yüzden bu çok eğlenceliydi. Kurs için çok ilkel video düzenlemeyi öğrendim ve bunlarla ilgili sevdiğim şey, bunların hiçbiri kavramsal çalışma değil. Açıkçası, bir programlama dili öğrenmek, kavramlarla boğuşmak zorundasın, oysa bir E-Kitap öğrenmek sadece iş akışları ve… daha önce hiç kurcalamadığım şeylerdi, bu yüzden öğrenmek ilginçti ama kariyer değişikliği gerektirmedi , bu yüzden oldukça güzeldi.

Harry: Ve sonra, teknik olmayan şeyler… Çok fazla bisiklet sürüyorum, çok bisikletten düşüyorum… ve geçen Mart ayından beri, neredeyse bir yıldır hiç seyahat etmediğim için, çok daha fazlasını yapıyorum bisiklete binmek ve buna daha çok odaklanmak… bunu geliştirmeye. Bu yüzden güç çıkışları ve işlevsel eşik güçleri hakkında bir sürü araştırma yapıyorum, şu anda bir antrenman programı yapıyorum, bu yüzden sürekli, sürekli yorgun bacaklar ama bisikletle ilgili fizyoloji hakkında çok şey öğreniyorum. Nedenini bilmiyorum çünkü onunla sürmeye devam etmekten başka bir şey yapma planım yok. Gerçekten büyüleyici oldu. Karantinalar sırasında çok şanslı olduğumu hissediyorum, çoğul ama aktif kalmayı başardım. Pek çok insan, ofise gidip gelmek, bacaklarını uzatmak için iyi bir fırsat gibi basit şeyleri kaçıracak. Birleşik Krallık'ta, bileceğiniz gibi, bisiklete binme çok desteklendi, bu yüzden bisiklete binmek hakkında daha fizyolojik bir açıdan daha fazla şey öğrenmekle çok daha fazla uğraşıyorum, yani… bilmiyorum, sadece bir inek olmak değişiklik için başka bir şey.

Drew: Web'deki performans optimizasyonu ile bisikletteki performans optimizasyonu arasında belki de o kadar büyük bir fark yok değil mi, hepsi marjinal kazançlar, değil mi?

Harry: Evet, aynen. Ve bisiklette baktığım grafiklerin miktarı… Bisikletten güç verilerim var, bir gezintiye çıkacağım ve “Ah, burada beş watt daha olsaydı ama sonra 10 tasarruf etseydim” watt var, bunu, bunu ve bunu şimdiye kadarki en hızlı yapabilirim” ve… bu konuda büyük bir anorak oldu. Ama evet, haklısın. Biliyor musun, orada gerçekten ilginç bir şeye rastladığını düşünüyorum. Biraz takıntılı, sayıların peşinden koşmayı seven biri için bu tür şeyler iyi bir spor/eğlence bence. Bir şeyler var, yani bunu bileceksin ama Strava, KOM'ların var. Geçen yıl 19 tanesini paketledim ki bu benim için olağanüstü bir miktar. Ve neredeyse hepsi, mevcut verileri takıntı haline getirmekten ve “Yenmeye çalıştığım bu adam, bu noktada 700 watt yapıyordu, eğer 1000'e kadar çıkabilseydim ve sonra vazgeçebilseydim” ve falan, falan, falan diye bakmaktan kaynaklanıyor. … takıntılı olmaktır. Nerdy. Ama haklısın, sanırım buna benzer bir şey, değil mi? If you could learn where you afford to tweak things from or squeeze last little drops out…

Drew: And you've still got limited bandwidth in both cases. You've got limited energy and you've got limited network connection.

Harry: Exactly, you can't just magic some more bandwidth there.

Drew: If you, the listener, would like to hear more from Harry, you can find him on Twitter, where he's @csswizardty, or go to his website at csswizardry.com where you'll find some fascinating case studies of his work and find out how to hire him to help solve your performance problems. Harry's E-Book, that he mentioned, and video course we'll link up from the show notes. Thanks for joining us today, Harry, do you have any parting words?

Harry: I'm not one for soundbites and motivation quotes but I heard something really, really, really insightful recently. Everyone keeps saying “Oh well we're all in the same boat” and we're not. We're all in the same storm and some people have got better boats than others. Some people are in little dinghies, some people have got mega yachts. Oh, is that a bit dreary to end on… don't worry about Corona, you'll be dead soon anyway!

Drew: Keep hold of your oars and you'll be all right.

Harry: Evet. I was on a call last night with some web colleagues and we were talking about this and missing each other a lot. The web is, by default, remote, that's the whole point of the web. But… missing a lot of human connection so, chatting to you for this hour and a bit now has been wonderful, it's been really nice. I don't know what my parting words really are meant to be, I should have prepared something, but I just hope everyone's well, hope everyone's making what they can out of lockdown and people are keeping busy.