Smashing Podcast Эпизод 34 с Гарри Робертсом: в каком состоянии веб-производительность?

В этом эпизоде ​​мы говорим о веб-производительности. Как выглядит ландшафт производительности в 2021 году? Я поговорил с экспертом Гарри Робертсом, чтобы выяснить это.

Показать примечания

В мае 2021 года Гарри проводит семинар мастер-класса по веб-производительности вместе со Smashing. На момент публикации все еще действуют большие скидки при раннем бронировании.

• Гарри в Твиттере
• Консультационный сайт Гарри CSS Wizardry
• Видеокурс «Все, что я сделал, чтобы сделать CSS Wizardry быстрым» со скидкой 15%
• Электронная книга «Вопросы для консультантов» со скидкой 15%
• Руководство Web.dev по Web Vitals
• Любимая взбивалка для яиц OXO GoodGrips Дрю

Еженедельное обновление

• Тенденции веб-дизайна 2021: отчет, написанный Сюзанной Скакка
• Использование Grommet в приложениях React, написанных Fortune Ikechi
• Как создать Node.js API для блокчейна Ethereum, написанный Джоном Агбануси
• Как мы улучшили производительность SmashingMag, написанный Виталием Фридманом
• Когда говорить нет внештатным проектам, написанным Беккой Кеннеди

Стенограмма

Дрю Маклеллан: независимый инженер-консультант по веб-производительности из Лидса, Великобритания. В своей роли он помогает некоторым из крупнейших и наиболее уважаемых организаций в мире предоставлять своим клиентам более быстрый и надежный опыт. Он приглашенный эксперт Google Developer, эксперт Cloudinary Media Developer, отмеченный наградами разработчик и международный спикер. Итак, мы знаем, что он знает свое дело, когда дело доходит до веб-производительности, но знаете ли вы, что у него 14 рук и семь ног? Мои Smashing друзья, пожалуйста, поприветствуйте Гарри Робертса. Привет, Гарри, как дела?

Гарри Робертс: Эй, я в шоке, большое спасибо. Очевидно, что 14 рук, семь ног… все еще создают свои обычные проблемы. Невозможно купить брюки.

Дрю: И велосипеды.

Гарри: Ага. У меня есть три с половиной велосипеда.

Дрю: Итак, я хотел поговорить с вами сегодня, к сожалению, не о велосипедах, хотя это само по себе было бы забавно. Я хотел поговорить с вами о веб-производительности. Это тема, которой я лично очень увлечен, но это одна из тех областей, о которых я беспокоюсь, когда я отвлекаюсь от мяча и занимаюсь какой-то другой работой, а затем возвращаюсь к небольшой перформанс-работе, Меня беспокоит, что знания, с которыми я работаю, очень быстро устаревают… Действительно ли веб-производительность в наши дни так быстро меняется, как мне кажется?

Гарри: Это… Я говорю это даже не для того, чтобы быть любезным с тобой, это такой хороший вопрос, потому что я много думал об этом в последнее время, и я бы сказал, что это две половины. Одна вещь, которую я бы попытался сказать клиентам, это то, что на самом деле это не так быстро. В основном потому, что я всегда использую этот звуковой фрагмент, вы можете сделать ставку на браузер. Браузерам на самом деле не разрешено коренным образом менять то, как они работают, потому что, конечно же, они должны поддерживать наследие двух десятилетий. Так что, как правило, если вы делаете ставку на браузер и знаете, как работают эти внутренние устройства, и TCP/IP, которые никогда не меняются… Таким образом, определенные вещи, которые четко высечены в камне, а это означает, что передовая практика, по большому счету, всегда будет наилучшая практика, когда речь идет об основах.

Гарри: Что становится еще интереснее, так это… Я вижу все больше и больше, что мы загоняем себя в угол, когда дело доходит до проблем со скоростью сайта. Таким образом, мы на самом деле создаем себе много проблем. Так что на самом деле это означает производительность ... я полагаю, это движущаяся стойка ворот. Чем больше меняется ландшафт или топография сети, то, как она устроена и как мы работаем, тем больше мы ставим перед собой новые задачи. Таким образом, необходимость выполнять намного больше работы над клиентом ставит другие проблемы с производительностью, чем те, которые мы решали бы пять лет назад, но эти проблемы с производительностью по-прежнему относятся к внутреннему устройству браузера, которое, в общем и целом, не изменилось за пять лет. Так что многое зависит… И я бы сказал, что у этого определенно есть две четкие стороны… Я призываю своих клиентов опираться на браузер, опираться на стандарты, потому что их нельзя просто изменить, стойки ворот на самом деле не двигаются. . Но, конечно же, это должно сочетаться с более современными и, возможно, немного более интересными методами разработки. Итак, вы держите свое… Ну, я собирался сказать «Фут в обоих лагерях», но с моими семью футами мне пришлось бы… четыре и три.

Дрю: Вы упомянули, что основы не меняются и такие вещи, как TCP/IP, не меняются. Одна из вещей, которая действительно изменилась в … я говорю «последние годы», на самом деле это, вероятно, немного возвращается сейчас, но это HTTP в том, что у нас был этот установленный протокол HTTP для связи между клиентами и серверами, и это изменилось, а затем мы получили H2, который тогда весь бинарный и другой. И это многое изменило… Это было сделано из соображений производительности, это должно было убрать некоторые из существующих ограничений, но это было изменение, и способ, которым мы должны были оптимизировать этот протокол, изменился. Сейчас стабильно? Или опять изменится, или…

Гарри: Итак, одна вещь, о которой я хотел бы узнать больше, это вторая половина вопроса, снова изменение. Мне нужно больше изучать QUIC и H3, но это слишком далеко, чтобы быть полезным для моих клиентов. Когда дело доходит до H2, все очень сильно изменилось, но я искренне считаю, что H2 — это много ложных обещаний, и я действительно считаю, что с ним поторопились, что примечательно, учитывая, что H1 был запущен… И я имею в виду 1.1, это был 1997 год, так что у нас есть много времени для работы над H2.

Гарри: Я полагаю, что основное преимущество — это веб-разработчики, которые понимают или считают, что запросы на полеты теперь не ограничены. Таким образом, вместо шести отправленных и/или шести текущих запросов одновременно, потенциально неограниченное количество, бесконечное количество. Приносит действительно интересные проблемы, потому что… это довольно сложно описать без наглядных пособий, но у вас все еще есть доступная пропускная способность, независимо от того, используете ли вы H1 или H2, протокол не делает ваше соединение быстрее. Так что вполне возможно, что вы могли бы залить сеть, запросив сразу 24 файла, но у вас недостаточно пропускной способности для этого. Таким образом, вы на самом деле не становитесь быстрее, потому что вы можете управлять только частью этого за раз.

Гарри: А еще ты должен подумать о том, как файлы реагируют. И это еще один совет, который я использую на семинарах для клиентов и так далее. Люди посмотрят на водопад H2 и увидят, что вместо традиционных шести запросов на отправку они могут увидеть 24. Отправка 24 запросов на самом деле не так уж полезна. Что полезно, так это когда эти ответы возвращаются. И вы заметите, что вы можете отправить 24 запроса, поэтому ваша левая сторона вашего водопада выглядит очень красиво и круто, но все они возвращаются в довольно ступенчатом, последовательном порядке, потому что вам нужно ограничить объем полосы пропускания, поэтому вы не можете выполнить все ответы одновременно.

Гарри: Ну, с другой стороны, если бы вы выполняли все ответы одновременно, вы бы чередовали ответы. Таким образом, вы получаете первые 10% каждого файла и следующие 20%… 20% файла JavaScript бесполезны. JavaScript нельзя использовать, пока не получено 100% его объема. Итак, вы увидите, как на самом деле проявляется водопад H2, когда вы смотрите на отклик… В любом случае, он больше похож на H1, он гораздо более ступенчатый. Итак, я думаю, что H2 был перепродан, или, возможно, инженеры не верили, что существуют ограничения на то, насколько эффективным он может быть. Поскольку вы увидите, что люди чрезмерно шардируют свои активы, и у них может быть двадцать… давайте сохраним число 24. Вместо двух больших JS-файлов у вас может быть 24 маленьких пакета. Они все равно будут возвращаться довольно последовательно. Они не будут поступать одновременно, потому что вы не наколдовали себе большую пропускную способность.

Гарри: Другая проблема заключается в том, что каждый запрос имеет постоянную задержку. Итак, допустим, вы запрашиваете два больших файла, и это сто миллисекунд в оба конца и 250 миллисекунд на загрузку, это два раза по 250 миллисекунд. Если вы умножите до 24 запросов, у вас все еще будет постоянная задержка, которую мы определили в 100 миллисекунд, так что теперь у вас есть задержка 2400 миллисекунд и 24 раза… вместо 250 миллисекунд загрузки, скажем, 25 миллисекунд загрузки, на самом деле это занимает больше времени, потому что задержка остается постоянной, и вы просто умножаете эту задержку на большее количество запросов. Так что я увижу клиентов, которые прочитают, что H2 — это волшебная палочка. Они осколки… О! Они не могли упростить процесс разработки, нам не нужно делать связывание или конкатенацию и так далее и тому подобное. И, в конечном счете, он будет работать медленнее, потому что вам удалось распределить свои запросы, что и было обещано, но ваша задержка остается постоянной, так что на самом деле у вас просто в n раз больше задержки в браузере. Как я уже сказал, очень сложно, возможно, бессмысленно пытаться объяснить это без визуальных эффектов, но удивительно, как H2 проявляет себя по сравнению с тем, что люди надеются, что он может сделать.

Дрю: Есть ли еще польза в этом процессе шардинга в том, что, хорошо, чтобы получить всю партию, по-прежнему требуется то же количество времени, но к тому времени, когда вы получите 100% первого 24-го числа, вы можете начать работать над этим, и вы можете начать выполнять его до 24-го числа.

Гарри: О, чувак, еще один отличный вопрос. Так что, безусловно, если все пойдет правильно и это проявится в ответе, больше похожем на H1, идея будет заключаться в том, что файл сначала возвращает первый, второй, третий, четвертый, а затем они могут выполняться в том порядке, в котором они приходят. Таким образом, вы действительно можете сократить общее время, обеспечив доставку вещей одновременно. Если мы посмотрим на веб-страницу, а не на водопад, и вы заметите, что запросы чередуются, это плохие новости. Потому что, как я уже сказал, 10% файла JavaScript бесполезны.

Гарри: Если сервер правильно выполняет свою работу и отправляет, отправляет, отправляет, отправляет, отправляет, тогда он будет работать быстрее. И тогда вы получите дополнительные преимущества от того, что ваша стратегия кэширования может быть более детальной. Так что действительно раздражает, если вы обновляете размер шрифта в виджете выбора даты. В мире H1 вам нужно кэшировать примерно 200 киловатт широкого CSS вашего сайта. В то время как сейчас вы просто кэшируете бюст datepicker.css. Так что у нас есть такие дополнительные преимущества, которые определенно очень ценны.

Дрю: Думаю, в сценарии, где вы волшебным образом получили все свои запросы сразу, это, очевидно, потенциально затормозило бы клиента, не так ли?

Гарри: Да, возможно. И тогда на самом деле произойдет то, что клиент должен будет выполнить загрузку планирования ресурсов, так что в итоге вы получите водопад, в котором все ваши ответы возвращаются в одно и то же время, тогда у вас будет довольно большой разрыв между прибытие последнего ответа и возможность его выполнения. Так что в идеале, когда мы говорим о JavaScript, вы бы хотели, чтобы браузер запрашивал их все в порядке запросов, в основном в том порядке, в котором вы их определили, сервер возвращал их все в правильном порядке, чтобы браузер мог выполнить их в правильном порядке. Потому что, как вы говорите, если все они вернутся одновременно, у вас просто будет огромный JavaScript для одновременного запуска, но его все равно нужно запланировать. Таким образом, у вас может быть сомневающийся до секунды между получением файла и тем, что он станет полезным. Итак, на самом деле, H1… Я думаю, в идеале вам нужно планирование запросов H2, ответы в стиле H1, чтобы вещи можно было сделать полезными по мере их поступления.

Дрю: Итак, вы в основном ищете ответный водопад, который выглядит так, будто вы можете спуститься по нему на лыжах.

Гарри: Да, точно.

Дрю: Но тебе не нужен парашют.

Гарри: Ага. И это действительно сложно… Я думаю, что произнести это вслух, это звучит очень тривиально, но, учитывая то, как продавался H2, я нахожу это довольно… не сложным, потому что это заставляет моего клиента звучать… глупо… но объяснить это довольно сложно. им… если подумать о том, как работает H1, все было не так уж и плохо. И если мы получим ответы, которые выглядят так и «О да, теперь я это вижу». Раньше мне приходилось учить этому инженеров по производительности. Люди, которые делают то же, что и я. Мне пришлось учить инженеров по производительности тому, что мы не слишком возражаем, когда запросы были сделаны, мы действительно заботимся о том, когда ответы становятся полезными.

Дрю: Одна из причин, по которой события развиваются довольно быстро, особенно за последние пять лет, заключается в том, что производительность является важной темой для Google. И когда Google придает вес чему-то подобному, это набирает обороты. По сути, производительность — это аспект взаимодействия с пользователем, не так ли?

Гарри: О, я имею в виду… это действительно хороший подкаст, я думал об этом полчаса назад, клянусь, я думал об этом полчаса назад. Производительность — это прикладная доступность. Вы гарантируете или увеличиваете вероятность того, что кто-то сможет получить доступ к вашему контенту, и я думаю, что доступность всегда просто… О, это программы для чтения с экрана, верно? Это люди без зрения. Решения о создании веб-сайта, а не приложения… решения о доступе к большей аудитории. Так что да, производительность — это прикладная доступность, которая, следовательно, является пользовательским опытом. И этот пользовательский опыт может сводиться к точке «Может ли кто-нибудь вообще увидеть ваш сайт». Или это может быть «Был ли этот опыт восхитительным? Когда я нажимал кнопку, она своевременно реагировала?». Так что я на 100% согласен, и я думаю, что это основная причина, по которой Google придает этому большое значение, потому что это влияет на взаимодействие с пользователем, и если кто-то собирается доверять результатам поиска, мы хотим попытаться дать этому человеку сайт, который они не будут ненавидеть.

Дрю: И это… все, о чем вы думаете, все преимущества, о которых вы думаете, пользовательский опыт, такие вещи, как увеличение вовлеченности, это определенно правда, не так ли? Ничто так быстро не уводит пользователя с сайта, как медлительность. Это так расстраивает, не так ли? Используя сайт, где вы знаете, что навигация может быть не такой ясной, и если вы нажимаете на ссылку и думаете: «Это то, что я хочу? Это не?" И только стоимость этого щелчка, простое ожидание, а затем вам нужно нажать кнопку «Назад», а затем это ожидание, и это просто… вы сдаетесь.

Гарри: Да, и это имеет смысл. Если вы заскочите в супермаркет и увидите, что он буквально битком набит людьми, вы сделаете минимум. Вы не собираетесь тратить там много денег, это как «О, мне просто нужно молоко», туда и обратно. Тогда как, если это приятный опыт, у вас есть «О, хорошо, пока я здесь, я посмотрю, есть ли… О, да, у них есть это… О, я приготовлю это завтра вечером» или что-то в этом роде. Я все еще думаю, что через три десятилетия в Интернете даже люди, которые создают для Интернета, борются, потому что это неосязаемо. Они изо всех сил пытаются действительно думать, что то, что раздражает вас в реальном магазине, будет раздражать вас в Интернете, и это так, и статистика показывает, что это так.

Дрю: Я думаю, что в самом начале, я думаю о конце 90-х, показывая здесь свой возраст, когда мы создавали веб-сайты, мы очень много думали о производительности, но мы думали о производительности с точки зрения того, что связи между людьми использование было настолько медленным. Мы говорим о коммутируемом соединении, модемах, телефонных линиях, модемах 28K, 56K, и в какой-то момент была тенденция к стилизации изображений, что каждая вторая строка изображения закрашивалась сплошным цветом, чтобы дать это… если вы можете представить это как смотреть сквозь жалюзи на изображение. И мы сделали это, потому что это помогло при сжатии. Потому что каждая вторая строка алгоритма сжатия может-

Гарри: Свернуть в один указатель.

Дрю: Ага. Таким образом, вы значительно уменьшили размер изображения, но при этом сохранили… И это стало элементом дизайна. Все этим занимались. Я думаю, что Джеффри Зельдман был одним из первых, кто применил этот подход. Но в первую очередь мы думали о том, как быстро мы сможем решить проблему. Не для пользовательского опыта, потому что мы не думали о… Я имею в виду, что это был пользовательский опыт, потому что мы, по сути, не хотели, чтобы люди покидали наши сайты. Но мы думали не о том, чтобы оптимизировать вещи так, чтобы они были действительно быстрыми, а о том, чтобы избежать их очень медленной работы, если это имеет смысл.

Гарри: Да, да.

Дрю: А потом, я думаю, когда скорости, подобные линиям ADSL, стали более распространенными, мы перестали думать в этих терминах и начали просто не думать об этом вообще. И теперь мы находимся в ситуации, когда мы используем мобильные устройства с ограниченными соединениями и, возможно, более медленными процессорами, и нам приходится думать об этом снова, но на этот раз с точки зрения получения преимущества. Помимо пользовательского опыта, это может иметь реальные преимущества для бизнеса с точки зрения затрат и способности получать прибыль. Разве это не так?

Гарри: Да, невероятно. Я имею в виду, не знаю, как это сформулировать. Не стреляю себе в ногу здесь, но одна вещь, которую я стараюсь и подчеркиваю клиентам, заключается в том, что скорость сайта даст вам конкурентное преимущество, но это только одна вещь, которая может дать вам некоторое конкурентное преимущество. Если у вас есть продукт, который никто не хочет покупать, то не имеет значения, насколько быстр ваш сайт. И точно так же, если кто-то действительно хочет самый быстрый веб-сайт в мире, вы должны удалить свои изображения, удалить свой CSS, удалить свой JavaScript, а затем посмотреть, сколько продуктов вы расскажете, потому что я гарантирую, что скорость сайта не была фактором. Но исследования показали, что скорость дает огромные преимущества, порядка миллионов. Пока мы разговариваем, я работаю с клиентом. Мы выяснили для них, что если бы они могли отображать данную страницу на одну секунду быстрее, или, точнее, их самый большой контент для рисования был на одну секунду быстрее, это стоило бы 1,8 миллиона в год, что… это большое число.

Дрю: Это почти оплатит ваш гонорар.

Гарри: Эй! Да, почти. Я сказал им: «Послушайте, через два года все это окупится. Вы будете в безубыточности». Хотел бы я. Но да, что касается аспекта, ориентированного на клиента… простите, аспекта, ориентированного на клиента, если у вас есть сайт E-Com, они будут тратить больше денег. Если вы издатель, они будут читать больше статей или просматривать больше минут контента, или что бы вы ни делали, это ваш KPI, который вы измеряете. Это может быть на сайте Smashing, может быть, они не отказываются, они на самом деле просматривают еще несколько статей, потому что мы сделали это очень легко и быстро. И тогда более быстрые сайты дешевле в эксплуатации. Если вы разобрались со своей стратегией кэширования, вы будете держать людей подальше от ваших серверов. Если вы оптимизируете свои активы, все, что должно поступать с вашего сервера, будет весить намного меньше. Так дешевле в эксплуатации.

Гарри: Дело в том, что за это приходится платить. Я думаю, что Скотт Джел, вероятно, сказал одно из самых… И я услышал это от него первым, поэтому я собираюсь предположить, что он придумал это, но поговорка такова: «Легко создать быстрый веб-сайт, но трудно сделать веб-сайт». быстро". И это так лаконично. Потому что причина, по которой веб-производительность может быть отодвинута в конец списка дел, заключается в том, что вы можете сказать клиенту: «Если я сделаю ваш сайт на секунду быстрее, вы заработаете дополнительно 1,8 миллиона в год», или это может быть «Если вы просто добавили Apple Pay к своей кассе, вы заработаете дополнительные пять миллионов». Так что дело не только в веб-производительности, и это не решающий фактор, это часть гораздо большей стратегии, особенно для E-Com онлайн. Но доказательство в том, что я лично измерил это с моими розничными клиентами, моими клиентами E-Com. Дело за этим прямо здесь, вы абсолютно правы. Это конкурентное преимущество, оно принесет вам больше денег.

Дрю: В прошлом, опять же, я возвращаюсь к прошлому, но такие люди, как Стив Содерс, были одними из первых, кто действительно начал писать и говорить о веб-производительности. И такие люди, как Стив, в основном говорили: «Забудьте о внутренней инфраструктуре, где все преимущества находятся в браузере, во внешнем интерфейсе, где все происходит медленно». Это все еще так 15 лет спустя?

Гарри: Да, да. Он повторно провел тест в промежутке между тогда и сейчас, и разрыв на самом деле увеличился, так что на самом деле это дороже по проводам. Но этому есть противодействие: если у вас действительно плохая производительность бэкэнда, если вы медленно выходите из ворот, то на фронтэнде вы можете отжать только так много. У меня есть клиент на данный момент, их время до первого байта составляет 1,5 секунды. Следовательно, мы никогда не сможем выполнить рендеринг быстрее, чем за 1,5 секунды, так что это ограничение. Мы по-прежнему можем вернуть время назад на внешнем интерфейсе, но если у вас очень, очень плохое время до первого байта, у вас есть замедление бэкэнда, существует предел того, насколько быстрее ваши усилия по повышению производительности внешнего интерфейса могут помочь вам. Но абсолютно.

Гарри: Это, однако, меняется, потому что… Ну, нет, не меняется, наверное, становится хуже. Мы больше навязываем клиенту. Раньше это был случай: «Ваш сервер такой же быстрый, как и сейчас, но после этого у нас появляется куча вопросительных знаков». потому что я постоянно слышу это: «Все наши пользователи используют WiFi. У них у всех есть настольные компьютеры, потому что все они работают из нашего офиса». Нет, теперь они все работают из дома. Вы не можете выбирать. Итак, вот где появляются все знаки вопроса, где происходят замедления, где вы не можете это контролировать. После этого то, что сейчас мы склонны больше ставить на клиенте. Под этим я подразумеваю полное время выполнения на клиенте. В любом случае вы переместили всю логику вашего приложения с сервера, поэтому ваше время до первого байта должно быть очень, очень минимальным. Это должен быть случай отправки некоторых пакетов из CDM на мой ... но вы перешли от возможности указать свои собственные серверы к надежде, что у кого-то нет Netflix, работающего на той же машине, на которой они пытаются просмотреть ваш сайт. .

Дрю: Это действительно хорошее замечание о том, как мы разрабатываем сайты, и я думаю, что традиционная лучшая практика всегда заключалась в том, что вы должны стараться учитывать все виды браузеров, все виды скоростей подключения, все виды размеров экрана, потому что вы не не знаю, чего ожидает пользователь. И, как вы сказали, у вас есть такие сценарии, когда люди говорят: «О, нет, мы знаем, что все наши пользователи находятся на своих рабочих компьютерах, они используют этот браузер, это последняя версия, они жестко подключены к локальной сети». но потом что-то происходит. Одним из больших преимуществ наличия веб-приложений является то, что мы можем делать такие вещи, как внезапное распределение нашей рабочей силы по домам, и они могут продолжать работать, но это верно только в том случае, если качество проектирования было таким, что кто-то, кто вращается на своем домашнем компьютере, на котором может быть установлен IE11 или что-то еще, независимо от того, есть ли качество работы, которое на самом деле означает, что сеть реализует свой потенциал в качестве действительно доступной среды.

Дрю: Как вы сказали, существует тенденция переносить все больше и больше вещей в браузер, и, конечно же, если браузер работает медленно, именно там и происходит медлительность. Вы должны задаться вопросом: «Хорошая ли это тенденция? Должны ли мы делать это?» У меня есть один сайт, о котором я особенно думаю, заметил, что он почти на 100% обработан сервером. Там очень мало JavaScript, и он молниеносно быстр. Каждый раз, когда я захожу на него, я думаю: «О, это быстро, кто это написал?» И тут я понимаю: «О да, это был я».

Гарри: Это потому, что ты на локальном хосте, неудивительно, что это кажется быстрым. Это ваш сайт разработки.

Дрю: Затем моя основная работа заключается в том, что мы создаем наше одностраничное приложение и переносим все с сервера, потому что в этом случае сервер является узким местом. Можете ли вы просто сказать, что в браузере производительнее? Или производительнее быть на сервере? Это просто случай измерения и принятия в каждом конкретном случае?

Гарри: Я думаю, вам нужно очень, очень, очень хорошо осознавать свой контекст и… искренне я думаю, что ошибка – это… нарциссизм, когда люди думают: «О, мой блог заслуживает того, чтобы его отображали в чьем-то браузере. Мой блог с показателем отказов 89% нуждается в собственной среде выполнения в браузере, потому что мне нужно, чтобы последующие переходы были быстрыми, я просто хочу получить… в основном разницу данных». Все равно никто не нажмет на твою следующую статью, приятель, не тяни время выполнения в трубу. Таким образом, вы должны быть очень осведомлены о вашем контексте.

Гарри: И я знаю, что… если Джереми Кит слушает это, он, вероятно, нанесет мне удар, но я бы сказал, что есть разница между веб-сайтом и веб-приложением, и определение этого очень, очень мутно. Но если у вас есть приложение, интенсивно считывающее и записывающее, так что что-то, где вы вводите данные, манипулируете данными и так далее. По сути, мой сайт — это не веб-приложение, это веб-сайт, предназначенный только для чтения, который я бы твердо отнес к лагерю веб-сайтов. Что-то вроде моего программного обеспечения для бухгалтерского учета — это веб-приложение, я бы сказал, веб-приложение, и я готов понести некоторые затраты времени на загрузку, потому что я знаю, что буду там 20 минут, час, сколько угодно. Так что вам нужно немного контекста, и опять же, может быть, нарциссизм немного суров, но вам нужно иметь реальное «Нужно ли нам сделать эту газету клиентским приложением?» Нет, не знаешь. Нет, не знаешь. Люди включили блокировщик рекламы, люди все равно не любят сайты пригородных газет. Они, вероятно, даже не будут читать статью и разглагольствовать об этом на Facebook. Только не стройте что-то подобное в качестве клиентского приложения, это не подходит.

Гарри: Так что я действительно думаю, что определенно есть момент, когда больше внимания уделяется клиенту, и это когда у вас меньше чувствительности к оттоку. Итак, любой тип com, например, я сейчас провожу аудит для сайта, который… я думаю, что это сайт E-Com, но он на 100% на клиенте. Вы отключаете JavaScript и ничего не видите, только пустой div id="app". E-Com это… вы очень чувствительны к любым вопросам. Ваш процесс оформления заказа даже слегка неверен, я ухожу куда-то еще. Это слишком медленно, я где-то в другом месте. У вас нет контекста, в котором кто-то хочет какое-то время спать с этим приложением.

Гарри: Фотошоп. Я открываю Photoshop и очень рад узнать, что заставка займет 45 секунд, потому что я буду там… в основном 45 секунд стоят 45 минут. И это так сложно определить, поэтому мне очень трудно убедить клиентов: «Пожалуйста, не делайте этого», потому что я не могу просто сказать: «Как долго, по вашему мнению, ваш пользователь будет там находиться». И вы можете проксировать его из… если ваш показатель отказов 89% не оптимизируется для второго просмотра страницы. Сначала снизьте показатель отказов. Я действительно думаю, что определенно есть раскол, но я бы сказал, что большинство людей попадают не на ту сторону этой линии. Большинство людей помещают в клиент то, чего там быть не должно. CNN, например, вы не можете прочитать ни одного заголовка на веб-сайте CNN, пока он полностью не загрузит приложение JavaScript. Единственное, что отрисовывается сервером, — это верхний и нижний колонтитулы, а это единственное, что не волнует людей.

Гарри: И я чувствую, что это просто… Я не знаю, как мы пришли к этому моменту. Это никогда не будет лучшим вариантом. Вы предоставляете фактически бесполезную страницу, которая затем должна сказать: «Круто, я пойду принесу то, что могло бы быть веб-приложением, но мы собираемся запустить его в браузере, затем я пойду и попрошу заголовок , тогда вы можете начать… о, вы ушли. Меня это очень, очень раздражает.

Гарри: И в этом нет ничьей вины, я думаю, что такая экосистема JavaScript находится в зачаточном состоянии, шумиха вокруг нее, и, кроме того, это прозвучит очень резко, но… В основном это очень наивная реализация. Конечно, Facebook изобрел React и что бы там ни было, он работает на них. В девяти случаях из 10 вы не работаете в масштабах Facebook, в 95 случаях из 100 вы, вероятно, не самые умные инженеры Facebook, и это действительно, очень жестоко и звучит ужасно, но вы можете получить только… эти вещи быстрые по умолчанию. Вам нужна очень, очень элегантная реализация этих вещей, чтобы сделать их правильными.

Гарри: Я обсуждал это со своим старым… он был ведущим инженером в команде, в которой я работал 10 лет назад в Sky. Я говорил с ним на днях об этом, и ему пришлось очень много работать, чтобы сделать клиентское приложение быстрым, в то время как для быстрого серверного приложения вам не нужно ничего делать. Вам просто нужно не делать это снова медленно. И я чувствую, что здесь много розовых очков, наивности, маркетинга… Я звучу так мрачно, нам нужно двигаться дальше, пока я не начал терять здесь людей.

Дрю: Как вы думаете, есть ли у нас тенденция, как в отрасли, иногда уделять больше внимания опыту разработчиков, чем пользовательскому опыту?

Гарри: Не в целом, но я думаю, что проблема возникает там, где и следовало ожидать. Если вы посмотрите на несоответствие… Я не знаю, видели ли вы это, но я предполагаю, что вы, кажется, очень хорошо держите руку на пульсе, несоответствие между данными HTTP-архива о том, какие фреймворки и Библиотеки JavaScript используются в дикой природе по сравнению с состоянием опроса JavaScript, если вы проследите за состоянием опроса JavaScript, он скажет: «О да, 75% разработчиков используют React», тогда как менее 5% сайтов используют React. Итак, я чувствую, что в целом я не думаю, что это проблема, но я думаю, что в областях, которые вы ожидаете, например, сильная лояльность к одному фреймворку, опыт разработчиков… проповедуется, вероятно, раньше, чем пользователь. Я не думаю, что опыт разработчиков следует упускать из виду, я имею в виду, что у всего есть стоимость обслуживания. Твоя машина. При его разработке было принято решение: «Ну, если мы скроем этот ключ, эту функциональность от механика, то механику потребуется гораздо больше времени, чтобы исправить это, поэтому мы не делаем таких вещей». Так что должен быть баланс эргономики и удобства использования, я думаю, что это важно. Я думаю, что сосредоточение внимания в первую очередь на опыте разработчиков просто сбивает меня с толку. Не оптимизируйте для себя, оптимизируйте для своего клиента, ваш клиент платит вам, а не наоборот.

Дрю: Таким образом, онлайновая эхо-камера не совсем соответствует реальности, когда вы видите, как все говорят: «О, вам следует использовать это, вам следует делать это», то на самом деле это лишь очень небольшой процент людей.

Гарри: Верно, и это хорошо, это обнадеживает. Эхо-камера… Возможно, такая монокультура вредна для здоровья, если вы хотите ее так назвать. Но также я чувствую, что… и я видел это во многих своих работах, у многих разработчиков… Как консультант, я работаю с множеством разных компаний. Многие люди делают потрясающую работу в WordPress. А WordPress поддерживает 24% Интернета. И мне кажется, что для такого разработчика, который работает с чем-то вроде WordPress или PHP на бэкенде, пользовательским кодом, чем бы он ни был, может быть немного похоже на «О, я думаю, что все используют React, а мы нет». ", но на самом деле нет. Все говорят о React, но вы все еще плывете по течению, вы все еще с большинством. Довольно обнадеживающе найти молчаливое большинство.

Дрю: Тенденция к генераторам статических сайтов, а затем размещению сайтов полностью на CDN, своего рода подход JAMstack, я думаю, когда мы говорим о такого рода сайтах издательского типа, а не о сайтах программного типа, я думаю, что это действительно здоровая тенденция. , вы бы подумали?

Гарри: Мне это нравится, абсолютно. Вы помните, когда мы называли SSG «флап-файлом», верно?

Дрю: Ага.

Гарри: Итак, я создал CSS Wizardry на Jekyll еще тогда, когда Jekyll называли веб-сайтом с откидными файлами. 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-

Дрю: Ага.

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.

Гарри: Он внушал уважение, но он был одним из парней, нам всем он очень нравился. Но он был массивен во всех измерениях. Рост выше шести футов, но просто крупный парень. Большой, большой, большой, большой мужчина. И он сказал нам: «Если бы вам нужно было спроектировать дверной проем, вы бы спроектировали его для обычного человека?» И мозги 15-летнего подростка говорят: «Ну да, если все примерно 5 футов 9 дюймов, тогда да». Он такой: «Ну, немедленно, Гарри не может войти в эту дверь». Вы не проектируете для среднего человека, вы проектируете для крайностей, потому что вы хотите, чтобы это было полезно большинству людей. Если вы спроектируете стул для обычного человека, мистер Броклсби в него не поместится. Так что он учил меня с очень, очень возраста, дизайну до крайности.

Гарри: И где это становится действительно интересным в веб-перформансе, так это… Если вы представляете себе лестницу и поднимаете лестницу рядом с ботом… Хорошо, я только что понял, что моя метафора может… Я буду придерживаться ее, и вы можете смеяться над ней. я потом. Представьте себе лестницу, и вы поднимаете лестницу за нижние перекладины. И это ваш худший опыт. Вы выбираете нижнюю ступеньку лестницы, чтобы поднять ее. Вся лестница идет вместе с ней, как прилив плывет все лодки. Причина, по которой метафора не работает, заключается в том, что если вы поднимаете лестницу за верхнюю ступеньку, она тоже поднимается, это лестница. И эта метафора даже не сработает, если я превращу ее в веревочную лестницу, потому что тогда веревочная лестница, вы поднимаете нижнюю ступеньку, и ничего не происходит, но… я хочу сказать, что если вы можете улучшить опыт для своего 90-го процентиля, это должно получить это для вашего 10-го процентиля, не так ли?

Гарри: Вот почему я говорю клиентам, они говорят мне что-то вроде «О, ну, большинство наших пользователей используют 4G на iPhone», так что ладно, хорошо, и мы начинаем тестировать 3G на Android, типа «Нет, нет, большинство наших пользователей — айфоны». Хорошо… это означает, что ваш средний пользователь будет иметь лучший опыт, но любой, кто еще не находится в 50-м процентиле, просто останется позади. Поэтому установите для себя довольно высокую планку, установив довольно низкие ожидания.

Гарри: Прости, у меня очень плохая привычка давать очень длинные ответы на короткие вопросы. Но это был фантастический вопрос, и, подытоживая, я на 100% согласен с вами, что вы хотите посмотреть на этот длинный хвост, вы хотите посмотреть на это… ваш 80-й процентиль, потому что если вы возьмете весь опыт на сайт и посмотрите на медиану, и вы улучшите медиану, это означает, что вы сделали его еще лучше для людей, которые уже были вполне удовлетворены. Игнорирование 50% людей — неправильный подход. И да, это всегда возвращается к мистеру Броклсби, говорящему мне: «Не создавайте дизайн для обычного человека, потому что тогда Гарри не сможет использовать дверь». О, для всех, кто слушает, мой рост 193 сантиметра, так что я довольно долговязый, вот что это такое.

Дрю: И все эти руки и ноги.

Гарри: Ага. Вот еще один хороший. Моя девушка недавно открыла для себя настройки специальных возможностей в iOS… так что у всех телефоны на беззвучном режиме, верно? На самом деле ни у кого нет телефона, который действительно звонит, у всех он отключен. Она обнаружила, что «О, вы знаете, вы можете настроить его так, чтобы при получении сообщения мигала вспышка. И если вы дважды коснетесь задней панели телефона, он сделает снимок экрана». И это настройки специальных возможностей, они предназначены для этого 95-го процентиля. И все же она такая: «О, это действительно полезно».

Гарри: То же самое с OXO Good Grips. OXO Good Grips, кухонная утварь. У меня их полно на кухне. Они созданы потому, что у жены основателя был артрит, и он хотел сделать более удобную посуду. Он разработал для 99-го процентиля, у большинства людей нет артрита. Но, проектируя для 99-го процентиля, непреднамеренно все остальные думают: «Боже мой, почему все картофелечистки не могут быть такими удобными?» И я чувствую, что это очень, очень… Мне нравится хорошее настроение или анекдот, который я люблю использовать в подобных сценариях. Но да, если вы оптимизируете для них… Что ж, прилив плавает все лодки, и, следовательно, это оптимизирует конечную часть людей, и вы получите много еще более счастливых клиентов сверх этого.

Дрю: У вас есть ручной ручной венчик OXO Good Grips?

Гарри: Не знаю. Я нет, это хорошо?

Дрю: Посмотри на это. Это так хорошо.

Гарри: У меня есть мандолинорезка OXO Good Grips, которая на прошлой неделе отрезала мне кончик пальца.

Дрю: Да, я не буду приближаться ни к одному из них.

Гарри: Да, это моя глупая ошибка.

Дрю: Еще один пример из моего собственного опыта работы с «длинным хвостом»: в проекте, над которым я сейчас работаю, этот «длинный хвост» находится в самом конце, у вас есть люди с самой низкой производительностью, но если вы посмотрите, кто эти клиенты, окажется, что они самые ценные клиенты для бизнеса...

Гарри: Хорошо.

Дрю: …потому что это крупнейшие организации с наибольшим объемом данных.

Гарри: Верно.

Дрю: И поэтому они сталкиваются с узкими местами, потому что у них так много данных для отображения на странице, и эти страницы нужно немного рефакторить, чтобы помочь этому варианту использования. Таким образом, у них самый медленный опыт, и они, когда дело доходит до этого, платят больше всего денег и приносят гораздо больше пользы, чем все люди, имеющие действительно быстрый опыт, потому что они бесплатные пользователи с небольшое количество данных, и все это работает хорошо и быстро.

Гарри: Захватывающее измерение, не правда ли? На самом деле, у меня было похожее… Я не имел ничего общего с тем влиянием на бизнес, которое вы только что описали, но пару лет назад я работал с клиентом, и их генеральный директор связался с вами, потому что их сайт работал медленно. Типа, медленно, медленно, медленно. Очень хороший парень, он просто очень хороший приземленный парень, но у него есть наставничество, как у настоящего богача. И у него есть последний iPhone, он может себе это позволить. Он мультимиллионер, он проводит много времени, летая между Австралией, откуда он родом, и Эстонией, где он сейчас живет.

Гарри: И он летит первым классом, конечно. Но это означает, что большую часть времени он проводит на своем красивом, блестящем iPhone 12 Pro Max, что бы там ни было, через Wi-Fi в самолете, что ужасно. И это было действительно удивительное сопоставление, когда он владеет сайтом и часто его использует, это сайт, который он использует. И он настаивал на этом… Я имею в виду, что их самым богатым клиентом был их генеральный директор. И он находится в этом странном привилегированном положении, где у него худшие связи, чем у Джо Паблика, потому что он где-то над Сингапуром на рейсе Quantas, где ему наливают шампанское, и он борется. И это было действительно захватывающее открытие, которое… О да, потому что у вас есть 95-й процентиль, который может в основном идти в любом направлении.

Дрю: Да, когда вы начинаете оптимизировать сайт с бокалом шампанского в одной руке, вы думаете: «Может быть, мы начинаем немного сбиваться с пути».

Гарри: Да, точно.

Дрю: Мы немного поговорили об измерении производительности, и по моему собственному опыту работы с производительностью очень важно измерять каждую часть. вы делаете другой и насколько большую разницу вы делаете. Как мы должны измерять эффективность наших сайтов? Какие инструменты мы можем использовать и с чего начать?

Гарри: О боже, еще один отличный вопрос. Таким образом, существует ряд ответов в зависимости от того, сколько времени, ресурсов и склонности к исправлению скорости сайта. Итак, что я попытаюсь сделать с клиентом, так это… Некоторые стандартные показатели действительно хороши. Время загрузки, не беспокойтесь об этом больше. Это очень, очень, очень... Я имею в виду, это хороший прокси, если время загрузки 120 секунд, я предполагаю, что у вас не очень быстрый веб-сайт, но он слишком непонятен и не совсем ориентирован на клиента. На самом деле я думаю, что Vitals — это действительно хороший шаг в правильном направлении, потому что они измеряют пользовательский опыт, но они основаны на технической информации. Largest Contentful Paint — это действительно хорошая визуальная вещь, но техническая составляющая разблокирует ваш критический путь, убедитесь, что основные изображения появляются быстро, и убедитесь, что ваша стратегия веб-шрифтов достойна. В этих показателях есть техническая подоплека. Они действительно хороши с полки.

Гарри: Однако, если у клиентов есть время, обычно это время, потому что вы хотите собрать данные, но вам нужно время, чтобы на самом деле собрать данные. Так что я стараюсь делать с клиентами следующее: «Послушайте, мы не можем работать вместе в течение следующих трех месяцев, потому что я полностью занят. Итак, что мы можем сделать, так это очень быстро предоставить вам бесплатную пробную версию Speedcurve, настроить некоторые пользовательские показатели», так что это означает, что для клиента издателя, газеты, я буду измерять «Как быстро появился заголовок статья вынесена? Как быстро было отрисовано главное изображение для статьи?» Для клиента электронной коммерции я хочу измерить, потому что, очевидно, вы измеряете такие вещи, как пассивный запуск рендеринга. Как только вы начинаете использовать любое программное обеспечение для мониторинга производительности, вы бесплатно фиксируете свои фактические показатели производительности. Итак, ваша первая содержательная краска, самая большая содержательная краска и т. д. Что я действительно хочу зафиксировать, так это то, что важно для них как для бизнеса.

Гарри: Итак, работая с клиентом E-Com в тот момент, когда мы можем сопоставить… Чем быстрее ваш стартовый рендер, какова вероятность добавления в корзину. Если вы сможете показать им товар раньше, они с большей вероятностью его купят. И это требует больших усилий для настройки, это своего рода сложная цель для клиентов, которые действительно амбициозны, но все, что вы действительно хотите измерить, потому что, как я уже сказал, вы на самом деле не хотите измерять то, что ваш самый большой Contentful Paint: вы хотите измерить свой доход, и повлиял ли на него Large Contentful Paint? Таким образом, конечной целью может быть все, что вы видите в качестве KPI для этого бизнеса. Это может быть в газетах, как далеко кто-то прокрутил статью? И это как-то коррелирует с задержкой первого ввода? Читали ли люди больше статей, если CLS был ниже? Но затем, прежде чем мы начнем создавать настраиваемые метрики, я искренне думаю, что Web Vitals — это действительно хорошее место для начала, и оно также довольно хорошо нормализовано. Это становится… Я не знаю, что это за слово. Наименьший общий знаменатель, я думаю, где каждый в отрасли теперь может обсуждать производительность на этом игровом поле.

Гарри: У меня есть одна проблема, и мне действительно нужно организовать встречу с командой жизненно важных органов. Я действительно считаю, что Lighthouse — это здорово, но CLS — это 33% веб-жизненных показателей. У вас есть LCP, FID, CLS. CLS составляет 33% ваших жизненно важных функций. Жизненные показатели — это то, что обычно предстает перед вашей маркетинговой командой, вашим отделом аналитики, потому что они всплывают в поисковой консоли, упоминаются в контексте страниц результатов поиска, в то время как жизненно важные показатели имеют большой вес, 33%, треть жизненно важных показателей - это CLS, это всего 5% от нашего показателя Lighthouse. Итак, вы получите разработчиков, которые строят Lighthouse, потому что его можно интегрировать в инструменты, это лабораторная метрика. Жизненно важные данные - это полевые данные, это ром.

Гарри: Итак, вы столкнулись с огромным разрывом, когда ваша маркетинговая команда говорит: «CLS — это очень плохо», а разработчики думают: «Ну, это 5% от оценки Lighthouse, которую мне дает DevTools, это 5% от оценки». что Lighthouse CLI дает нам в CircleCI» или что-то еще, что вы используете, но для маркетинговой команды это 33% того, что их волнует. Таким образом, проблема заключается в некотором разрыве, потому что я действительно думаю, что Lighthouse очень ценен, но я не знаю, как они примиряют эту довольно огромную разницу, когда в жизненно важных показателях CLS составляет 33% от вашей оценки… ну, не оценка, потому что вы на самом деле его нет, а Lighthouse составляет всего 5%, и подобные вещи все еще нуждаются в сглаживании, прежде чем мы сможем сделать это обсуждение плавным.

Гарри: Но, опять же, длинный ответ на короткий вопрос. Витал действительно хорош. LCP — это хороший показатель пользовательского опыта, который можно свести к техническим решениям, как и в случае с CLS. Так что я думаю, что это действительно хорошая отправная точка. Кроме того, это пользовательские метрики. Я пытаюсь довести своих клиентов до точки, когда им все равно, насколько быстр их сайт, они просто заботятся о том, чтобы заработать больше денег со вчерашнего дня, и если это так, то это потому, что он работал быстро? Если он сделал меньше, это потому, что он работал медленнее? Я не хочу, чтобы они гнались за мистическим двухсекундным LCP, я хочу, чтобы они гнались за оптимальным LCP. И если это на самом деле окажется медленнее, чем вы думаете, то как бы то ни было, это нормально.

Дрю: Итак, для веб-разработчика, который просто интересуется… у него нет бюджета, чтобы тратить его на такие инструменты, как Speedcurve и тому подобное, они, очевидно, могут запускать такие инструменты, как Lighthouse, прямо в своем браузере, чтобы получить хорошие измерения… Такие вещи, как Google Аналитика полезна для этого уровня?

Гарри: Да, и их можно сделать более полезными. Аналитика уже много лет собирает элементарную информацию о производительности. И это будет время DNS, TCP и TLS, время до первого байта, время загрузки страницы, которое является прокси… ну, что угодно, просто время загрузки страницы и время загрузки. Так что довольно неуклюжие показатели. Но это хорошая отправная точка, и обычно каждый проект, который я начинаю с клиентом, если у него нет New Relic или Speedcurve или чего-то еще, я просто говорю: «Хорошо, дайте мне взглянуть на вашу аналитику», потому что я могу как минимум проксировать ситуацию оттуда. И он никогда не будет так же хорош, как Speedcurve, New Relic, Dynatrace или что-то в этом роде. Вы можете очень, очень, очень легко отправлять пользовательские метрики в аналитику. Если кто-то слушает, хочет иметь возможность отправить ... мой сайт, например. У меня есть такие показатели, как «Как быстро вы можете прочитать заголовок одной из моих статей? В какой момент было отображено изображение страницы «О программе»? В какой момент был призыв к действию, который умолял вас нанять меня? Как скоро это появится на экране?» Действительно тривиально собрать эти данные и почти так же тривиально отправить их в аналитику. Поэтому, если кто-то захочет просмотреть исходный код на моем сайте, прокрутите вниз до закрывающего тега body и найдите фрагмент аналитики, вы увидите, насколько легко мне собирать пользовательские данные и отправлять их в аналитику. А в пользовательском интерфейсе аналитики ничего делать не нужно. Обычно вам нужно настраивать пользовательские отчеты, анализировать данные и приводить их в презентабельный вид. Это граждане первого класса в Google Analytics. Таким образом, в тот момент, когда вы начинаете собирать пользовательскую аналитику, ей посвящен целый раздел панели инструментов. В самой GA нет настройки, нет тяжелой работы, так что это действительно тривиально, и, если у клиентов есть реальный бюджет или, может быть, я хочу показать им силу пользовательского мониторинга, я не хочу говорить: «О да, я обещаю это будет очень хорошо, можно мне просто 24 штуки на Speedcurve?» Я могу начать с того, что просто скажу: «Послушайте, это элементарно. Давайте посмотрим на возможности здесь, теперь мы, возможно, сможем убедить вас перейти на что-то вроде Speedcurve».

Дрю: Я часто обнаруживал, что мое внутреннее чутье относительно того, насколько быстро что-то должно быть или какое влияние должно иметь изменение, может быть ошибочным. Я вношу изменения и думаю, что делаю вещи быстрее, а затем измеряю их, и на самом деле я делаю вещи медленнее. Это только я плохо разбираюсь в вебе?

Гарри: Вовсе нет. У меня есть действительно подходящий пример этого. Предварительная загрузка… очень краткое введение для тех, кто не слышал о предварительной загрузке, загрузка определенных ресурсов в Интернете по своей природе очень медленная, и два основных кандидата здесь — фоновые изображения в CSS и веб-шрифты, потому что, прежде чем вы сможете загрузить фоновое изображение, у вас есть чтобы загрузить HTML, который затем загружает CSS, а затем CSS говорит: «О, этому div на главной странице нужно это фоновое изображение». Так что это по своей сути очень медленно, потому что у вас есть весь этот кусок времени CSS между ними. С предварительной загрузкой вы можете поместить одну строку в HTML в теге head, которая говорит: «Эй, ты еще этого не знаешь, но, поверь мне, тебе очень, очень, очень скоро понадобится это изображение». Таким образом, вы можете поместить предварительную загрузку в HTML, которая упреждающе запускает эту загрузку. К тому моменту, когда CSS требуется фоновое изображение, он говорит: «О, круто, у нас оно уже есть, это быстро». И это преподносится как этот веб-перф Мессия… Вот в чем дело, и я обещаю вам, я написал это в Твиттере на прошлой неделе, и с тех пор я дважды оказался прав. Люди слышали о предварительной загрузке и обещаниях, которые она дает, а также о том, что Lighthouse очень сильно продвигает ее, теоретически она делает ваш сайт быстрее. Люди так увлеклись идеей предварительной загрузки, что даже когда я могу доказать, что она не работает, они не удалят ее снова. Потому что «Нет, но Маяк сказал». Теперь это одна из тех вещей, где теория звучит. Если вам нужно дождаться своего веб-шрифта, а не загружать его раньше, вы увидите материал быстрее. Проблема в том, что когда вы думаете о том, как на самом деле работает Интернет, о любой странице, на которую вы впервые заходите, о любом совершенно новом домене, который вы открываете, у вас есть конечная пропускная способность, и браузер очень разумно расходует эту пропускную способность правильно. Он очень быстро просмотрит ваш HTML-код и составит список покупок. Самое главное — это CSS, затем этот jQuery, затем этот… и затем следующие несколько вещей — это, это и это менее приоритетно. Как только вы начинаете загружать свой HTML с предварительной загрузкой, вы говорите браузеру: «Нет, нет, нет, это больше не твой список покупок, приятель, это мой. Тебе нужно пойти и взять это». Этот конечный объем пропускной способности по-прежнему конечен, но он не тратится на большее количество ресурсов, поэтому все становится немного медленнее. И мне пришлось освистывать это дважды за последнюю неделю, и все равно люди говорят: «Да, но нет, это потому, что он загружается раньше». Нет, он запрашивается раньше, но крадет пропускную способность вашего CSS. Вы можете буквально видеть, что ваши веб-шрифты крадут пропускную способность вашего CSS. Так что это одна из тех вещей, где вы должны, должны, должны следовать цифрам. Я делал это раньше на крупномасштабном клиенте. Если вы слушаете это, вы слышали об этом клиенте, и я был весьма настойчив в том, что «Нет, нет, ваши теги заголовков расположены в неправильном порядке, потому что так и должно быть, и вам нужно, чтобы они были в таком порядке». порядка, потому что теоретически это намекает на то, что…» Даже по тому, чем я был для клиента, я знал, что выставляю себя дураком. Из-за того, как работают браузеры, он должен быть быстрее. Итак, я делаю уловку, это изменение… для многих миллионов людей, и оно становится медленнее. Стало медленнее. И я сижу там, возмущенно твердя: «Нет, но браузеры так работают» — бесполезно, потому что это не работает. И мы отменили это, и я такой: «Извините! Все равно выставлю вам за это счет! Так это вообще не ты.

Дрю: Следуйте этим цифрам.

Гарри: Да, точно. «На самом деле я должен брать с вас больше, потому что я потратил время, чтобы вернуть его, заняло у меня больше времени». Но да, вы абсолютно правы, это не вы, это одна из тех вещей, где… Я делал это много раз в гораздо меньшем масштабе, когда я говорил: «Ну, теоретически это должно работать», и это не работает. 'т. Вам просто нужно следить за тем, что происходит в реальном мире. Вот почему этот мониторинг действительно важен.

Дрю: По мере изменения ландшафта и развития технологий Google внедряет новые технологии, которые помогают нам работать быстрее. Есть ли хороший способ не отставать от изменений? Есть ли какие-либо ресурсы, на которые мы должны обратить внимание, чтобы поддерживать наши навыки в актуальном состоянии, когда дело доходит до веб-производительности?

Гарри: Чтобы быстро рассказать обо всем «производстве Google»… Я знаю, что это немного иронично, но я собираюсь сосредоточиться на этом. Я думаю, прямо к началу, ставка на браузер. Например, такие вещи, как AMP, в лучшем случае являются запоздалым решением. Ничто не заменит создание быстрого сайта, и в тот момент, когда вы начинаете использовать такие вещи, как AMP, вам приходится придерживаться этих нестандартных стандартов, милость команды AMP передумала. У меня был клиент, который потратил целое состояние на лицензирование шрифта у поставщика шрифтов из разрешенного списка AMP, затем в какой-то момент AMP решил: «О, на самом деле нет, этот шрифт предоставлен, мы собираемся заблокировать их сейчас». Итак, у меня был клиент. который вложил значительные средства в AMP и этого поставщика шрифтов и должен был выбрать: «Ну, отменить всю работу AMP или мы просто тратим впустую это очень большое число в год на веб-шрифт» бла, бла, бла. Так что я бы очень настороженно относился к любому из них… Я эксперт Google Developer, но я не знаю ни одного запрета на затыкание рта… Я могу быть критическим, и я бы сказал… избегайте вещей, которые приветствуются как однозначные универсальное решение, например, AMP.

Гарри: И чтобы на секунду сбросить кого-то еще, у Cloudflare есть штука под названием Rocket Loader, которая в своем стремлении напоминает AMP. Он разработан так: «О, просто включите эту штуку в свой CDN, это сделает ваш сайт быстрее». И на самом деле это просто замена для правильного создания вашего сайта в первую очередь. Итак… чтобы разобраться с этим аспектом, постарайтесь оставаться как можно более независимым, знать, как работают браузеры, что сразу же означает, что монокультура Chrome, вы снова на коленях у Google, но знаете, как работают браузеры, придерживайтесь некоторых фундаментальных идеологий. Когда вы создаете сайт, посмотрите на страницу. Будь то в Figma, Sketch или где бы то ни было, посмотрите на дизайн и скажите: «Ну, это то, что пользователь хочет увидеть в первую очередь, поэтому я ничего не буду этому препятствовать. Я не буду лениво загружать это основное изображение, потому что это глупо, зачем мне это делать?» Так что просто подумайте: «Что бы вы хотели, чтобы пользователь сделал в первую очередь?» На сайте E-Com это будет изображение продукта, вероятно, одновременное с навигацией, но обзоры продукта, вопросы и ответы о продукте, ленивая загрузка этого. Спрячьте это за JavaScript.

Гарри: Определенные фундаментальные способы работы, которые пригодятся вам независимо от того, о какой технологии вы читаете, а именно: «Расставьте приоритеты по приоритетам вашего клиента». Выполнение дополнительной работы над этим было бы быстрее, так что не мешайте этому, а затем больше тактических вещей, чтобы люди знали, чтобы быть в курсе… и снова, прямо в Google, но web.dev оказывается феноменальным ресурсом для независимой от фреймворка и стека информации… Так что, если вы хотите узнать о жизненно важных функциях, вы хотите узнать о PWA, так что web.dev действительно великолепен.

Гарри: На самом деле очень мало публикаций, ориентированных на производительность. Электронная почта Калибра, я думаю, что ее двухнедельная электронная почта просто феноменальна, это действительно хороший дайджест. Следите за веб-платформой в целом, так что есть Рабочая группа по производительности, у них есть масса предложений по предложениям GitHub. Опять же, вернемся к Google, но никто не знает об этом феноменальном веб-сайте: chromestatus.com. Он точно сообщает вам, над чем работает Chrome, какие сигналы поступают от других браузеров, поэтому, если вы хотите увидеть, как обстоят дела с подсказками приоритета, вы можете пойти и получить ссылки на все соответствующие средства отслеживания ошибок. Chrome Status показывает вам вехи для каждого… «Это выходит в MAT8, это было выпущено в 1967 году» или что-то в этом роде, это действительно хорошо для технических идей.

Гарри: Но я постоянно возвращаюсь к этому, и я знаю, что это звучит как «Старик кричит на Клауда», но придерживаюсь основ, почти каждый фунт или доллар, евро, который я когда-либо зарабатывал, учил клиентов. что «Вы знаете, что браузер уже делает это, верно» или «Вы знаете, что это невозможно сделать быстрее», и это звучит очень праведно с моей стороны… Я никогда не зарабатывал ни цента на продаже дополнительных технологий. Каждый бит денег, который я зарабатываю, связан с удалением, вычитанием. Если вы обнаружите, что добавляете что-то, чтобы сделать ваш сайт быстрее, вы в неправильном направлении.

Гарри: Дело в том, что я не буду называть… крупную рекламную/поисковую/браузерную компанию, не буду называть их, и я не буду называть JavaScript-фреймворк, но сейчас я обсуждения с очень, очень большой, очень популярной средой JavaScript об удалении того, что активно вредит, или, возможно, об удалении того, что может повредить производительности огромного количества веб-сайтов. И они сказали: «О, мы собираемся подключиться…» к кому-то из этой крупной компании, потому что они провели некоторое исследование… и это типа «Нам нужна возможность удалить эту штуку, потому что вы можете видеть здесь, и здесь, и здесь это делает этот сайт медленнее ». И их решение состояло в том, чтобы добавить больше, например: «О, но если вы сделаете и это, то вы можете обойти это» и что-то вроде «Нет, нет, добавление большего количества, чтобы сделать сайт быстрее, должно быть неправильным решением. Конечно, вы можете увидеть, что движетесь в неправильном направлении, если требуется больше кода, чтобы в итоге получить более быстрый сайт».

Гарри: Потому что с самого начала это было быстро, и все, что вы добавляете, делает его медленнее. И идея добавить больше, чтобы сделать его быстрее, хотя… это может проявиться в более быстром веб-сайте, это неправильный подход. Это гонка на выживание. Извините, я очень разозлился, вы можете сказать, что я не разглагольствовал какое-то время. Другое дело, если вы обнаружите, что добавляете функции, чтобы сделать сайт быстрее, вы, вероятно, движетесь в неправильном направлении, гораздо эффективнее сделать быстрее, удаляя вещи, чем добавляя их.

Дрю: Вы подготовили видеокурс под названием «Все, что я сделал, чтобы сделать CSS Wizardry быстрым».

Гарри: Да!

Дрю: Это немного отличается от традиционных онлайн-видеокурсов, не так ли?

Гарри: Это так. Я буду честен, это отчасти… Я не хочу говорить о лени с моей стороны, но я не хотел разрабатывать учебную программу, которая должна была быть очень жесткой и вести вас от нуля до героя, потому что на это уходит время. огромен, и время, которое я не знал, было бы у меня. Итак, что я хотел, так это иметь готовый материал, просто сделать скриншот, как я говорю через него, чтобы он не начинался с «Вот браузер, и вот как он работает», так что вам нужно, по крайней мере, знать основы веб-производительности, но это лайфхаки, профессиональные советы и примеры из реальной жизни.

Гарри: И поскольку мне не нужно было проходить полный курс обучения, я смог значительно снизить цену. Так что это не большой 10-часовой курс, который проведет вас от нуля до героя, это то, что вы считаете нужным. По сути, это просто просмотр моего сайта, который является отличной площадкой для вещей, которые нестабильны или… для меня очень низкий риск экспериментировать там. Так что я только что сделал серию видео. Было очень весело записывать. Просто снести свой собственный сайт и говорить о том, «Вот как это работает, и вот как вы могли бы это использовать».

Дрю: Я думаю, это действительно здорово, что она разделена на решение разных проблем. Если я хочу узнать больше об оптимизации изображений или о чем-то еще, я могу подумать: «Хорошо, что мой приятель Гарри может сказать об этом?», погрузиться в видео об изображениях и уйти. Таким образом, это действительно доступно, вам не нужно часами просиживать за вещами, вы можете просто перейти к той части, которую хотите, и выучить то, что вам нужно, а затем уйти.

Гарри: Я думаю, что пытался сохранить его больше… Преимущество отсутствия жесткой учебной программы в том, что вам не нужно сначала смотреть определенное видео, нет вступления, это просто «Иди, осмотрись и посмотри, что тебе интересно». это означало, что кто-то, страдающий от проблем с LTP, говорил: «О, хорошо, мне нужно погрузиться в эту папку здесь», или если у него проблемы с CSS, он может погрузиться в эту папку. Очевидно, что у меня нет статистики, но я полагаю, что на курсах высокий уровень отказов, просто потому, что вам нужно тащиться через три часа введения на случай, если вы что-то пропустите, и это похоже на «О, знаете что, я не могу продолжайте делать это каждый день», и люди могут просто отказаться от многих курсов. Так что я думал просто погрузиться, вам не нужно смотреть предыдущие три часа, вы можете просто пойти и найти все, что захотите. И обратная связь была очень, очень... На самом деле, что я сделаю, так это то, что ее еще не существует, но я сделаю это сразу после звонка, любой, кто использует код скидки SMASHING15, получит скидку 15%. этого.

Дрю: Получается, что вы оптимизировали сам курс по производительности, потому что вы можете сразу перейти к той части, которую хотите, и вам не нужно вести все переговоры и…

Гарри: Да, непреднамеренно, но я возьму это на себя.

Дрю: Итак, я узнал все о веб-производительности, о чем ты узнал в последнее время, Гарри?

Гарри: Технические вещи… не совсем. У меня много чего в моем списке того, что нужно изучить, так что QUIC, H3, я хотел бы получить немного больше практических знаний об этом, но я написал электронную книгу во время первого карантина в Великобритании, поэтому я узнал как делать электронные книги, что было очень весело, потому что это всего лишь HTML и CSS, и я знаю, как это сделать, так что это было очень весело. Я научился очень элементарному редактированию видео для курса, и что мне понравилось, так это то, что это не концептуальная работа. Очевидно, что изучая язык программирования, вы должны бороться с понятиями, в то время как изучение электронной книги было просто рабочим процессом и… тем, с чем я никогда раньше не возился, так что учиться было интересно, но это не требовало смены карьеры. , так что это было довольно приятно.

Гарри: И потом, нетехнические вещи… Я много езжу на велосипедах, я часто падаю с велосипедов… и поскольку я вообще не путешествовал с марта прошлого года, то есть уже почти год, я делаю намного больше. ездить на велосипеде и уделять больше внимания… улучшению этого. Итак, я провел множество исследований выходной мощности и функциональных пороговых мощностей, в данный момент я выполняю тренировочную программу, поэтому постоянно, постоянно утомляю ноги, но я много узнаю о физиологии во время езды на велосипеде. Я не знаю почему, потому что у меня нет планов делать что-либо с ним, кроме как продолжать кататься. Это было действительно увлекательно. Я чувствую, что мне очень повезло во время карантина, во множественном числе, но мне удалось оставаться активным. Многие люди упускают такие простые вещи, как ежедневные поездки в офис, хороший шанс размять ноги. В Великобритании, как вы знаете, езда на велосипеде очень пропагандируется, поэтому я гораздо больше возился с изучением езды на велосипеде с более физиологической точки зрения, что означает… не знаю, просто быть ботаником. что-то еще для разнообразия.

Дрю: Возможно, не так уж и велика разница между оптимизацией производительности в сети и оптимизацией производительности в велоспорте, это все предельные выгоды, верно?

Гарри: Да, точно. И количество графиков, которые я просматривал на велосипеде… У меня есть данные о мощности велосипеда, я выхожу на прогулку и возвращаюсь со словами: «О, если бы у меня было еще пять ватт, но я сэкономил 10». ватт, я мог бы сделать это, это и это быстрее всех» и… был огромен по этому поводу. Но да, ты прав. Знаешь что, я думаю, ты наткнулся на что-то действительно интересное. Я думаю, что такие вещи — хороший вид спорта/развлечения для тех, кто немного одержим, кому нравится гоняться за цифрами. Есть вещи, я имею в виду, что вы это знаете, но, Strava, у вас есть свои KOM. В прошлом году я собрал 19 из них, что для меня феноменальное количество. И это почти все из-за одержимости доступными данными и взгляда на «Этот парень, которого я пытаюсь победить, он выдавал 700 ватт в этот момент, если бы я мог подняться до 1000, а затем затихнуть» и бла, бла, бла … это навязчиво. Ботан. Но вы правы, я думаю, это нечто похожее, не так ли? 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.

Гарри: Ага. 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.