009. Performance - Иван Карев, Андрей Морозов, Михаил Мокрушин, Андрей Роенко, Тамерлан Локьяев
Вставка
- Опубліковано 6 вер 2024
- Поговорим о том, на что нужно обратить внимание при анализе производительности сайта. Покажем несколько примеров оптимизаций на наших сервисах, а также обсудим влияние рекламы и расширений на скорость загрузки страниц.
18:42 О *14 килобайтах*
Каждый раз когда мне везет на кого-то, кто начинает рассуждать на тему 14 килобайт в аспекте -
"да это наверняка все не так, а если так, то сетевой администратор наверняка сменил настройки, и значит опять все не так"
я задаю один вопрос - а почему Вам было сложно это проверить?
*Почему Вам было сложно убедиться в том что:*
A) что вообще по сути обсуждают в теме 14 килобайт
B) когда разобрались в TCP slowStart, и поняли, что таки да - возможно, почему не проверили хотя бы на уровне своего локалхоста?
C) когда проверили и увидели, что блин оно таки работает, почему не попытались проверить это на уровне своего провайдера?
И так далее.
_Сетевой администратор дейтсвительно может влиять на эти 14килобайт. Но только не в сторону уменьшения, а наоборот_
А ответ очень простой. Потому что никто такими оптимизациями заниматься не хочет.
Все хотят сделать мало и получить много.
Где это видано чтобы сейчас страница исполняющая какую то полезную работу, в сжатом виде со всеми стилями и JS логикой
состояла из 14 килобайт? (на самом деле еще меньше)
И в подобных рассуждениях есть очень много правды. Почему? Потому что чаще всго, у страницы есть другие проблемы, решение которых принесет намного больше пользы, чем попытка вложиться в 14K.
Исключение если вы яндекс со странице из одного инпута.
*Так стоит или не стоит?*
Стоит, когда все остальные проблемы страницы решены.
А это условие, в текущих реалиях, чаще всего выполнить возможно.
22:26 *defer или async*
На самом деле правильный ответ и не то и не другое.
Это два костыля, которые никаким образом сейчас, в случае если вы хотите контролировать ситуацию Вам не помогут. Потому как, в тот момент, когда вы ставите либо defer или async вы как тот страус который засовывает голову в песок с криком "aaaaaaaa" авось пронесет.
Невозможно сейчас строить производительные страницы, не решая самостоятельно вопрос нагрузки создаваемой JS логикой. То есть когда Вы поставили defer или async вы стали играть в лотерею, в которой от Вас уже ничего не зависит.
Вынося за скобки вышеописанную прохладную историю, мне интересно, откуда докладчик взял что они работают в разных браузерах по разному?
Все браузеры вышедшие с начала 2014 года, одинаковым образом реализует defer. По крайней мере в той части коотрая больше всех беспокоит. Те что вышли раньше имеют особенности, но завбано то, что все эти особенности работают скорее в плюс чем в минус.
С async все еще проще. Во первых он вам нафиг ненужен в решении этой задачи, а во вторых прогноз его работы еще надежнее чем у дефер.
1:20:53 Не понимаю картинку. Как так вышло что iphone8 быстрее MacBook Pro 2015 Года?
Это чушь какая то, специально взял старенький i3 intel которому уже больше 10 лет, и он совершенно логично обогнал iphone даже без точных замеров. Как мог mac проиграть?