Smashing Podcast Episode 34 z Harrym Robertsem: Jaki jest stan wydajności internetowej?

W tym odcinku mówimy o wydajności sieci. Jak wygląda krajobraz wydajności w 2021 roku? Aby się tego dowiedzieć, rozmawiałem z ekspertem Harrym Robertsem.

Pokaż notatki

Harry prowadzi warsztaty Web Performance Masterclass ze Smashing w maju 2021 roku. W momencie publikacji nadal dostępne są duże zniżki na wczesne ceny.

• Harry na Twitterze
• Strona konsultingowa Harry'ego CSS Wizardry
• Kurs wideo Wszystko, co zrobiłem, aby przyspieszyć kreatory CSS, w tym 15% zniżki
• Pytania do Konsultantów eBook z 15% rabatem
• Przewodnik Web.dev po Web Vitals
• Ulubiony trzepaczka do jajek Drew OXO GoodGrips

Cotygodniowa aktualizacja

• Trendy w projektowaniu stron internetowych 2021: Raport autorstwa Suzanne Scacca
• Korzystanie z przelotki w aplikacjach React napisanych przez Fortune Ikechi
• Jak zbudować interfejs API Node.js dla Ethereum Blockchain napisany przez Johna Agbanusi
• Jak poprawiliśmy wydajność SmashingMag napisany przez Witalija Friedmana
• Kiedy powiedzieć nie niezależnym projektom napisanym przez Beccę Kennedy

Transkrypcja

Drew McLellan: Jest niezależnym konsultantem ds. wydajności sieciowej z Leeds w Wielkiej Brytanii. W swojej roli pomaga niektórym z największych i najbardziej szanowanych organizacji na świecie w dostarczaniu klientom szybszych i bardziej niezawodnych usług. Jest zaproszonym ekspertem Google Developer, Cloudinary Media Developer Expert, wielokrotnie nagradzanym programistą i międzynarodowym prelegentem. Wiemy, że zna się na wydajności w sieci, ale czy wiesz, że ma 14 ramion i siedem nóg? Moi Smashingowi przyjaciele, witajcie Harry'ego Robertsa. Cześć Harry, jak się masz?

Harry Roberts Hej, miażdżę, bardzo ci dziękuję. Oczywiście 14 ramion, siedem nóg… wciąż stwarzają zwykłe problemy. Nie można kupić spodni.

Drew: I rowery.

Harry: Tak. Cóż, mam trzy i pół rowerów.

Drew: Więc chciałem z tobą dzisiaj porozmawiać, niestety nie o rowerach, chociaż to byłoby zabawne samo w sobie. Chciałem z tobą porozmawiać o wydajności sieci. Jest to temat, który mnie osobiście bardzo pasjonuje, ale jest to jeden z tych obszarów, o które się martwię, kiedy odrywam wzrok od piłki i angażuję się w jakąś inną pracę, a potem wracam do wykonania trochę pracy. Obawiam się, że wiedza, z którą pracuję, bardzo szybko się dezaktualizuje… Czy wydajność sieci jest obecnie tak szybka, jak to widzę?

Harry: To jest… Nie mówię tego tylko po to, żeby być dla ciebie miłym, to takie dobre pytanie, ponieważ ostatnio sporo nad tym myślałem i powiedziałbym, że są dwie połowy. Jedną rzeczą, którą chciałbym powiedzieć klientom, jest to, że w rzeczywistości nie porusza się tak szybko. Przede wszystkim dlatego, że zawsze używam tego dźwięku, możesz postawić na przeglądarkę. Przeglądarkom nie wolno tak naprawdę zmieniać fundamentalnie sposobu ich działania, ponieważ, oczywiście, muszą zachować dwie dekady spuścizny. Tak więc, ogólnie rzecz biorąc, jeśli postawisz na przeglądarkę i wiesz, jak działają te wewnętrzne elementy i TCP/IP, które nigdy się nie zmieniają… Więc pewne rzeczy, które są dość mocno zakorzenione, co oznacza, że ​​ogólnie rzecz biorąc, najlepsze praktyki będą zawsze najlepsze praktyki, jeśli chodzi o podstawy.

Harry: To, co robi się ciekawsze, to… Coraz częściej widzę, że wpadamy w zakręty, jeśli chodzi o kwestie szybkości witryny. Więc faktycznie stwarzamy sobie wiele problemów. Tak więc realistycznie oznacza to wydajność… przypuszczam, że to ruchomy słupek bramki. Im bardziej zmienia się krajobraz lub topografia sieci, sposób jej budowania i sposób, w jaki pracujemy, stawiamy sobie nowe wyzwania. Tak więc nadejście wykonywania znacznie większej ilości pracy na kliencie stwarza inne problemy z wydajnością niż rozwiązywalibyśmy je pięć lat temu, ale te problemy z wydajnością nadal dotyczą wewnętrznych elementów przeglądarki, które w zasadzie nie zmieniły się od pięciu lat. Tak więc wiele zależy… I powiedziałbym, że są na to zdecydowanie dwie jasne strony… Zachęcam moich klientów do oparcia się na przeglądarce, oparcia się na standardach, bo nie da się ich tak po prostu zmienić, bramki tak naprawdę się nie ruszają . Ale oczywiście musi to łączyć się z bardziej nowoczesnymi i być może nieco ciekawszymi praktykami programistycznymi. Więc trzymaj swoje… Cóż, chciałem powiedzieć „stopę w obu obozach”, ale z moimi siedmioma stopami musiałbym… cztery i trzy.

Drew: Wspomniałeś, że podstawy się nie zmieniają, a rzeczy takie jak TCP/IP się nie zmieniają. Jedna z rzeczy, które zmieniły się w… mówię „ostatnie lata”, to prawdopodobnie teraz trochę się cofa, ale jest to HTTP, ponieważ mieliśmy ustalony protokół HTTP do komunikacji między klientami a serwerami, a to się zmieniło, a potem otrzymaliśmy H2, który jest wtedy cały binarny i inny. I to wiele zmieniło… Było to ze względu na wydajność, miało to usunąć niektóre z istniejących ograniczeń, ale to była zmiana i zmienił się sposób, w jaki musieliśmy optymalizować ten protokół. Czy to jest teraz stabilne? A może to się znowu zmieni, czy…

Harry: Więc jedną rzeczą, o której chciałbym dowiedzieć się więcej, jest druga połowa pytania, ponowna zmiana. Muszę bardziej przyjrzeć się QUIC i H3, ale jest to trochę za daleko, aby przydać się moim klientom. Jeśli chodzi o H2, wiele się zmieniło, ale naprawdę uważam, że H2 to wiele fałszywych obietnic i wierzę, że został przekroczony, co jest niezwykłe, biorąc pod uwagę, że H1 został uruchomiony… Mam na myśli 1.1, był rok 1997, więc mamy dużo czasu na pracę nad H2.

Harry: Myślę, że główną korzyścią są twórcy stron internetowych, którzy rozumieją to lub postrzegają, że jest teraz nieograniczony w prośbach o lot. A więc zamiast sześciu wysłanych i/lub sześciu żądań w locie naraz, potencjalnie nieograniczone, nieskończone. Przynosi jednak naprawdę interesujące problemy, ponieważ… jest to dość trudne do opisania bez pomocy wizualnych, ale nadal masz taką samą dostępną przepustowość, niezależnie od tego, czy używasz H1 czy H2, protokół nie przyspiesza połączenia. Jest więc całkiem możliwe, że możesz zalać sieć, żądając jednocześnie 24 plików, ale nie masz na to wystarczającej przepustowości. Więc tak naprawdę nie robisz się szybciej, ponieważ możesz zarządzać tylko ułamkiem tego na raz.

Harry: A także to, o czym musisz pomyśleć, to reakcja plików. I to jest kolejna profesjonalna wskazówka, przez którą przechodzę na warsztatach dla klientów i tak dalej. Ludzie spojrzą na wodospad H2 i zobaczą, że zamiast tradycyjnych sześciu żądań wysyłki mogą zobaczyć 24. Wysyłanie 24 żądań nie jest tak naprawdę przydatne. Przydatne jest to, kiedy te odpowiedzi są zwracane. Zauważysz, że możesz wysłać 24 żądania, więc lewa strona wodospadu wygląda naprawdę ładnie i stromo, ale wszystkie zwracają się w dość rozłożony, sekwencyjny sposób, ponieważ musisz ograniczyć przepustowość, więc nie możesz spełnić wszystkich odpowiedzi w tym samym czasie.

Harry: Cóż, inna sprawa jest taka, że ​​gdybyś spełniał wszystkie odpowiedzi w tym samym czasie, byłbyś przeplatany odpowiedziami. Więc w nocy dostajesz pierwsze 10% każdego pliku, a następne 20%… 20% pliku JavaScript jest bezużyteczne. JavaScript nie jest użyteczny, dopóki nie pojawi się 100%. Więc to, co zobaczysz, to w rzeczywistości sposób, w jaki wodospad H2 manifestuje się, gdy spojrzysz na odpowiedź… I tak wygląda o wiele bardziej jak H1, jest o wiele bardziej rozłożony. Więc, H2, myślę, że był wyprzedany, a może inżynierowie nie uwierzyli, że istnieją limity na to, jak skuteczna może być. Ponieważ zobaczysz, jak ludzie nadmiernie shardują swoje aktywa i mogą mieć ich dwadzieścia… zachowajmy liczbę 24. Zamiast dwóch dużych plików JS, możesz mieć 24 małe pakiety. Nadal będą wracać dość sekwencyjnie. Nie wszystkie przybędą w tym samym czasie, ponieważ nie udało ci się zaczarować większej przepustowości.

Harry: A innym problemem jest to, że każde żądanie ma stałe opóźnienie. Załóżmy, że żądasz dwóch dużych plików i trwa to sto milisekund w obie strony i 250 milisekund, czyli dwa razy 250 milisekund. Jeśli pomnożysz do 24 żądań, nadal masz stałe opóźnienie, które zdecydowaliśmy się na 100 milisekund, więc teraz masz 2400 milisekund opóźnienia i 24 razy… zamiast 250 milisekund pobierania powiedzmy, że pobieranie 25 milisekund, w rzeczywistości trwa to dłużej, ponieważ opóźnienie pozostaje stałe i po prostu mnożysz to opóźnienie przez więcej żądań. Więc zobaczę klientów, którzy przeczytali, że H2 to ta magiczna kula. Rozbiją… Och! Nie mogli uprościć procesu rozwoju, nie musimy tworzyć pakietów ani konkatenacji i tak dalej, i tak dalej. I ostatecznie skończy się to wolniej, ponieważ udało ci się rozłożyć żądania, co było obietnicą, ale twoje opóźnienie pozostaje stałe, więc w rzeczywistości masz tylko n razy większe opóźnienie w przeglądarce. Tak jak powiedziałem, naprawdę trudne, prawdopodobnie bezcelowe próbowanie wyjaśnienia tego bez wizualizacji, ale to niezwykłe, jak manifestuje się H2 w porównaniu z tym, co ludzie mają nadzieję, że może zrobić.

Drew: Czy ten proces shardingu nadal przynosi korzyści, okej, zdobycie całości nadal zajmuje tyle samo czasu, ale do czasu, gdy odzyskasz 100% pierwszego 24. z powrotem, możesz zacząć nad tym pracować i możesz zacznij go wykonywać, zanim minie 24. dzień.

Harry: O rany, kolejne świetne pytanie. Tak więc, absolutnie, jeśli wszystko idzie poprawnie i objawia się to w odpowiedzi bardziej wyglądającej na H1, pomysł byłby taki, że plik zwraca pierwszy, dwa, trzy, cztery, a następnie mogą zostać wykonane w kolejności, w jakiej przychodzą. Możesz więc skrócić łączny czas, zapewniając, że rzeczy dotrą w tym samym czasie. Jeśli spojrzymy na stronę internetową zamiast na wodospad i zauważysz, że żądania są przeplatane, to zła wiadomość. Ponieważ tak jak powiedziałem, 10% pliku JavaScript jest bezużyteczne.

Harry: Jeśli serwer wykona swoją pracę poprawnie i wysyła, wysyła, wysyła, wysyła, wysyła, to będzie szybciej. A potem masz dodatkowe korzyści z Twojej strategii buforowania, która może być bardziej szczegółowa. Tak naprawdę irytujące byłoby aktualizowanie rozmiaru czcionki w widżecie wyboru daty. W świecie H1 musisz zburzyć około 200 kilowatów szerokiego CSS Twojej witryny. Tymczasem teraz po prostu buforujesz plik datepicker.css. Mamy więc takie korzyści, które są zdecydowanie bardzo cenne.

Drew: Sądzę, że w scenariuszu, w którym w magiczny sposób odzyskałeś wszystkie swoje prośby od razu, to oczywiście potencjalnie ugrzęzłoby klienta, prawda?

Harry: Tak, potencjalnie. A wtedy to, co faktycznie by się wydarzyło, to to, że klient musiałby wykonać mnóstwo harmonogramów zasobów, więc w rezultacie powstałby wodospad, w którym wszystkie odpowiedzi wracają w tym samym czasie, wtedy byłaby dość duża luka między nadejście ostatniej odpowiedzi i możliwość jej wykonania. Więc idealnie, gdy mówimy o JavaScript, chciałbyś, aby przeglądarka żądała ich wszystkich w kolejności żądań, zasadniczo w kolejności, w której je zdefiniowałeś, serwer zwracał je wszystkie we właściwej kolejności, aby przeglądarka mogła wykonać je we właściwej kolejności. Ponieważ, jak mówisz, jeśli wszystkie wrócą w tym samym czasie, masz po prostu ogromny JavaScript do uruchomienia na raz, ale nadal trzeba to zaplanować. Więc możesz mieć wątpliwości co do sekundy między przybyciem pliku a jego użytecznością. Właściwie, H1… Myślę, że najlepiej byłoby, gdyby chodziło o planowanie żądań H2, odpowiedzi w stylu H1, aby rzeczy mogły być przydatne, gdy nadejdą.

Drew: Więc zasadniczo szukasz wodospadu odpowiedzi, który wygląda tak, jakbyś mógł po nim zjechać na nartach.

Harry: Tak, dokładnie.

Drew: Ale nie potrzebowałbyś spadochronu.

Harry: Tak. I to jest naprawdę trudne… Myślę, że powiedzenie tego na głos brzmi bardzo trywialnie, ale biorąc pod uwagę sposób, w jaki sprzedawano H2 uważam to za dość… nie trudne, ponieważ to sprawia, że ​​mój klient brzmi… głupio… ale trzeba to wyjaśnić dla nich… jeśli pomyślisz o tym, jak działa H1, nie było tak źle. A jeśli otrzymamy odpowiedzi, które wyglądają tak i „O tak, teraz to widzę”. Musiałem tego wcześniej uczyć inżynierów wykonawczych. Ludzi, którzy robią to, co ja. Musiałem nauczyć inżynierów ds. wydajności, że nie przejmujemy się zbytnio, gdy pojawiają się prośby, naprawdę zależy nam na tym, kiedy odpowiedzi stają się przydatne.

Drew: Jednym z powodów, dla których sprawy toczą się dość szybko, zwłaszcza w ciągu ostatnich pięciu lat, jest to, że wydajność jest ważnym tematem dla Google. A kiedy Google przykłada wagę do czegoś takiego, to zyskuje na przyczepności. Zasadniczo jednak wydajność jest aspektem doświadczenia użytkownika, prawda?

Harry: Och, to znaczy… to naprawdę dobry podcast, myślałem o tym pół godziny temu, obiecuję, że myślałem o tym pół godziny temu. Wydajność to dostępność. Gwarantujesz lub zwiększasz szanse, że ktoś uzyska dostęp do Twoich treści i myślę, że dostępność jest zawsze po prostu… Och, to czytniki ekranu, prawda? To ludzie bez wzroku. Decyzje o budowie strony internetowej, a nie aplikacji… decyzje dotyczą dostępu do większej liczby odbiorców. Więc tak, wydajność to dostępność, która jest zatem doświadczeniem użytkownika. A to doświadczenie użytkownika może sprowadzać się do kropki „Czy ktoś mógłby nawet doświadczyć Twojej witryny”. Albo może to być „Czy to było wspaniałe doświadczenie? Kiedy kliknąłem przycisk, czy zareagował na czas?”. Więc zgadzam się w 100% i myślę, że to jest główny powód, dla którego Google przykłada do tego wagę, ponieważ wpływa to na wrażenia użytkownika i jeśli ktoś ma ufać wynikom wyszukiwania, chcemy spróbować dać tej osobie witrynę, która nie będą nienawidzić.

Drew: I to… wszystko, o czym myślisz, wszystkie korzyści, o których myślisz, wrażenia użytkownika, rzeczy takie jak zwiększone zaangażowanie, to zdecydowanie prawda, prawda? Nic nie odciąga użytkownika od strony szybciej niż powolne działanie. To takie frustrujące, prawda? Korzystanie ze strony, na której wiesz, że może nawigacja nie jest tak przejrzysta, a jeśli klikniesz na link i pomyślisz „Czy tego chcę? Czyż nie? I tylko koszt tego kliknięcia, po prostu czekania, a potem musisz kliknąć przycisk Wstecz, a potem to czekanie i po prostu… poddajesz się.

Harry: Tak, i to ma sens. Jeśli miałbyś skoczyć do supermarketu i zobaczyć, że jest absolutnie zawalony ludźmi, zrobisz absolutne minimum. Nie wydasz tam dużo pieniędzy, to jest jak „Och, potrzebuję tylko mleka”, wchodząc i wychodząc. Natomiast jeśli jest to miłe doświadczenie, masz „Och, no cóż, jak tu będę, zobaczę, czy… Och, tak, mają to… Och, ugotuję to jutro wieczorem” lub cokolwiek. Myślę, że nadal, trzy dekady w sieci, nawet ludzie, którzy budują dla walki w sieci, ponieważ jest to niematerialne. Trudno im naprawdę pomyśleć, że to, co denerwuje Cię w prawdziwym sklepie, denerwuje Cię w Internecie, i tak jest, a statystyki pokazują, że tak.

Drew: Myślę, że na samym początku, myślę o późnych latach 90., pokazując swój wiek tutaj, kiedy tworzyliśmy strony internetowe, bardzo dużo myśleliśmy o wydajności, ale myśleliśmy o wydajności z punktu widzenia połączeń, jakie mieli ludzie używanie były tak powolne. Mówimy o dial-up, modemach, przez linie telefoniczne, modemach 28K, 56K, i w pewnym momencie pojawił się trend w stylizacji obrazów, że każda inna linia obrazu byłaby wymazana jednolitym kolorem, aby dać to… jeśli można to sobie wyobrazić jak patrzenie na obraz przez żaluzję. Zrobiliśmy to, ponieważ pomogło to w kompresji. Ponieważ co drugi wiersz algorytm kompresji mógłby-

Harry: Zwiń w jeden wskaźnik.

Drew: Tak. I tak znacznie zmniejszyłeś rozmiar obrazu, wciąż będąc w stanie uzyskać… I stał się elementem projektu. Wszyscy to robili. Myślę, że może Jeffrey Zeldman był jednym z pierwszych, którzy zapoczątkowali to podejście. Ale myśleliśmy tam przede wszystkim o tym, jak szybko możemy przekazać rzeczy. Nie dla doświadczenia użytkownika, ponieważ nie myśleliśmy o… To znaczy, myślę, że to było doświadczenie użytkownika, ponieważ zasadniczo nie chcieliśmy, aby ludzie opuszczali nasze strony. Ale myśleliśmy o tym, żeby nie optymalizować rzeczy, aby były naprawdę szybkie, ale staraliśmy się uniknąć ich powolnego, jeśli to ma sens.

Harry: Tak, tak.

Drew: A potem, myślę, że w miarę jak prędkości, takie jak linie ADSL, stały się bardziej powszechne, przestaliśmy myśleć w ten sposób i zaczęliśmy po prostu o tym nie myśleć. A teraz jesteśmy w sytuacji, w której używamy urządzeń mobilnych, które mają ograniczone połączenia i być może wolniejsze procesory i musimy o tym pomyśleć jeszcze raz, ale tym razem w kategoriach uzyskania przewagi. Oprócz strony doświadczenia użytkownika, może to przynieść realne korzyści biznesowe pod względem kosztów i zdolności do osiągania zysków. Czyż nie?

Harry: Tak, niesamowicie. To znaczy, nie wiem, jak to sformułować. Nie strzelam sobie tutaj w nogę, ale jedną rzeczą, którą staram się i podkreślam wobec klientów, jest to, że szybkość witryny da ci przewagę nad konkurencją, ale to tylko jedna rzecz, która może dać ci przewagę nad konkurencją. Jeśli masz produkt, którego nikt nie chce kupować, nie ma znaczenia, jak szybka jest Twoja strona. I tak samo, jeśli ktoś naprawdę chce najszybszej witryny na świecie, musisz usunąć swoje obrazy, usunąć swój CSS, usunąć JavaScript, a następnie zobaczyć, ile produktów mówisz, ponieważ gwarantuję, że szybkość witryny nie była czynnikiem. Ale badania wykazały, że bycie szybkim niesie ze sobą ogromne korzyści, rzędu milionów. Podczas rozmowy pracuję z klientem. Wymyśliliśmy dla nich, że gdyby mogli renderować daną stronę o sekundę szybciej, a raczej ich największa zawartość do malowania byłaby o sekundę szybsza, to jest warte 1,8 miliona rocznie, co jest… to duża liczba.

Drew: To by prawie opłaciło twoją opłatę.

Harry: Hej! Tak, prawie. Powiedziałem im: „Słuchaj, po dwóch latach to wszystko się opłaci. Wyjdziesz na zero”. Chciałbym. Ale tak, czy aspekt kontaktu z klientem… przepraszam, aspekt kontaktu z klientem, jeśli masz stronę E-Com, to wyda więcej pieniędzy. Jeśli jesteś wydawcą, przeczytają więcej artykułu lub zobaczą więcej minut treści, lub cokolwiek robisz, jest to Twój KPI, który mierzysz. Mogło być na stronie Smashing, możliwe, że się nie odbiły, ale kliknęli jeszcze kilka artykułów, ponieważ sprawiliśmy, że jest to naprawdę łatwe i szybkie. A wtedy szybsze strony są tańsze w obsłudze. Jeśli masz już uporządkowaną strategię buforowania, będziesz trzymać ludzi z dala od swoich serwerów. Jeśli zoptymalizujesz swoje zasoby, wszystko, co musi pochodzić z Twojego serwera, będzie miało znacznie mniejszą wagę. O wiele tańsze w eksploatacji.

Harry: Rzecz w tym, że dostanie się tam kosztuje. Myślę, że Scott Jehl prawdopodobnie powiedział jeden z najbardziej… I usłyszałem to od niego jako pierwszy, więc zakładam, że to wymyślił, ale powiedzenie brzmi: „Łatwo jest zrobić szybką stronę internetową, ale trudno zrobić stronę internetową szybki". I to jest tak zwięzłe. Ponieważ wydajność sieci może zostać zepchnięta na dół listy rzeczy do zrobienia, ponieważ możesz być w stanie powiedzieć klientowi „Jeśli przyspieszę twoją witrynę o sekundę, zarobisz dodatkowe 1,8 miliona rocznie” lub może to być „Jeśli właśnie dodałeś Apple Pay do swojej kasy, zarobisz dodatkowe pięć milionów”. Więc nie chodzi tylko o wydajność sieci i nie jest to decydujący czynnik, jest to część znacznie większej strategii, szczególnie dla E-Com online. Ale dowody są takie, że zmierzyłem to z pierwszej ręki z moimi klientami detalicznymi, moimi klientami E-Com. Sprawa jest tutaj, masz absolutną rację. To przewaga konkurencyjna, dzięki której zarobisz więcej pieniędzy.

Drew: Znowu wracam do przeszłości, ale ludzie tacy jak Steve Souders byli jednymi z pierwszych, którzy naprawdę zaczęli pisać i mówić o wydajności sieciowej. A ludzie tacy jak Steve w zasadzie mówili: „Zapomnij o infrastrukturze zaplecza, gdzie wszystkie korzyści, które można osiągnąć, są w przeglądarce, we frontendzie, tam wszystko dzieje się powoli”. Czy po 15 latach nadal tak jest?

Harry: Tak, tak. Przeprowadził test ponownie w międzyczasie i teraz, a luka faktycznie się poszerzyła, więc w rzeczywistości jest to bardziej kosztowne w przypadku drutu. Ale jest na to przeszkoda: jeśli masz naprawdę słabą wydajność zaplecza, jeśli powoli wyruszasz z bramy, na przedniej części jest tylko tyle, ile możesz. W tej chwili mam klienta, jego czas do pierwszego bajtu to 1,5 sekundy. Dlatego nigdy nie możemy renderować szybciej niż 1,5 sekundy, więc to będzie ograniczenie. Nadal możemy cofnąć czas na frontendzie, ale jeśli masz naprawdę zły czas na pierwszy bajt, masz spowolnienia w backendzie, istnieje limit tego, o ile szybciej możesz zwiększyć wydajność interfejsu. Ale absolutnie.

Harry: To się jednak zmienia, ponieważ… Cóż, nie, myślę, że się nie zmienia, jest coraz gorzej. Więcej naciskamy na klienta. Kiedyś był to przypadek „Twój serwer jest tak szybki, jak jest, ale potem mamy kilka znaków zapytania”. ponieważ słyszę to cały czas „Wszyscy nasi użytkownicy korzystają z Wi-Fi. Wszyscy mają komputery stacjonarne, ponieważ wszyscy pracują w naszym biurze”. Cóż, nie, teraz wszyscy pracują w domu. Nie masz wyboru. Więc to jest miejsce, w którym pojawiają się wszystkie znaki zapytania, gdzie następuje spowolnienie, gdzie nie można tego naprawdę kontrolować. Po tym fakt, że teraz bardziej stawiamy na klienta. Mam na myśli całe czasy działania na kliencie. I tak przeniosłeś całą logikę aplikacji poza serwer, więc czas do pierwszego bajtu powinien być bardzo, bardzo minimalny. Powinno to być przypadek wysyłania niektórych pakietów z CDM do mojego… ale przeszliście od możliwości specyfikacji własnych serwerów do nadziei, że ktoś nie ma uruchomionego Netflixa na tym samym komputerze, na którym próbuje wyświetlić twoją witrynę .

Drew: Sposób, w jaki projektujemy witryny, to naprawdę dobry punkt i myślę, że tradycyjna najlepsza praktyka zawsze była taka, że ​​powinieneś starać się obsługiwać różne przeglądarki, różne prędkości połączeń, różne rozmiary ekranu, ponieważ nie nie wiem, czego będzie się spodziewać użytkownik. I, jak powiedziałeś, masz takie scenariusze, w których ludzie mówią „O nie, wiemy, że wszyscy nasi użytkownicy są na swoich wydanych do pracy komputerach stacjonarnych, korzystają z tej przeglądarki, jest to najnowsza wersja, są podłączeni do sieci LAN”. ale potem coś się dzieje. Jedną z wielkich korzyści płynących z posiadania aplikacji internetowych jest to, że możemy robić takie rzeczy, jak nagle rozprowadzanie naszej siły roboczej z powrotem do ich domów i mogą oni dalej pracować, ale to jest prawdziwe tylko wtedy, gdy jakość inżynierii była taka, że ​​ktoś, kto się kręci uruchomić swój domowy komputer, na którym może znajdować się IE11 lub cokolwiek innego, niezależnie od tego, czy jest tam jakość pracy, która faktycznie oznacza, że ​​sieć spełnia swój potencjał, będąc naprawdę dostępnym medium.

Drew: Jak mówisz, istnieje trend polegający na przenoszeniu coraz większej liczby rzeczy do przeglądarki i oczywiście jeśli przeglądarka jest wolna, to właśnie wtedy dzieje się spowolnienie. Musisz się zastanowić „Czy to dobry trend? Czy powinniśmy to robić?” Mam jedną stronę, o której szczególnie myślę, zauważyłem, że jest prawie w 100% renderowana przez serwer. Jest bardzo mało JavaScript i jest szybki jak błyskawica. Za każdym razem, gdy do niego podchodzę, myślę „Och, to jest szybkie, kto to napisał?” I wtedy uświadamiam sobie: „O tak, to byłem ja”.

Harry: To dlatego, że jesteś na lokalnym hoście, nic dziwnego, że jest to szybkie. To Twoja witryna dewelopera.

Drew: Następnie, moja codzienna praca, budujemy naszą aplikację jednostronicową i przenosimy rzeczy z serwera, ponieważ w tym przypadku serwer jest wąskim gardłem. Czy możesz po prostu powiedzieć, że bycie w przeglądarce jest bardziej wydajne? Lub bardziej wydajny, aby być na serwerze? Czy to tylko kwestia mierzenia i rozpatrywania każdego przypadku z osobna?

Harry: Myślę, że musisz być bardzo, bardzo, bardzo świadomy swojego kontekstu i… naprawdę uważam, że błąd to… narcyzm, w którym ludzie myślą „Och, mój blog zasługuje na wyświetlenie w czyjejś przeglądarce. Mój blog ze współczynnikiem odrzuceń na poziomie 89% potrzebuje własnego środowiska uruchomieniowego w przeglądarce, ponieważ potrzebuję kolejnych nawigacji, aby były szybkie, chcę tylko pobrać… w zasadzie różnicę danych.” I tak nikt nie klika twojego następnego artykułu, kolego, nie wciskaj czasu wykonawczego w dół rury. Musisz więc być bardzo świadomy swojego kontekstu.

Harry: I wiem, że… jeśli Jeremy Keith tego słucha, prawdopodobnie zrobi na mnie cios, ale jest, powiedziałbym, różnica między stroną internetową a aplikacją internetową, a definicja tego jest bardzo, bardzo mętny. Ale jeśli masz aplikację intensywnie odczytującą i zapisującą, czyli coś, w którym wprowadzasz dane, manipulujesz danymi i tak dalej. Zasadniczo moja strona nie jest aplikacją internetową, to strona internetowa, jest tylko do odczytu, którą mocno umieściłbym w obozie stron internetowych. Coś tak, jak moje oprogramowanie księgowe jest aplikacją internetową, powiedziałbym, że jest aplikacją internetową i jestem gotów ponieść trochę kosztów związanych z czasem rozruchu, ponieważ wiem, że będę tam przez 20 minut, godzinę, cokolwiek. Potrzebujesz więc trochę kontekstu i znowu, może narcyzm jest trochę surowy, ale musisz mieć prawdziwe „Czy musimy zrobić z tej gazety aplikację po stronie klienta?” Nie, nie masz. Nie, nie masz. Ludzie mają włączone blokowanie reklam, ludzie i tak nie lubią witryn z gazetami dojeżdżającymi do pracy. Prawdopodobnie nawet nie przeczytają tego artykułu i nie będą o nim narzekać na Facebooku. Po prostu nie buduj czegoś takiego jako aplikacji renderowanej przez klienta, to nie jest odpowiednie.

Harry: Więc myślę, że zdecydowanie jest punkt, w którym bardziej pomogłoby klientowi, i wtedy masz mniejszą wrażliwość na odejście. Czyli każdy typ com, na przykład, robię na chwilę audyt dla witryny, która… Myślę, że jest to witryna E-Com, ale jest w 100% na kliencie. Wyłączasz JavaScript i nic nie widzisz, tylko pusty div id = „app”. E-Com jest… jesteś bardzo wrażliwy na wszelkie problemy. Twój proces realizacji transakcji jest nawet nieco niepoprawny, jestem gdzieś indziej. Jest za wolny, lecę gdzie indziej. Nie masz kontekstu, w którym ktoś chciałby przez jakiś czas spać w tej aplikacji.

Harry: Photoshop. Otwieram Photoshopa i cieszę się, że zajmie to 45 sekund ekranu powitalnego, ponieważ będę tam przez… w zasadzie 45 sekund jest warte 45 minut. I tak trudno to zdefiniować, dlatego naprawdę ciężko mi przekonać klientów „Proszę, nie rób tego”, ponieważ nie mogę po prostu powiedzieć „Jak myślisz, jak długo twój użytkownik tam będzie”. I możesz to zrobić z… jeśli Twój współczynnik odrzuceń na poziomie 89% nie zostanie zoptymalizowany pod kątem drugiego wyświetlenia strony. Najpierw zmniejsz współczynnik odrzuceń. Myślę, że na pewno jest rozłam, ale powiedziałbym, że większość ludzi znajduje się po złej stronie tej linii. Większość ludzi umieszcza w kliencie rzeczy, których nie powinno tam być. Na przykład CNN nie można przeczytać ani jednego nagłówka w witrynie CNN, dopóki nie zostanie w pełni uruchomiona aplikacja JavaScript. Jedyną rzeczą, którą renderuje serwer, jest nagłówek i stopka, które są jedyną rzeczą, o którą ludzie nie dbają.

Harry: I czuję, że to jest po prostu… nie wiem, jak do tego momentu dojdziemy. To nigdy nie będzie lepsza opcja. Dostarczasz stronę, która jest praktycznie bezużyteczna, która następnie musi powiedzieć „Super, pójdę pobrać aplikację internetową, ale uruchomimy ją w przeglądarce, a potem pójdę i poproszę o nagłówek , wtedy możesz zacząć… och, nie ma cię.” To naprawdę mnie irytuje.

Harry: I nie jest to niczyja wina, myślę, że to dzieciństwo tego rodzaju ekosystemu JavaScript, szum wokół niego, a także, to zabrzmi naprawdę surowo, ale… To w zasadzie dużo naiwnych implementacji. Jasne, Facebook wymyślił React i cokolwiek, to działa dla nich. Dziewięć razy na 10 nie pracujesz na skalę Facebooka, 95 razy na 100 prawdopodobnie nie jesteś najmądrzejszymi inżynierami Facebooka, a to naprawdę, naprawdę okrutne i brzmi okropnie, ale możesz tylko uzyskać… Żadne z te rzeczy są domyślnie szybkie. Potrzebujesz bardzo, bardzo eleganckiej implementacji tych rzeczy, aby były poprawne.

Harry: Rozmawiałem z moim starym… był głównym inżynierem w zespole, w którym byłem 10 lat temu w Sky. Rozmawiałem z nim pewnego dnia o tym i musiał bardzo ciężko pracować, aby szybko renderować aplikację kliencką, podczas gdy w przypadku szybkiej renderowanej aplikacji serwerowej nie musisz nic robić. Po prostu nie musisz ponownie zwalniać. I czuję, że jest dużo różowych okularów, naiwności, marketingu… Brzmię tak ponuro, że musimy iść dalej, zanim zacznę naprawdę tracić tutaj ludzi.

Drew: Czy uważasz, że jako branża mamy tendencję do skupiania się czasem bardziej na doświadczeniu programisty niż na doświadczeniu użytkownika?

Harry: Nie jako całość, ale myślę, że ten problem pojawia się w miejscu, którego można by się spodziewać. Jeśli spojrzysz na tę rozbieżność… nie wiem, czy widziałeś to, ale zakładam, że tak, wydaje się, że bardzo trzymasz rękę na pulsie, rozbieżność między danymi archiwum HTTP o tym, jakie frameworki i Biblioteki JavaScript są używane na wolności w przeciwieństwie do stanu ankiety JavaScript, jeśli podążysz za stanem ankiety JavaScript, powie „O tak, 75% programistów używa Reacta”, podczas gdy mniej niż 5% witryn korzysta z Reacta. Więc wydaje mi się, że masowo, nie sądzę, że to problem, ale myślę, że w obszarach, których można by się tego spodziewać, duża lojalność wobec jednego frameworka, na przykład, doświadczenie programisty jest… ewangelizowane prawdopodobnie przed użytkownikiem. Nie sądzę, że należy przeoczyć doświadczenie programistów, mam na myśli, że wszystko ma koszt utrzymania. Twój samochód. Podjęto decyzję, kiedy projektowano, że „Cóż, jeśli ukryjemy ten klucz, tę funkcjonalność przed mechanikiem, naprawienie tego zajmie mechanikowi dużo więcej, dlatego nie robimy takich rzeczy”. Tak więc musi istnieć równowaga między ergonomią a użytecznością, myślę, że to jest ważne. Myślę, że skupianie się przede wszystkim na doświadczeniu programisty jest dla mnie po prostu zbijające z tropu. Nie optymalizuj dla siebie, optymalizuj dla swojego klienta, Twój klient Ci płaci, a nie odwrotnie.

Drew: Więc komora echa online nie jest dokładnie reprezentatywna dla rzeczywistości, kiedy widzisz, że wszyscy mówią „Och, powinieneś tego używać, powinieneś to robić”, to w rzeczywistości jest to tylko bardzo mały procent ludzi.

Harry: Zgadza się, i to dobrze, to uspokajające. Komora echa… być może nie jest zdrowe mieć taki rodzaj monokultury, jeśli chcesz to tak nazwać. Ale też czuję się jak… i widziałem to w wielu własnych pracach, wielu programistach… Jako konsultant pracuję z wieloma różnymi firmami. Wiele osób wykonuje niesamowitą pracę w WordPressie. A WordPress obsługuje 24% sieci. I wydaje mi się, że takiemu programiście, pracującym na backendzie, w niestandardowym kodzie, czymkolwiek to jest, może być całkiem łatwo, aby poczuć się trochę jak „Och, chyba wszyscy używają Reacta, a my nie. ”, ale tak naprawdę nie. Wszyscy mówią o React, ale ty wciąż płyniesz z prądem, wciąż jesteś z większością. To całkiem uspokajające, znaleźć milczącą większość.

Drew: Trend w kierunku statycznych generatorów witryn, a następnie hostingu witryn w całości w sieci CDN, rodzaj podejścia JAMstack, myślę, że kiedy mówimy o tego rodzaju witrynach typu publikowania, a nie witrynach typu oprogramowania, myślę, że to naprawdę zdrowy trend , pomyślałbyś?

Harry: Absolutnie to uwielbiam. Pamiętasz, jak nazywaliśmy SSG „plik klapy”, prawda?

Drew: Tak.

Harry: Więc zbudowałem CSS Wizardry na Jekyll, kiedy Jekyll nazywano witryną z plikami klap. 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-

Drew: Tak.

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: Dowodził szacunkiem, ale był jednym z chłopaków, wszyscy naprawdę go lubiliśmy. Ale był masywny w każdym wymiarze. Dobrze ponad sześć stóp wzrostu, ale tylko duży chłopak. Duży, duży, duży, duży mężczyzna. I powiedział nam: „Gdybyś zaprojektował drzwi, zaprojektowałbyś je dla przeciętnej osoby?” A mózgi piętnastolatków mówią: „No tak, jeśli wszyscy mają mniej więcej 5'9 lat, to tak”. Powiedział: „Cóż, od razu Harry nie może skorzystać z tych drzwi”. Nie projektujesz dla przeciętnej osoby, projektujesz dla kończyn, ponieważ chcesz, aby była użyteczna dla większości ludzi. Jeśli zaprojektowałeś krzesło dla przeciętnej osoby, pan Brocklesby nie zmieściłby się w nim. Więc uczył mnie od bardzo, naprawdę wieku, projektowania do twoich kończyn.

Harry: A to, co staje się naprawdę interesujące w wydajności sieci, to… Jeśli wyobrazisz sobie drabinę i podniesiesz ją za pomocą bota… OK, właśnie zdałem sobie sprawę, że moja metafora może… będę się tego trzymać i możesz się z tego śmiać mnie później. Wyobraź sobie drabinę, którą podnosisz za dolne szczeble. I to są twoje najgorsze doświadczenia. Wybierasz dolny szczebel w drabinie, aby go podnieść. Wraz z nim idzie cała drabina, jak przypływ unosi wszystkie łodzie. Powodem, dla którego metafora nie działa, jest to, że jeśli podniesiesz drabinę za najwyższy szczebel, ona również się podniesie, to jest drabina. I ta metafora nawet nie zadziała, jeśli zmienię ją w drabinkę sznurową, ponieważ wtedy drabina sznurowa podnosi dolny szczebel i nic się nie dzieje, ale… chodzi mi o to, że jeśli możesz poprawić doświadczenie dla swojego 90. percentyla, to musi to zdobądź to dla swojego 10 percentyla, prawda?

Harry: I dlatego mówię klientom, że mówią mi takie rzeczy jak „No cóż, większość naszych użytkowników korzysta z 4G na iPhone’ach”, więc w porządku, w porządku, i zaczynamy testować 3G na Androidzie, jak „Nie, nie, większość naszych użytkowników to iPhone’y” ok… oznacza to, że przeciętny użytkownik będzie miał lepsze wrażenia, ale każdy, kto nie jest jeszcze w 50. percentylu, zostaje po prostu dalej w tyle. Więc ustaw sobie poprzeczkę dość wysoko, ustawiając dość niskie oczekiwania.

Harry: Przepraszam, mam naprawdę zły nawyk udzielania naprawdę długich odpowiedzi na krótkie pytania. Ale to było fantastyczne pytanie i próbując podsumować, w 100% zdecydowanie zgadzam się z tobą, że chcesz spojrzeć na ten długi ogon, chcesz spojrzeć na to… twój 80 percentyl, ponieważ jeśli weźmiesz wszystkie doświadczenia na stronę i spójrz na medianę, a poprawisz medianę, co oznacza, że ​​uczyniłeś ją jeszcze lepszą dla ludzi, którzy byli już całkiem zadowoleni. 50% osób, które są skutecznie ignorowane, nie jest właściwym podejściem. I tak, to zawsze wraca do pana Brocklesby'ego, który mówi mi: „Nie projektuj dla przeciętnej osoby, ponieważ wtedy Harry nie może użyć drzwi”. Och, dla każdego, kto słucha, mam 193 centymetry, więc jestem dość chudy, to jest to.

Drew: I te wszystkie ręce i nogi.

Harry: Tak. Oto jeszcze jeden dobry. Moja dziewczyna niedawno odkryła ustawienia ułatwień dostępu w iOS… więc każdy ma wyciszony telefon, prawda? Nikt tak naprawdę nie ma telefonu, który faktycznie dzwoni, wszyscy go wyciszają. Odkryła, że ​​„Wiesz, możesz to ustawić tak, aby po otrzymaniu wiadomości migała lampa błyskowa. A jeśli dwukrotnie dotkniesz tył telefonu, zrobi zrzut ekranu”. A to są ustawienia ułatwień dostępu, zaprojektowane dla 95 percentyla. A jednak mówi „Och, to jest naprawdę przydatne”.

Harry: To samo z dobrymi uchwytami OXO. OXO Good Grips, przybory kuchenne. Mam ich mnóstwo w kuchni. Zostały zaprojektowane, ponieważ żona założyciela miała artretyzm, a on chciał robić wygodniejsze naczynia. Zaprojektował dla 99 percentyla, większość ludzi nie ma artretyzmu. Ale projektując dla 99. centyla, niechcący, wszyscy inni są jak „O mój Boże, dlaczego wszystkie obieraczki do ziemniaków nie mogą być tak wygodne?” I czuję, że to naprawdę, naprawdę… Lubię dobre samopoczucie lub anegdotę, którą lubię opowiadać w tego rodzaju scenariuszach. Ale tak, jeśli zoptymalizujesz dla nich… Cóż, przypływ unosi wszystkie łodzie, a to optymalizuje ogony ludzi, a ponad to przyciągniesz wielu jeszcze szczęśliwszych klientów.

Drew: Czy masz ręczną trzepaczkę OXO Good Grips?

Harry: Ja nie. Nie wiem, czy to dobrze?

Drew: Przyjrzyj się temu. To jest takie dobre.

Harry: Mam krajalnicę mandolinową OXO Good Grips, która w zeszłym tygodniu odcięła mi koniec palca.

Drew: Tak, nie zbliżę się do jednego z nich.

Harry: Tak, to moja własna głupia wina.

Drew: Innym przykładem z mojego własnego doświadczenia z cateringiem dla tego długiego ogona jest to, że w projekcie, nad którym obecnie pracuję, ten długi ogon jest na samym końcu, masz ludzi z najwolniejszymi wynikami, ale jeśli okaże się, że jeśli spojrzysz na to, kim są ci klienci, są oni najcenniejszymi klientami dla firmy-

Harry: Dobra.

Drew: …ponieważ są to największe organizacje z największą ilością danych.

Harry: Tak.

Drew: I tak trafiają w wąskie gardła, ponieważ mają tak dużo danych do wyświetlenia na stronie, a te strony muszą zostać trochę zrefaktoryzowane, aby pomóc w takim przypadku użycia. Tak więc mają najwolniejsze działanie, a jeśli chodzi o to, płacą najwięcej pieniędzy i robią o wiele większą różnicę niż wszyscy ludzie, którzy mają naprawdę szybkie działanie, ponieważ są darmowymi użytkownikami z niewielka ilość danych i wszystko działa ładnie i jest szybkie.

Harry: To fascynujący wymiar, prawda? W rzeczywistości miałem podobny… Nie miałem wpływu na biznes, jak to właśnie opisałeś, ale pracowałem z klientem kilka lat temu i jego dyrektor generalny skontaktował się z nim, ponieważ jego strona działała wolno. Jak wolno, wolno, wolno. Naprawdę miły facet, jest po prostu naprawdę miłym, twardo stąpającym po ziemi facetem, ale jest mentorem, jak prawdziwy bogaty. I ma najnowszego iPhone'a, może sobie na to pozwolić. Jest multimilionerem, spędza dużo czasu, latając między Australią, skąd pochodzi, a Estonią, gdzie obecnie mieszka.

Harry: I leci pierwszą klasą, oczywiście, że tak. Ale oznacza to, że większość czasu spędza na swoim ładnym, błyszczącym iPhonie 12 Pro Max, cokolwiek, cokolwiek, jest przez WiFi w samolocie, co jest okropne. I to było naprawdę niesamowite zestawienie, gdzie jest właścicielem strony i często jej używa, jest to strona, z której korzysta. A on naciskał… To znaczy, że ich najbogatszym klientem był ich dyrektor generalny. I jest w tej dziwnie uprzywilejowanej sytuacji, gdzie jest w gorszym połączeniu niż Joe Public, ponieważ jest gdzieś nad Singapurem w samolocie Quantas, z szampanem wlewanym mu po szyi, i walczy. I to był naprawdę fascynujący wgląd, który… O tak, ponieważ masz 95 percentyl, może w zasadzie iść w dowolnym kierunku.

Drew: Tak, kiedy zaczynasz optymalizować stronę z kieliszkiem szampana w jednej ręce, myślisz: „Może zaczynamy się trochę gubić”.

Harry: Tak, dokładnie.

Drew: Rozmawialiśmy trochę o mierzeniu wydajności, a z mojego własnego doświadczenia w pracy nad wydajnością naprawdę ważne jest, aby zmierzyć wszystko.g A, aby móc zidentyfikować, gdzie są problemy, ale robisz coś innego i jak wielką robisz różnicę. Jak powinniśmy się zająć mierzeniem wydajności naszych witryn? Jakich narzędzi możemy użyć i od czego zacząć?

Harry: O rany, kolejne świetne pytanie. Tak więc istnieje szereg odpowiedzi w zależności od tego, ile czasu, zasobów, skłonności do naprawy szybkości witryny. Więc to, co spróbuję zrobić z klientem, to… Niektóre gotowe metryki są naprawdę dobre. Czas ładowania, nie przejmuj się już tym. Jest bardzo, bardzo, bardzo… To znaczy, to dobry serwer proxy, jeśli czas wczytywania wynosi 120 sekund. Zgaduję, że nie masz bardzo szybkiej strony internetowej, ale jest zbyt niejasna i tak naprawdę nie jest skierowana do klienta. Właściwie uważam, że Vitals to naprawdę dobry krok we właściwym kierunku, ponieważ mierzą one wrażenia użytkownika, ale opierają się na danych technicznych. Największy contentful paint jest naprawdę fajny pod względem wizualnym, ale techniczne elementy odblokowują twoją krytyczną ścieżkę, upewnij się, że obrazy bohaterów docierają szybko i upewnij się, że twoja strategia dotycząca czcionek internetowych jest przyzwoita. Te dane mają swój techniczny nurt. Te są naprawdę dobre z półki.

Harry: Jednakże, jeśli klienci mają czas, to zwykle jest to czas, ponieważ chcesz przechwycić dane, ale potrzebujesz czasu, aby faktycznie przechwycić dane. Więc to, co próbuję zrobić z klientami, to chodźmy: „Słuchaj, nie możemy pracować razem przez następne trzy miesiące, ponieważ mam pełne rezerwacje. Możemy więc naprawdę szybko skonfigurować bezpłatną wersję próbną Speedcurve, skonfigurować niestandardowe metryki”, co oznacza, że ​​dla klienta wydawcy, gazety, mierzyłbym „Jak szybko pojawił się nagłówek wyrenderowany artykuł? Jak szybko został wyrenderowany główny obraz artykułu?” Dla klienta e-commerce chcę mierzyć, ponieważ oczywiście mierzysz rzeczy takie jak rozpoczęcie renderowania pasywnie. Gdy tylko zaczniesz korzystać z dowolnego oprogramowania do monitorowania wydajności, rejestrujesz rzeczywiste dane dotyczące wydajności za darmo. Tak więc Twoje pierwsze treści treściwe, największe treści, itp. To, co naprawdę chcę uchwycić, to rzeczy, które są dla nich ważne jako firma.

Harry: A więc praca z klientem E-Com w momencie, w którym jesteśmy w stanie skorelować… Im szybciej zaczniesz renderować, jakie jest prawdopodobieństwo dodania do koszyka. Jeśli możesz pokazać im produkt wcześniej, jest bardziej prawdopodobne, że go kupią. I to jest dużo wysiłku, aby ustawić, to jest rodzaj rozciągającego celu dla klientów, którzy są naprawdę ambitni, ale wszystko, co naprawdę chcesz zmierzyć, ponieważ tak jak powiedziałem, tak naprawdę nie chcesz mierzyć tego, co jest największe Contentful Paint polega na tym, że chcesz zmierzyć swoje przychody i czy miał na to wpływ Large Contentful Paint? Tak więc ostatecznym celem byłoby wszystko, co uważasz za KPI dla tej firmy. Może to być w gazetach, jak daleko w dół ktoś przewinął artykuł? I czy to koreluje w jakikolwiek sposób z opóźnieniem pierwszego wejścia? Czy ludzie czytali więcej artykułów, jeśli CLS był niższy? Ale zanim zaczniemy robić niestandardowe, niestandardowe metryki, szczerze myślę, że wskaźniki sieciowe są naprawdę dobrym miejscem do rozpoczęcia i są również całkiem dobrze znormalizowane. Staje się… nie wiem, co to za słowo. Najniższy wspólny mianownik, jak sądzę, gdzie wszyscy w branży mogą teraz dyskutować o wydajności na równych zasadach.

Harry: Mam jeden problem, a właściwie muszę umówić się na spotkanie z zespołem ds. Vitals, jest to, że naprawdę uważam, że Lighthouse jest świetny, ale CLS to 33% wskaźników internetowych. Masz LCP, FID, CLS. CLS to 33% twoich funkcji życiowych. Vitals to to, co zwykle trafia przed działem marketingu, działem analityki, ponieważ pojawia się w konsoli wyszukiwania, jest wymienione w kontekście stron wyników wyszukiwania, podczas gdy najważniejsze jest to, że masz dużą wagę, 33%, trzecią Vitals to CLS, to tylko 5% naszego wyniku Lighthouse. Dostaniesz więc programistów, którzy budują wokół Lighthouse, ponieważ można je zintegrować z oprzyrządowaniem, jest to metryka laboratoryjna. Vitals to dane terenowe, to rum.

Harry: Więc masz ogromną rozłąkę, w której Twój zespół marketingowy mówi „CLS jest naprawdę zły”, a programiści myślą „Cóż, to 5% wyniku Lighthouse, który daje mi DevTools, to 5% wyniku że Lighthouse CLI daje nam w CircleCI” lub czymkolwiek, czego używasz, ale dla zespołu marketingowego to 33% tego, na czym im zależy. Więc problem jest trochę rozłączony, ponieważ uważam, że Lighthouse jest bardzo cenny, ale nie wiem, jak pogodzić tę dość ogromną różnicę, w której w parametrach życiowych CLS stanowi 33% twojego wyniku… cóż, nie punkt, ponieważ ty tak naprawdę nie mam, a Lighthouse to tylko 5%, a takie rzeczy wciąż wymagają dopracowania, zanim będziemy mogli bezproblemowo przeprowadzić tę dyskusję.

Harry: Ale znowu długa odpowiedź na krótkie pytanie. Vitals jest naprawdę dobry. LCP jest dobrym miernikiem doświadczenia użytkownika, który można sprowadzić do rozwiązań technicznych, podobnie jak w przypadku CLS. Więc myślę, że to naprawdę dobry punkt wyjścia. Poza tym są to niestandardowe metryki. To, do czego staram się nakłonić moich klientów, to punkt, w którym tak naprawdę nie obchodzi ich, jak szybka jest ich strona, po prostu obchodzi ich, że zarobili więcej pieniędzy od wczoraj, a jeśli tak, to dlatego, że działała szybko? Jeśli robił mniej, to dlatego, że działał wolniej? Nie chcę, żeby ścigali mistycznego dwusekundowego LCP, chcę, żeby ścigali optymalny LCP. A jeśli faktycznie okaże się, że jest wolniejsze niż myślisz, to cokolwiek, w porządku.

Drew: Więc dla programistów internetowych, którzy są po prostu zainteresowani… nie mają budżetu do wydania na narzędzia takie jak Speedcurve i inne rzeczy, mogą oczywiście uruchamiać narzędzia takie jak Lighthouse tylko w swojej przeglądarce, aby uzyskać dobry pomiar… Czy rzeczy takie jak Google Analytics przydatne na tym poziomie?

Harry: Są i można je uczynić bardziej użytecznymi. Analytics od wielu lat gromadzi podstawowe informacje o wydajności. I to będzie czas DNS, TCP i TLS, czas do pierwszego bajtu, czas pobierania strony, który jest serwerem proxy… cóż, cokolwiek, po prostu czas pobierania strony i czas ładowania. Więc dość niezgrabne metryki. Ale to dobry punkt wyjścia i normalnie każdy projekt, który zaczynam z klientem, jeśli nie ma New Relic, Speedcurve lub cokolwiek, powiem po prostu „No dobrze, pozwól mi spojrzeć na twoje analizy”, ponieważ mogę najmniej proxy sytuacji stamtąd. I nigdy nie będzie tak dobre, jak coś takiego jak Speedcurve, New Relic, Dynatrace lub cokolwiek innego. Możesz przesyłać niestandardowe metryki naprawdę, naprawdę, bardzo łatwo do analityki. Jeśli ktoś słuchający chce mieć możliwość wysłania… na przykład mojej strony. Mam wskaźniki takie jak „Jak szybko możesz przeczytać nagłówek jednego z moich artykułów? W którym momencie został wyrenderowany obraz strony Informacje? W którym momencie było wezwanie do działania, które błaga cię o zatrudnienie mnie? Jak szybko zostanie to wyrenderowane na ekranie?” Naprawdę trywialne jest przechwytywanie tych danych i prawie tak samo trywialne wysyłanie ich do analityków. Jeśli więc ktoś chce wyświetlić źródło w mojej witrynie, przewiń w dół do zamykającego tagu treści i znajdź fragment kodu analitycznego, zobaczysz, jak łatwo jest mi przechwytywać niestandardowe dane i wysyłać je do analityki. A w interfejsie analitycznym nie musisz nic robić. Zwykle musiałbyś skonfigurować niestandardowe raporty i przeszukiwać dane, aby były prezentowane. Są to obywatele pierwszej klasy w Google Analytics. Tak więc w momencie, gdy zaczniesz przechwytywać niestandardowe analizy, jest poświęcona temu cała sekcja pulpitu nawigacyjnego. W samej GA nie ma konfiguracji, nie ma ciężkiego podnoszenia, więc jest to naprawdę trywialne i jeśli klienci mają prawdziwy budżet lub może chcę im pokazać moc niestandardowego monitorowania, nie chcę mówić „O tak, obiecuję będzie naprawdę dobrze, czy mogę mieć 24 kawałków na Speedcurve?” Mogę zacząć od powiedzenia „Słuchaj, to jest szczątkowe. Zobaczmy tutaj możliwości, teraz możemy przekonać Cię do uaktualnienia do czegoś takiego jak Speedcurve.”

Drew: Często stwierdzam, że moje przeczucie, jak szybko coś powinno być, albo jaki wpływ powinna mieć zmiana, może być błędne. Dokonuję zmiany i myślę, że robię rzeczy szybciej, a potem mierzę to i właściwie to robię rzeczy wolniej. Czy to tylko ja jestem śmieciem na perf w sieci?

Harry: Wcale nie. Mam na to naprawdę trafny przykład. Wstępne ładowanie… naprawdę szybkie wprowadzenie dla każdego, kto nie słyszał o wstępnym ładowaniu, ładowanie niektórych zasobów w Internecie jest z natury bardzo powolne, a dwoma głównymi kandydatami są tutaj obrazy tła w CSS i czcionki internetowe, ponieważ zanim będziesz mógł pobrać obraz tła, musisz aby pobrać kod HTML, który następnie pobiera CSS, a następnie CSS mówi „Och, ten div na stronie głównej potrzebuje tego obrazu tła”. Więc jest to z natury bardzo powolne, ponieważ masz cały ten kawał czasu CSS pomiędzy. Dzięki preload możesz umieścić jeden wiersz w kodzie HTML w tagu head, który mówi „Hej, jeszcze tego nie wiesz, ale uwierz mi, będziesz potrzebować tego obrazu naprawdę, bardzo, bardzo szybko”. Możesz więc umieścić wstępne ładowanie w kodzie HTML, które zapobiegawczo uruchamia to pobieranie. Zanim CSS potrzebuje obrazu tła, wygląda to tak: „Och, fajnie, już go mamy, to szybko”. I to jest reklamowane jako ten internetowy Mesjasz… Oto rzecz i obiecuję wam, że tweetowałem w zeszłym tygodniu i od tego czasu dwukrotnie udowodniłem, że mam rację. Ludzie słyszą o wstępnym ładowaniu i obietnicy, jaką daje, a także, że Lighthouse teoretycznie jest bardzo forsowany, dzięki czemu Twoja witryna jest szybsza. Ludzie do tego stopnia poślubiają ideę wstępnego ładowania, że ​​nawet jeśli udowodnię, że to nie działa, nie usuną go ponownie. Ponieważ „Nie, ale Lighthouse powiedział”. To jedna z tych rzeczy, w których teoria jest słuszna. Jeśli będziesz musiał poczekać na swoją czcionkę internetową, zamiast pobierać ją wcześniej, zobaczysz rzeczy szybciej. Problem polega na tym, że kiedy pomyślisz o tym, jak faktycznie działa sieć, na każdej stronie, którą odwiedzasz po raz pierwszy, każdej nowej domenie, którą odwiedzasz, masz skończoną ilość przepustowości i bardzo mądre wykorzystanie tej przepustowości przez przeglądarkę. Bardzo szybko przejrzy Twój kod HTML i utworzy listę zakupów. Najważniejszą rzeczą jest CSS, potem to jQuery, potem to… i jeszcze kilka rzeczy to te, te i te z mniejszym priorytetem. Gdy tylko zaczniesz ładować swój kod HTML z preloadami, mówisz przeglądarce „Nie, nie, nie, to nie jest już twoja lista zakupów, kolego, to jest moja. Musisz iść i je zdobyć. Ta skończona przepustowość jest nadal skończona, ale nie jest zużywana na więcej zasobów, więc wszystko staje się nieznacznie wolniejsze. I musiałem to wygwizdać dwa razy w zeszłym tygodniu, a ludzie wciąż mówią „Tak, ale nie, to dlatego, że pobiera się wcześniej”. Nie, jest to wymagane wcześniej, ale kradnie przepustowość z Twojego CSS. Możesz dosłownie zobaczyć, jak twoje czcionki internetowe kradną przepustowość z twojego CSS. Jest to więc jedna z tych rzeczy, w których musisz, musisz, musisz podążać za liczbami. Robiłem to już wcześniej na dużym kliencie. Jeśli tego słuchasz, słyszałeś o tym kliencie i bardzo nalegałem, że „Nie, nie, twoje tagi na głowie są w złej kolejności, ponieważ tak powinno być i musisz je mieć w tym porządku, bo teoretycznie to wskazuje na to…” Nawet w tym, czym byłam dla klienta, wiedziałam, że szykuję się na głupca. Ze względu na sposób działania przeglądarek musi być szybszy. Więc robię sztuczkę, tę zmianę… dla wielu milionów ludzi, i to stało się wolniejsze. Zwolniło. A ja siedzący tam z oburzeniem twierdzący „Nie, ale przeglądarki działają w ten sposób” jest bezużyteczny, ponieważ nie działa. I cofnęliśmy to, a ja powiedziałem „Przepraszam! Nadal będę wystawiać za to fakturę!” Więc to wcale nie ty.

Drew: Śledź te liczby.

Harry: Tak, dokładnie. „Właściwie muszę cię obciążyć więcej, ponieważ spędziłem czas, aby to przywrócić, zajęło mi to więcej czasu”. Ale tak, masz absolutną rację, to nie ty, to jedna z tych rzeczy, w których… robiłem to kilka razy na znacznie mniejszą skalę, gdzie powiem „No cóż, to teoretycznie musi działać” i nie działa 'T. Musisz tylko śledzić to, co dzieje się w prawdziwym świecie. Dlatego ten monitoring jest naprawdę ważny.

Drew: Wraz ze zmianami krajobrazu i rozwojem technologii Google wprowadza nowe technologie, które pomagają nam przyspieszać. Czy istnieje dobry sposób, abyśmy mogli nadążyć za zmianami? Czy są jakieś zasoby, którym powinniśmy się przyjrzeć, aby aktualizować nasze umiejętności, jeśli chodzi o wydajność sieci?

Harry: Aby szybko zająć się całym „tworzeniem Google”… wiem, że to trochę przymrużeniem oka, ale skupię się na tym. Chyba na samym początku postaw na przeglądarkę. Rzeczy takie jak AMP, na przykład, są w najlepszym razie rozwiązaniem po namyśle. Nie ma zastępstwa dla zbudowania szybkiej witryny, a w momencie, gdy zaczniesz korzystać z takich rzeczy jak AMP, musisz trzymać się tych niestandardowych standardów, a łaska zespołu AMP zmienia zdanie. Miałem klienta, który wydał fortunę na licencjonowanie czcionki od dostawcy czcionek z listy dozwolonych AMP, a następnie w pewnym momencie AMP zdecydowało „Och, właściwie nie, ta czcionka została dostarczona, zamierzamy teraz je zablokować”. Więc miałem klienta który dużo zainwestował w AMP i tego dostawcę czcionek i musiał wybrać „Cóż, czy cofamy całą pracę z AMP, czy po prostu marnujemy tę bardzo dużą liczbę w ciągu roku na czcionkę internetową” bla, bla, bla. Więc byłbym bardzo ostrożny wobec każdego… jestem ekspertem Google Developer, ale nie znam żadnego nakazu kneblowania… Mogę być krytyczny i powiedziałbym… unikaj rzeczy, które są okrzyknięte jednym rozmiarem rozwiązanie dla wszystkich, takie jak AMP.

Harry: A żeby na chwilę zrzucić kogoś innego, Cloudflare ma coś, co nazywa się Rocket Loader, które jest w stylu AMP. Został zaprojektowany w stylu „Och, po prostu włącz to w swojej sieci CDN, dzięki temu Twoja witryna będzie szybsza”. A właściwie to tylko zamiennik prawidłowego budowania witryny. Więc… aby zająć się tym aspektem, postaraj się pozostać jak najbardziej niezależny, dowiedz się, jak działają przeglądarki, co od razu oznacza, że ​​monokultura Chrome, jesteś z powrotem w łonie Google, ale wiesz, jak działają przeglądarki, trzymaj się kilku podstawowych ideologii. Kiedy budujesz witrynę, spójrz na stronę. Niezależnie od tego, czy jest to Figma, Sketch, czy gdziekolwiek to jest, spójrz na projekt i powiedz: „Cóż, to jest to, co użytkownik chce najpierw zobaczyć, więc nic nie będę w tym przeszkadzał. Nie będę leniwie ładować tego głównego obrazu, ponieważ to głupie, dlaczego miałbym to zrobić?” Zastanów się więc nad pytaniem „Co chciałbyś, aby użytkownik był pierwszy?” Na stronie E-Com będzie to zdjęcie produktu, prawdopodobnie w tym samym czasie nav, ale recenzje produktu, pytania i odpowiedzi produktu, leniwie to ładują. Ukryj to za JavaScriptem.

Harry: Pewne podstawowe sposoby pracy, które będą Ci dobrze służyły, bez względu na technologię, o której czytasz, czyli „Ustaw priorytety dla tego, co priorytetowy dla Twojego klienta”. Większa praca nad tym byłaby szybsza, więc nie stawiaj tego na przeszkodzie, ale potem więcej taktycznych rzeczy, o których ludzie powinni być świadomi, bądź na bieżąco… i znowu, prosto z powrotem do Google, ale web.dev okazuje się być fenomenalnym źródłem wiedzy dla niezależnych od frameworków, niezależnych od stosów spostrzeżeń… Więc jeśli chcesz poznać najważniejsze informacje, chcesz dowiedzieć się więcej o PWA, więc web.dev jest naprawdę świetny.

Harry: Właściwie jest bardzo mało publikacji skoncentrowanych na wydajności. E-mail Calibre jest, myślę, że jego dwutygodniowy e-mail dotyczący wydajności jest po prostu fenomenalny, to naprawdę dobre podsumowanie. Ogólnie miej oko na platformę internetową, więc jest Performance Working Group, która ma mnóstwo rzeczy na temat propozycji GitHub. Ponownie wróć do Google, ale nikt nie wie o tej witrynie i jej fenomenalnym: chromestatus.com. Informuje dokładnie, nad czym pracuje Chrome, jakie są sygnały z innych przeglądarek, więc jeśli chcesz zobaczyć, jak wygląda praca nad wskazówkami dotyczącymi priorytetów, możesz przejść i uzyskać linki do wszystkich odpowiednich programów do śledzenia błędów. Status Chrome pokazuje kamienie milowe dla każdego… „To wychodzi w MAT8, zostało wydane w 1967” lub cokolwiek, to naprawdę dobra rzecz, jeśli chodzi o całkiem techniczne spostrzeżenia.

Harry: Ale wciąż do tego wracam i wiem, że prawdopodobnie brzmię jak „Stary człowiek krzyczy na Cloud”, ale trzymam się podstaw, prawie każdy funt lub dolar, euro, które kiedykolwiek zarobiłem, uczy klientów że „Wiesz, że przeglądarka już to robi, prawda” lub „Wiesz, że to nie może być szybsze” i brzmi to naprawdę dobrze z mojej strony… Nigdy nie zarobiłem ani centa na sprzedaży dodatkowej technologii. Każda część pieniędzy, które zarabiam, polega na usuwaniu, odejmowaniu. Jeśli zauważysz, że dodajesz elementy, które przyspieszają działanie witryny, jesteś w złym kierunku.

Harry: Na przykład nie zamierzam wymieniać… dużych firm zajmujących się reklamą/wyszukiwarkami/przeglądarkami, nie zamierzam ich nazywać i nie będę wymieniał frameworka JavaScript, ale obecnie jestem w dyskusje z bardzo, bardzo dużym, bardzo popularnym frameworkiem JavaScript na temat usuwania czegoś, co aktywnie szkodzi, lub opcjonalnie usuwania czegoś, co mogłoby zaszkodzić wydajności ogromnej liczby stron internetowych. A oni powiedzieli: „Och, wpadniemy…” ktoś z tej dużej firmy, ponieważ przeprowadzili pewne badania… i to było jak „Potrzebujemy opcji, aby usunąć tę rzecz, ponieważ możesz zobaczyć tutaj i tutaj, i tutaj spowalnia tę stronę.” A ich rozwiązanie polegało na dodaniu więcej, na przykład „Och, ale jeśli zrobisz to również, możesz to ominąć”, a to „Nie, nie, dodanie więcej, aby strona była szybsza, musi być złym rozwiązaniem. Z pewnością widzisz, że zmierzasz w złym kierunku, jeśli potrzeba więcej kodu, aby uzyskać szybszą witrynę”.

Harry: Ponieważ na początku było szybko, a wszystko, co dodajesz, sprawia, że ​​jest wolniejsze. I pomysł, aby dodać więcej, aby przyspieszyć, chociaż… może objawiać się w szybszej witrynie, to jest to zły sposób. To wyścig na dno. Przepraszam, robię się naprawdę podekscytowany, możesz powiedzieć, że od jakiegoś czasu nie grałem. A więc to inna sprawa, jeśli zauważysz, że dodajesz funkcje, które przyspieszają witrynę, prawdopodobnie zmierzasz w złym kierunku. O wiele skuteczniejsze jest szybsze usuwanie elementów niż ich dodawanie.

Drew: Stworzyłeś kurs wideo zatytułowany „Wszystko, co zrobiłem, aby przyspieszyć czary CSS”.

Harry: Tak!

Drew: To trochę różni się od tradycyjnych kursów wideo online, prawda?

Harry: Jest. Będę szczery, to po części… nie chcę mówić o lenistwie z mojej strony, ale nie chciałem projektować programu nauczania, który musiałby być bardzo sztywny i prowadzić od zera do bohatera, ponieważ czas poświęcony na zrobienie tego jest ogromny i nie wiedziałem, czy będę miał. Chciałem więc mieć gotowy materiał, po prostu rzut ekranu, w którym mówię, aby nie zaczynał się od „Oto przeglądarka i oto jak to działa”, więc musisz być przynajmniej świadomy podstawy perf w sieci, ale to hacki, porady od profesjonalistów i przykłady z życia.

Harry: A ponieważ nie musiałem robić pełnego programu nauczania, mogłem obniżyć cenę. Więc nie jest to duży 10-godzinny kurs, który zabierze Cię od zera do bohatera, ale można wejść i wyjść, jak uważasz za stosowne. Zasadniczo po prostu patrzę na moją stronę, która jest doskonałym placem zabaw dla rzeczy, które są niestabilne lub… ryzyko eksperymentowania jest dla mnie bardzo małe. Więc właśnie zrobiłem serię wideo. Nagrywanie było świetną zabawą. Po prostu zrywam moją własną stronę i mówię: „No tak to działa i oto jak możesz z tego skorzystać”.

Drew: Myślę, że to naprawdę wspaniałe, jak to jest podzielone na rozwiązywanie różnych problemów. Jeśli chcę dowiedzieć się więcej na temat optymalizacji obrazów lub czegokolwiek, mogę pomyśleć „Tak, co mój kumpel Harry ma na to do powiedzenia?”, zanurzyć się w filmie o obrazach i ruszam. Jest to naprawdę dostępne w ten sposób, nie musisz siedzieć przez wiele godzin z rzeczami, możesz po prostu przejść do tego, co chcesz i nauczyć się tego, czego potrzebujesz, a potem wyjść.

Harry: Myślę, że starałem się zachować to bardziej… Zaletą niestosowania sztywnego programu nauczania jest to, że nie musisz najpierw oglądać określonego filmu, nie ma wstępu, po prostu „Idź i rozejrzyj się i zobacz, co uważasz za interesujące” co oznaczało, że ktoś, kto ma problemy z LTP, mówi „No cóż, muszę zagłębić się w ten folder” lub jeśli ma problemy z CSS, może zagłębić się w tym folderze. Oczywiście nie mam statystyk, ale wyobrażam sobie, że na kursach jest wysoki współczynnik porzucania, po prostu dlatego, że musisz przebrnąć przez trzy godziny wprowadzenia, jeśli coś przegapisz, i to jest jak „Och, wiesz co, nie mogę rób to codziennie”, a ludzie mogą po prostu zrezygnować z wielu kursów. Więc moje myślenie było po prostu zanurzeniem się, nie musisz widzieć poprzednich trzech godzin, możesz po prostu iść i znaleźć, co chcesz. A opinie są naprawdę, naprawdę… Właściwie to, co zrobię, to jeszcze nie istnieje, ale zrobię to zaraz po rozmowie, każdy, kto użyje kodu rabatowego SMASHING15, dostanie 15% zniżki z tego.

Drew: To prawie tak, jakbyś zoptymalizował sam kurs pod kątem wydajności, ponieważ możesz po prostu przejść od razu do tego, co chcesz i nie musisz robić wszystkich negocjacji i-

Harry: Tak, niezamierzone, ale przyjmę to za to.

Drew: Więc nauczyłem się wszystkiego o wydajności sieciowej, czego ostatnio się nauczyłeś, Harry?

Harry: Techniczne sprawy… nie do końca. Mam dużo na mojej liście „do nauczenia się”, więc QUIC, H3 coś w rodzaju, chciałbym zdobyć trochę więcej praktycznej wiedzy na ten temat, ale napisałem e-booka podczas pierwszej blokady w Wielkiej Brytanii, więc nauczyłem się jak tworzyć e-booki, co było świetną zabawą, ponieważ są po prostu HTML i CSS, a ja znam się na tym, więc to była świetna zabawa. Na kursie nauczyłem się bardzo podstawowej edycji wideo, a to, co mi się w nich podobało, nie jest pracą koncepcyjną. Oczywiście, ucząc się języka programowania, musisz zmagać się z pojęciami, podczas gdy nauka e-booka była tylko przepływem pracy i… rzeczami, z którymi nigdy wcześniej nie majstrowałem, więc nauka była interesująca, ale nie wymagała zmiany kariery , więc to było całkiem miłe.

Harry: A potem sprawy nietechniczne… jeżdżę dużo na rowerach, dużo spadam… a ponieważ nie podróżowałem w ogóle od marca zeszłego roku, prawie rok, robię dużo więcej jazdę na rowerze i skupienie się na… poprawie tego. Więc robię mnóstwo badań dotyczących mocy wyjściowych i funkcjonalnych mocy progowych, obecnie robię program treningowy, więc ciągle, ciągle wyczerpane nogi, ale uczę się dużo o fizjologii związanej z jazdą na rowerze. Nie wiem dlaczego, bo nie mam zamiaru robić z tym niczego poza jazdą dalej. To było naprawdę fascynujące. Czuję, że miałem szczęście podczas blokad, liczba mnoga, ale udało mi się pozostać aktywnym. Wiele osób przegapi proste rzeczy, takie jak codzienne dojazdy do biura, dobra okazja na rozprostowanie nóg. Jak wiesz, w Wielkiej Brytanii kolarstwo jest bardzo popularne, więc dużo więcej majstrowałem przy uczeniu się jazdy na rowerze z bardziej fizjologicznego aspektu, co oznacza… nie wiem, po prostu jestem nerdem coś innego dla odmiany.

Drew: Czy może nie ma aż tak dużej różnicy między optymalizacją wydajności w sieci a optymalizacją wydajności w jeździe na rowerze, to wszystko są marginalne korzyści, prawda?

Harry: Tak, dokładnie. I ilość wykresów, na które patrzyłem na rowerze… Mam dane dotyczące mocy z roweru, wyjadę na przejażdżkę i wrócę w stylu „Och, gdybym miał tutaj pięć watów więcej, ale potem zaoszczędziłem 10 watów tam, mógłbym zrobić to, to i to najszybsze w historii” i… był ogromnym anorakiem. Ale tak, masz rację. Wiesz co, myślę, że trafiłeś tam na coś naprawdę interesującego. Myślę, że tego typu rzeczy są dobrym sportem/rozrywką dla kogoś, kto ma trochę obsesji i lubi gonić za liczbami. Są rzeczy, to znaczy, że to wiesz, ale Strava, masz swoje KOMy. W zeszłym roku zapakowałem 19 sztuk, co jest dla mnie ilością fenomenalną. I to prawie wszystko od obsesji na punkcie dostępnych danych i patrzenia na „Ten facet, którego próbuję pokonać, miał w tym momencie 700 watów, gdybym mógł uzyskać do 1000, a potem się wycofać” i bla, bla, bla … to bycie obsesyjnym. Frajerowaty. Ale masz rację, myślę, że to coś podobnego, prawda? 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: Tak. 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.