Why I’m excited with React Hooks?. Да, снова хуки). Обзор 3 базовых хуков на примере таймера → http://bit.ly/2IqziAf
Forwarded from Жабаскрипт (веде Віктор Турський)
Почти всегда, при разговоре о производительности веб-сайта, мы говорим о времени ожидания пользователем какого-то события ("First Meaningful Paint" и тд). Мы часто обсуждаем оптимизации фронтенда и бэкенда. И это круто, но остается корень всех бед - скорость света. Часто JavaScript разработчики упускают это проблему из виду 😀
Может ли случится такое, что через 30 лет Интернет будет настолько быстрым, что сайт с сервера в Сан-Франциско будет моментально открываться в Киеве? Физики говорит, что нет.
Допустим:
1. Твой бекенд рендерит страницу (или формирует JSON) за 20мс.
2. Не существует никакого WiFi, провайдеров, маршрутизации и тд. Есть просто оптоволоконный кабель, который одним концом вставлен в твой ноутбук, а вторым напрямую в сервер в Сан-Франциско. Растояние по прямой от Киева до Сан-Франциско - 9,848км (возьмем 10 тыс км для простоты счета).
3. Скорость света в вакуме 300 тыс км в секунду, скорость света в оптоволокне будет ниже - 200 тыс км в секунду.
Если мы посчитаем время, которое проведет наш запрос в пути, то мы получим 100 мс (10 тыс / 200 тыс * 2). Быстрее получить ответ не позволит скорость света. Добавляем время оработки запроса и мы получим 120мс - в 6 раз дольше, чем наш запрос обрабатывает наш бэкенд.
Хорошо, мы уже выяснили, что никогда не поиграем в CS:GO с ребятами с Сан-Франциско с пингом ниже 100мс. Давайте дальше :)
Перед тем как запросить данные с сервера мы должны установить сетевое соединение. Протокол HTTP работает поверх TCP, следовательно нам нужно TCP соединение с сервером.
Для установки TCP соедения используется так называемое "тройное рукопожатие" ("TCP 3-way handshake") и теперь наш запрос выглядит:
Мы не тратим дополнительные 50ms после TCP хендшейка, поскольку мы можем сразу начать отправлять запрос после отправки ack, нам не нужно ждать ответ от сервера. Сервер, как примет ack, посчитает соединение открытым и сразу начнет обрабатывать наш запрос.
То есть ответ пользователь получит через 220ms, в 11 раз дольше, чем отрабатывал наш бэкенд.
Но мы используем HTTPS и нам нужно SSL/TLS соединение и оно устанавливается поверх TCP, и у него есть свой механизм рукопожатия для обменя ключами шифрования, и это нужно сделать до момента, как мы отправим наш запрос на сервер.
Наша схема превращается в:
То есть в условиях, которые не могут даже существовать, когда пользователь имеет оптоволоконный кабель длинной в 10тыс км от своего ноутбука к серверу, он получит ответ через 420мс, в 21 раз дольше чем отрабатывает наш бэкенд. Это без учета того, что нам нужно еще вначале сбегать к DNS, чтобы получить ip-адрес сервера.
Если мы разрабатываем веб-приложения (не важно фронтенд или бекэнд), то обязаны понимать азы работы веба.
Продолжение следует...
Может ли случится такое, что через 30 лет Интернет будет настолько быстрым, что сайт с сервера в Сан-Франциско будет моментально открываться в Киеве? Физики говорит, что нет.
Допустим:
1. Твой бекенд рендерит страницу (или формирует JSON) за 20мс.
2. Не существует никакого WiFi, провайдеров, маршрутизации и тд. Есть просто оптоволоконный кабель, который одним концом вставлен в твой ноутбук, а вторым напрямую в сервер в Сан-Франциско. Растояние по прямой от Киева до Сан-Франциско - 9,848км (возьмем 10 тыс км для простоты счета).
3. Скорость света в вакуме 300 тыс км в секунду, скорость света в оптоволокне будет ниже - 200 тыс км в секунду.
Если мы посчитаем время, которое проведет наш запрос в пути, то мы получим 100 мс (10 тыс / 200 тыс * 2). Быстрее получить ответ не позволит скорость света. Добавляем время оработки запроса и мы получим 120мс - в 6 раз дольше, чем наш запрос обрабатывает наш бэкенд.
========= Запрос к бэкенду ======
50ms: Kyiv -------запрос-----> SF
20ms: работа бэкенда
50ms: Kyiv <------ответ------- SF
Хорошо, мы уже выяснили, что никогда не поиграем в CS:GO с ребятами с Сан-Франциско с пингом ниже 100мс. Давайте дальше :)
Перед тем как запросить данные с сервера мы должны установить сетевое соединение. Протокол HTTP работает поверх TCP, следовательно нам нужно TCP соединение с сервером.
Для установки TCP соедения используется так называемое "тройное рукопожатие" ("TCP 3-way handshake") и теперь наш запрос выглядит:
========= TCP соединение ========
50ms: Kyiv -------syn--------> SF
50ms: Kyiv <------syn/ack----- SF
50ms: Kyiv -------ack--------> SF
========= Запрос к бэкенду ======
Kyiv -------запрос-----> SF
20ms: работа бэкенда
50ms: Kyiv <------ответ------- SF
Мы не тратим дополнительные 50ms после TCP хендшейка, поскольку мы можем сразу начать отправлять запрос после отправки ack, нам не нужно ждать ответ от сервера. Сервер, как примет ack, посчитает соединение открытым и сразу начнет обрабатывать наш запрос.
То есть ответ пользователь получит через 220ms, в 11 раз дольше, чем отрабатывал наш бэкенд.
Но мы используем HTTPS и нам нужно SSL/TLS соединение и оно устанавливается поверх TCP, и у него есть свой механизм рукопожатия для обменя ключами шифрования, и это нужно сделать до момента, как мы отправим наш запрос на сервер.
Наша схема превращается в:
========= TCP соединение ========
50ms: Kyiv -------syn--------> SF
50ms: Kyiv <------syn/ack----- SF
50ms: Kyiv -------ack--------> SF
========= TLS соединение ========
Kyiv ---представление--> SF
50ms: Kyiv <--сертификаты----- SF
50ms: Kyiv ---обмен ключами--> SF
50ms: Kyiv <--обмен ключами--- SF
========= Запрос к бэкенду ======
50ms: Kyiv -------запрос-----> SF
20ms: работа бэкенда
50ms: Kyiv <------ответ------- SF
То есть в условиях, которые не могут даже существовать, когда пользователь имеет оптоволоконный кабель длинной в 10тыс км от своего ноутбука к серверу, он получит ответ через 420мс, в 21 раз дольше чем отрабатывает наш бэкенд. Это без учета того, что нам нужно еще вначале сбегать к DNS, чтобы получить ip-адрес сервера.
Если мы разрабатываем веб-приложения (не важно фронтенд или бекэнд), то обязаны понимать азы работы веба.
Продолжение следует...
Как ускорить код-ревью . Интересный рассказ о том как улучшить качество кода, наладить процесс код ревью и уменьшить количество ошибок в продакшене → http://bit.ly/2T76aSA
Интересная заметка о том почему MDN выбирает Flow (спойлер: нет фич, которые не в страндарте, в их команде больше разработчиков, работавших с Flow, есть инструменты для легкого перехода на TS если что-то пойдет не так) → http://bit.ly/2BLCsbY
Разбираемся с асинхронностью в JavaScript . Перевод статьи на тему того, как обрабатывает движок js асинхронные операции → http://bit.ly/2Isd94s
Use Imagemin to compress images. Библиотека для сжатия изображений в статье на web.dev → http://bit.ly/2SR9geb. Также у них есть классная песочница, где можно посмотреть интеграцию с популярными сборщиками, например webpack → http://bit.ly/2GCb4Bh
A Roadmap for Node.js Security: обзор угроз безопасности и способов защиты проектов на Node.js → http://bit.ly/2BMV1fF
Make frontend “backend” again: как развивалась разработка бэкенда и что из этого могут позаимствовать фронтендеры. Прикольный доклад Николая Рыжикова на HolyJS → http://bit.ly/2T1CaIo
Прикольная шпаргалка по git. Описаны самые часто используемые комманды и best practices
Не умничайте с элементами форм. Брэд Фрост про модалки, формы, best practices при их разработке и том, что мешает юзерам и менеджерам паролей В переводе на Хабре → http://bit.ly/2BUULeI
Прикольная коллекция бесплатных иллюстрированных аватаров с удобным API → https://joeschmoe.io/
Стартует конкурс.
Условия простые: прислать интересную или смешную историю, которая происходила с вами, или свидетелем которой вы были.
Возьмём тему: "баги на продакшене". Думаю многим будет что сказать.
Неделю собираем истории (@smartDevBot), формируем список историй и проводим голосование.
Голосование проведем в чате канала в телеграмме (@smart_dev_chat), 3 дня думаю будет достаточно.
Победителю полагается утешительный приз - 1 кг конфет (каких - предлагайте в комментариях). Приз доставим в любую точку, но если вы живёте за полярным кругом - прошу, пожалейте нас, и нашу упряжку хаски 😁.
Актуальный список можно почитать (и поднять себе настроение) здесь:
https://telegra.ph/Konkurs-Luchshaya-istoriya-na-temu-Bagi-na-prode-02-28
В общем, думаю будет по фану. Расскажите друзьям и участвуйте - буду благодарен.
🤹♂️💣💥
Условия простые: прислать интересную или смешную историю, которая происходила с вами, или свидетелем которой вы были.
Возьмём тему: "баги на продакшене". Думаю многим будет что сказать.
Неделю собираем истории (@smartDevBot), формируем список историй и проводим голосование.
Голосование проведем в чате канала в телеграмме (@smart_dev_chat), 3 дня думаю будет достаточно.
Победителю полагается утешительный приз - 1 кг конфет (каких - предлагайте в комментариях). Приз доставим в любую точку, но если вы живёте за полярным кругом - прошу, пожалейте нас, и нашу упряжку хаски 😁.
Актуальный список можно почитать (и поднять себе настроение) здесь:
https://telegra.ph/Konkurs-Luchshaya-istoriya-na-temu-Bagi-na-prode-02-28
В общем, думаю будет по фану. Расскажите друзьям и участвуйте - буду благодарен.
🤹♂️💣💥
Telegraph
Конкурс. Лучшая история на тему "Баги на проде"
История 1 История 2 Моя драмматическая история!:) Сидели мы как то со своими коллегами в офисе - работали. Один паренек стажер, уже умел немного кодить и выполнял какие то небольшие задачки на одном из проектов на боевом сервере. Но работу терминала линукс…
The Smart Ways to Correct Mistakes in Git. Очень полезная статья для тех, кто пытается освоить git. Разобраны способы исправления ошибок на разных этапах работы. Также внизу статьи есть ссылка на бесплатный курс обучения по git → http://bit.ly/2tJMO7z
TSLint in 2019. Краткая заметка о нынешнем состоянии линтера и том, почему команда будет переходить к улучшении поддержки Typenoscript в ESLint взамен развития TSLint → http://bit.ly/2tFU5FN
Вот и продолжение крутой серии статей от @jabanoscript: "Скорость света и Веб - часть 2" :)
Мы уже разобрались, что есть скорость света и она влияет на задержки при передаче данных. У нас есть задержки на TCP и TLS рукопожатия, также есть время в пути запроса и ответа. Можем ли мы говорить, что это максимальные задержки, которые мы получаем?
На самом деле все сложнее, и даже при самой высокой пропускной способности сети у нас будут дополнительные задержки в передаче данных.
Есть 2 нюанса, которые важны:
1. TCP контролирует доставку пакетов и для того, чтобы понять, что пакеты были доставлены нужно какое-то подтверждение от получателя. Для этого в ответ отправляется пакет с флагом "ack" (acknowledge).
2. Клиент и сервер изначально не знают доступной на данный момент пропускной способности сети. Она зависит от возможностей сервера, от возможностей промежуточных узлов, от активности других узлов в этой же сети и тд. Единственный способ узнать - это пробовать передавать данные с разной скоростью и смотреть доходят ли они (ждать подтверждения, что вторая сторона получила их).
Как это работает?
Когда мы делаем запрос к серверу он сначала отправляет нам часть данных, потом ждет подтверждения, потом увеличивает объем передаваемых данных в 2 раза и опять ждет ответ. Если все ок, еще раз увеличивает и так далее до момента пока он не достигнет максимального объема данных, которые готов принимать клиент.
Как это все называется?
✳️ Механизм постепенного увеличения скорости передачи данных называется "TCP Slow Start"
✳️ Лимит отправителя на объем данных в пути называется "Congestion window size" (CWND). После отправки этого объема данных, отправитель должен ждать подтверждения о том, что данные дошли. Увеличения этого лимита и есть "TCP Slow Start". ВАЖНО: про этот лимит знает только отправитель и он сам для себя его регулирует. CWND имеряется в "сегментах" (сегмент обычно не более 1,46KB). Стартовое значение по стандарту - 10 сегментов (14.6KB)
✳️ Также есть ограничение получателя на объем данных, которое он может принять - "Receiver window size" (RWND). Получатель отправляет отправителю RWND в каждом пакете с подтвержджением (с флагом ack). Поскольку передача дынных происходит в обе стороны, то каждая сторона может выступать как получателем, так и отправителем. Получатель может передать RWND равным нулю, это говорит о том, что отправитель должен приостановить передачу.
Обе переменные ограничивают количество данных, которое можно отправить, это всегда минимум с CWND и RWND.
Теперь давайте нарисуем, что на самом деле происходит, когда браузер хочет скачать наш JavaScript файл на 50KB.
Возьмем те же локациии - Киев и Сан-Франциско.
Самое интересное, что если бы наш JS файл был бы 40KB, то мы получили бы его на 100ms раньше.
Нам может казаться, что немного больший размер данных не влияет ни на что, если у пользоватлей быстрый интернет, но мы видим, что это не так.
Поэтому используйте Gzip компрессию c HTTP, следите за Cookie (они могут быть большими), сжимайте картинки и удаляйте с них метаданные . Конечно, не забывайте про CDN (может дать существенный выигрышь).
Дальше я попробую описать более детально, что у нас есть, чтобы сделать наши веб-приложения более быстрыми.
Продолжение следует...
Мы уже разобрались, что есть скорость света и она влияет на задержки при передаче данных. У нас есть задержки на TCP и TLS рукопожатия, также есть время в пути запроса и ответа. Можем ли мы говорить, что это максимальные задержки, которые мы получаем?
На самом деле все сложнее, и даже при самой высокой пропускной способности сети у нас будут дополнительные задержки в передаче данных.
Есть 2 нюанса, которые важны:
1. TCP контролирует доставку пакетов и для того, чтобы понять, что пакеты были доставлены нужно какое-то подтверждение от получателя. Для этого в ответ отправляется пакет с флагом "ack" (acknowledge).
2. Клиент и сервер изначально не знают доступной на данный момент пропускной способности сети. Она зависит от возможностей сервера, от возможностей промежуточных узлов, от активности других узлов в этой же сети и тд. Единственный способ узнать - это пробовать передавать данные с разной скоростью и смотреть доходят ли они (ждать подтверждения, что вторая сторона получила их).
Как это работает?
Когда мы делаем запрос к серверу он сначала отправляет нам часть данных, потом ждет подтверждения, потом увеличивает объем передаваемых данных в 2 раза и опять ждет ответ. Если все ок, еще раз увеличивает и так далее до момента пока он не достигнет максимального объема данных, которые готов принимать клиент.
Как это все называется?
✳️ Механизм постепенного увеличения скорости передачи данных называется "TCP Slow Start"
✳️ Лимит отправителя на объем данных в пути называется "Congestion window size" (CWND). После отправки этого объема данных, отправитель должен ждать подтверждения о том, что данные дошли. Увеличения этого лимита и есть "TCP Slow Start". ВАЖНО: про этот лимит знает только отправитель и он сам для себя его регулирует. CWND имеряется в "сегментах" (сегмент обычно не более 1,46KB). Стартовое значение по стандарту - 10 сегментов (14.6KB)
✳️ Также есть ограничение получателя на объем данных, которое он может принять - "Receiver window size" (RWND). Получатель отправляет отправителю RWND в каждом пакете с подтвержджением (с флагом ack). Поскольку передача дынных происходит в обе стороны, то каждая сторона может выступать как получателем, так и отправителем. Получатель может передать RWND равным нулю, это говорит о том, что отправитель должен приостановить передачу.
Обе переменные ограничивают количество данных, которое можно отправить, это всегда минимум с CWND и RWND.
Теперь давайте нарисуем, что на самом деле происходит, когда браузер хочет скачать наш JavaScript файл на 50KB.
Возьмем те же локациии - Киев и Сан-Франциско.
TCP соединение ========Скорость в 100Мбит/с говорит о том, что мы получим 50KB через 4ms, но на самом деле у нас это займет 620ms.
50ms: Kyiv -------syn--------> SF
50ms: Kyiv <------syn/ack----- SF
50ms: Kyiv -------ack--------> SF
========= TLS соединение ========
Kyiv ---представление--> SF
50ms: Kyiv <--сертификаты----- SF
50ms: Kyiv ---обмен ключами--> SF
50ms: Kyiv <--обмен ключами--- SF
====== HTTP запрос к серверу ====
50ms: Kyiv -------запрос-----> SF
20ms: работа бекенда
50ms: Kyiv <-----14.6KB------- SF
50ms: Kyiv -------ack--------> SF
50ms: Kyiv <-----29.2KB------- SF
50ms: Kyiv -------ack--------> SF
50ms: Kyiv <-----6.2KB-------- SF
Самое интересное, что если бы наш JS файл был бы 40KB, то мы получили бы его на 100ms раньше.
Нам может казаться, что немного больший размер данных не влияет ни на что, если у пользоватлей быстрый интернет, но мы видим, что это не так.
Поэтому используйте Gzip компрессию c HTTP, следите за Cookie (они могут быть большими), сжимайте картинки и удаляйте с них метаданные . Конечно, не забывайте про CDN (может дать существенный выигрышь).
Дальше я попробую описать более детально, что у нас есть, чтобы сделать наши веб-приложения более быстрыми.
Продолжение следует...
AMP и Турбо-страницы: плюсы, минусы и результаты внедрения. Опыт внедрения компанией данных технологий, сложности, с какими столкнулись и какой профит получили. Такжи советую почитать комментарии, там альтернативная точка зрения → http://bit.ly/2GR11Iv
Вебпак, вид сквозь монокль. Классный доклад об улучшении сборки проекта и developer experience при работе с вебпак -> http://bit.ly/2tOFXtC
Сотрудник Google Мартин Сплит (Martin Splitt) объявил о запуске новой серии видео, посвящённой SEO для JavaScript. Так как эта тема интересует многие контент-ориентированные проекты, а точного описания процессов индексации нет - очень советую → http://bit.ly/2VAlg0i
Всем привет.
У нашего канала есть друзья, коротые несут образование в массы - это WebHero School. Это не просто образовательный проект, а целое коммьинити (что очень-очень круто). Рекомендуем подписаться на их канал @webheropublic. В нем сможете найти полезные материалы, книги и статьи, необходимые для того чтоб начать свой путь в мир разработки или углубить знания. Также у сообщества есть чат, в котором можно обсудить интересующие вопросы.
В общем подписывайтесь, рекомендуем)
У нашего канала есть друзья, коротые несут образование в массы - это WebHero School. Это не просто образовательный проект, а целое коммьинити (что очень-очень круто). Рекомендуем подписаться на их канал @webheropublic. В нем сможете найти полезные материалы, книги и статьи, необходимые для того чтоб начать свой путь в мир разработки или углубить знания. Также у сообщества есть чат, в котором можно обсудить интересующие вопросы.
В общем подписывайтесь, рекомендуем)
Improving Performance in React Functional Components using React.memo(). Интересная статья, в которой объясняется как улучшить производительность React приложения с помощью Pure.Component, ShouldComponentUpdate и React.memo() → http://bit.ly/2tRawyS