Привет!
Не писал в этой статье, потому что ответом будет: "it depends" :) В общем случае, мы начинаем профилировать страницу на предмет проблем.
Самый ТОП проблем у нас был из-зи большого (огромного) количества мусорных объектов.
Скриншотов у меня уже не осталось, но вот пример:
время рендера на сервере увеличивается до 120мс, гидрейта драмматически больше.
По логам смотрим requiresId пользователя, смотрим на объем данных отправляемых ему.
Смотрим вызовы GC через profile — для node.js и\или браузера. Поняв, что он вызывается крайне часто, собираем JS Heap.
В хипе выясняется, что у нас каждый компонент генерировал свой объект переводов (сами переводы инкапсулируются в redux стор при запросе страницы, но каждый компонент добирал себе переводы). Компонентов очень много, особенно на поисковых страницах.
Итого меняем систему переводов, делаем общий прокси, который по ключу валидирует доступ к объекту переводов. Избавляемся от кучи объектов. Для того, чтобы понимать порядок, на странице поиска резюме у нас активно более 9000 react компонентов.
Время рендера на сервере падает до 90мс, при гидрейте видим также падение на графиках
не, от RAF в итоге мы отказываемся и по факту получаем завязку только на марки для понимания, когда браузер справляется с документом (парсинг, дошел до нужного момента, отправил загрузку критикал ресурсов). Их нам как раз хватает на текущий момент, чтобы реагировать на проблемы.
да, все верно, но метрика fmp_body у нас стоит перед концом самого боди:
<body>
<div class="root" data-test="вот тут очень много ненужных символов, которые будут влиять на парсинг">
<!-- или вот сюда можно наставить -->
Куча контента, который рисуется на сервере
</div>
<script>window.performance.mark('fmp_body')</script>
</body>
На картинке:
fmp_body указывается после блока с контентом, поэтому с большей долей вероятности, мы можем говорить, что critical ресурсы готовы. Контент ниже: это уже iframe и элементы которые ставят скрипты после своих инитов
Я думал, что ответы легко определяются по мере продвижения по event loop, но да, их будет не лишним кратко описать:
Будет ли выведено "1" в консоль? Почему?
function loop() {
Promise.resolve().then(loop);
}
setTimeout(() => {console.log(1)}, 0);
loop();
Ответ: 1 выведено не будет, страница зависнет. Дело в том, что на каждый виток loop, мы получаем микротаску, которая попадает в microtask queue и по окончании функции loop мы будем доставать следующую микротаску loop. До получения задачи из TaskQueue мы никогда не дойдем. Подробнее описано в разделе: Что же такое микротаски?
Есть сайт, а на сайте ссылка, у которой при наведении cursor: pointer ставится через :hover стиль CSS и кнопка, у которой также по :hover меняется background-color c серого на синий. Добавляем скрипт:
while (true);
Вопрос: Что будет если навести мышку на ссылку? А на кнопку? Почему?
Ответ: Мы получаем бесконечный цикл, поэтому задачи из RenderQueue никогда выполнены не будут. Это означает, что мы вообще никогда не выполним ни один из этапов: Style\Paint\Layout\Composite, стили на :hover не применятся. Подробнее про это в TaskQueue
Как анимировать выпадающий элемент по height с 0 до auto? Здесь важно обсудить способы c помощью JS и/или CSS. Кстати, если гуглить этот вопрос, то stackoverflow вначале предлагает неверный ответ. Суть понимания event loop и работы браузеров сводится к тому, как замерить то самое height = auto с помощью JS.
div1.style.height = 'auto' // Запланировали изменение высоты
const animateTo = div1.offsetHeight; // форсим layout, размеры будут пересчитаны, но пользователь изменений не увидит
div1.style.height = '0' // возвращаем первоначальное значение
После этого кода animateTo знает до какого размера анимировать элемент. Дальше уже дело техники. Подробнее почему так происходит можно почитать в блоке RenderQueue и в частности в Layout разделе статьи
Секунды честные.
Проблема в том, что на главной у нас большое количество ресурсов. Из наиболее тяжелых на главной:
1) картинки
2) Рекламные баннеры — много разных видов
3) Вакансии дня, которые подгружаются асинхронно
Рекламные баннеры мы грузим только после физической загрузки и инициализации страницы, чтобы их загрузка и исполнение (например, нашей рекламной сети) не влияло на основные возможности сайта.
TTI трекает загрузку абсолютно всех ресурсов и исполнение всех скриптов.
Поэтому если уйти с главной хх на страницу, где меньше рекламы TTI вырастает.
Иногда делают просто инлайн скрипт с сохранением времени, тогда это не совсем честный FMP получается, но примерное понимание критических ресурсов он дает.
это как раз про performance.mark я писал. Просто он не отображает идеальный fmp, а только дает понимание, когда мы дошли до нужного места :)
Но из его преимуществ: он дает уже достаточно данных для аналитики производительности сайта.
Если коротко, то иногда, если снимают данные со стороны клиента, делают через 2 requestAnimationFrame, причем скрипт вызова вставляют после значимого контента. Например, после текста вакансии, или резюме.
Иногда делают просто инлайн скрипт с сохранением времени, тогда это не совсем честный FMP получается, но примерное понимание критических ресурсов он дает.
В итоге, вроде как и считаем, а с другой стороны не идеально правильно.
У нас, да и у еще заметного ряда компаний два круга обработки резюме: вначале hr фильтрует первые резюме. Затем разработчики. Там же разработчик могут оставлять комментарий — на что обратить внимание на собеседовании.
Да, саму статью я писал в отрыве от того, как это сделано на хх, так как не было целью делать рекламную статейку, а своим взглядом поделиться. На тех же jobhero можно составить резюме удобного формата. (либо просто гугл-доком воспользоваться)
Если же говорить как такую технику применить в хх, то питчинг можно выносить в реалиях hh.ru в виде сопроводительных писем.
Так как мы в компанию практически всё время нанимаем разработчиков через hh.ru, то могу сказать, что часто в сопроводительном письме разработчики пишут или ничего или «заинтересовала компания». Поэтому писать свое короткое «о себе» там, после условного «здравствуйте», вполне может сработать.
p.s. еще забыл про такой сервис как resume.io — я им не пользовался, но вроде он был популярен какое-то время назад.
Привет.
Все же я не буду писать в статье информацию по типу: подал резюме в M компаний, в M — 1 позвали, в N прошел собеседование в K не прошел. Резюме, которое составляется, как в первом треде правильно написали, работает на то, чтобы тебя заметили, выбрали и позвали на собес. Из всех компаний, куда я подавался, была только 1 зарубежная компания, которая решила не говорить.
Могу сказать следующее:
1) Этот способ формирования резюме выстрадал через то, что сам проводил собеседования и через подачи в разные компании
2) Этот способ работает как на зарубежные, так и для российских компаний. Ну и честно говоря, способ несколько подсмотрен у американских «best practices».
Вот один из примеров резюме, которые мне нравятся github.com/donavon/resume/blob/master/donavon-west-resume-2019.pdf
3) Оферов было немало, но в хх мне всегда что-то нравилось больше. (не пытаюсь рекламировать, но согласитесь, я бы не сидел на попе ровно, если бы мне в хх что-то не нравилось). Так с 2016 года я полностью отвечал за фронтенд на отдельном проекте хх, с 2019 года за фронтенд-архитектуру основного сайта. Сюда можно добавить такие бонусы что:
3.1) Мне нравится коллектив
3.2) У нас есть школа разработчиков, а у меня страсть к выступлениям
3.3) Опять же, в ХХ у меня получилось много смен команд и контекстов внутри компании: Поиск => Мобильный сайт => Talantix 1 => Talantix 2 в качестве лида => Архитектура
Резюме позволяет увидеть вас и принять решение «позвать на собес». Дальше задача резюме как максимум — это ваш (для вас же) план в ответе на вопрос интервьювера «расскажите о себе».
Я бы делал это так:
1) Самые важные на ваш моменты выносим в блок «о себе».
2) Опыт работы по содержанию начинает постепенно деградировать от свежего и расписанного, к уменьшению подробностей и остановке только на ключевых пунктах 1-2 на место \ год и т.д.
К слову, это заметно даже не 15+ лет опыта работы, но и на мелких 6-7 годах, как у меня — xnim.ru/cv/ru вот тут можно проследить, что новое подробно, но чем старее, тем скупее.
Возможно мои случаи с которыми я сталкивался работали по-другому (здесь часто работает правило «у меня такая же нога, но не болит), но да, как писал в статье серчеры или HR менеджеры, которые изначально ищут кандидата, часто работают как regexp, все ключевые навыки будут рассмотрены как ваша профессия. Поэтому мне приходилось фиксить этот блок напильником.
Сам когда только стал фронтендером, мне часто писали с предложением C# работы :/ Итого, выкинул лишнее, жить стало легче.
А вот с третьим пунктом, не соглашусь. „Сильное“ резюме, которое строится от „достижений“ и интересов вполне могут зайти в конторы в которые очередь, я проверял :)
Главный поинт в том, что react-helmet решает только работу с head документом. Декораторы же могут использоваться для значительно большего спектра задач (в статье, например, разобрано 4 способа использования).
Если же вы о декораторе title, который был приведен в качестве одного из примеров, то аналогично вопросу axios vs http — у react-helmet много функций, в которых мы не нуждаемся. В таком случае лучше сделать маленькую «утилиту»\компонент, который решит потребности. А если требования изменятся, и нужен будет больший набор возможностей, то окей, перейдем.
Привет!
Не писал в этой статье, потому что ответом будет: "it depends" :) В общем случае, мы начинаем профилировать страницу на предмет проблем.
Самый ТОП проблем у нас был из-зи большого (огромного) количества мусорных объектов.
Скриншотов у меня уже не осталось, но вот пример:
время рендера на сервере увеличивается до 120мс, гидрейта драмматически больше.
По логам смотрим requiresId пользователя, смотрим на объем данных отправляемых ему.
Смотрим вызовы GC через profile — для node.js и\или браузера. Поняв, что он вызывается крайне часто, собираем JS Heap.
В хипе выясняется, что у нас каждый компонент генерировал свой объект переводов (сами переводы инкапсулируются в redux стор при запросе страницы, но каждый компонент добирал себе переводы). Компонентов очень много, особенно на поисковых страницах.
Итого меняем систему переводов, делаем общий прокси, который по ключу валидирует доступ к объекту переводов. Избавляемся от кучи объектов. Для того, чтобы понимать порядок, на странице поиска резюме у нас активно более 9000 react компонентов.
Время рендера на сервере падает до 90мс, при гидрейте видим также падение на графиках
не, от RAF в итоге мы отказываемся и по факту получаем завязку только на марки для понимания, когда браузер справляется с документом (парсинг, дошел до нужного момента, отправил загрузку критикал ресурсов). Их нам как раз хватает на текущий момент, чтобы реагировать на проблемы.
От RAF как раз отказались из-за искажений
да, все верно, но метрика fmp_body у нас стоит перед концом самого боди:
На картинке:
fmp_body указывается после блока с контентом, поэтому с большей долей вероятности, мы можем говорить, что critical ресурсы готовы. Контент ниже: это уже iframe и элементы которые ставят скрипты после своих инитов
1) Да, конечно
2) Да, анимация будет больше похоже на включение-выключение старых телевизоров, при изменении только scaleY
Я думал, что ответы легко определяются по мере продвижения по event loop, но да, их будет не лишним кратко описать:
Будет ли выведено "1" в консоль? Почему?
Ответ: 1 выведено не будет, страница зависнет. Дело в том, что на каждый виток loop, мы получаем микротаску, которая попадает в microtask queue и по окончании функции loop мы будем доставать следующую микротаску loop. До получения задачи из TaskQueue мы никогда не дойдем. Подробнее описано в разделе: Что же такое микротаски?
Есть сайт, а на сайте ссылка, у которой при наведении cursor: pointer ставится через :hover стиль CSS и кнопка, у которой также по :hover меняется background-color c серого на синий. Добавляем скрипт:
Вопрос: Что будет если навести мышку на ссылку? А на кнопку? Почему?
Ответ: Мы получаем бесконечный цикл, поэтому задачи из RenderQueue никогда выполнены не будут. Это означает, что мы вообще никогда не выполним ни один из этапов: Style\Paint\Layout\Composite, стили на
:hoverне применятся. Подробнее про это в TaskQueueКак анимировать выпадающий элемент по height с 0 до auto? Здесь важно обсудить способы c помощью JS и/или CSS. Кстати, если гуглить этот вопрос, то stackoverflow вначале предлагает неверный ответ. Суть понимания event loop и работы браузеров сводится к тому, как замерить то самое height = auto с помощью JS.
Если говорить про CSS решения, то можно использовать scaleY: https://developer.mozilla.org/en-US/docs/Web/CSS/transform-function/scaleY. Если говорить про JS решения, то можно воспользоваться следующим подходом:
После этого кода animateTo знает до какого размера анимировать элемент. Дальше уже дело техники. Подробнее почему так происходит можно почитать в блоке RenderQueue и в частности в Layout разделе статьи
Проблема в том, что на главной у нас большое количество ресурсов. Из наиболее тяжелых на главной:
1) картинки
2) Рекламные баннеры — много разных видов
3) Вакансии дня, которые подгружаются асинхронно
Рекламные баннеры мы грузим только после физической загрузки и инициализации страницы, чтобы их загрузка и исполнение (например, нашей рекламной сети) не влияло на основные возможности сайта.
TTI трекает загрузку абсолютно всех ресурсов и исполнение всех скриптов.
Поэтому если уйти с главной хх на страницу, где меньше рекламы TTI вырастает.
это как раз про performance.mark я писал. Просто он не отображает идеальный fmp, а только дает понимание, когда мы дошли до нужного места :)
Но из его преимуществ: он дает уже достаточно данных для аналитики производительности сайта.
Кстати, FMP еще бывает накладно «правильно» считать сторонним средством, так как появляется вопрос: а что является тем самым meaningful контентом.
Поэтому и способов подсчета его несколько. Вот тут про это говорил: www.youtube.com/watch?v=4joeMk5v8Rw
Если коротко, то иногда, если снимают данные со стороны клиента, делают через 2 requestAnimationFrame, причем скрипт вызова вставляют после значимого контента. Например, после текста вакансии, или резюме.
Иногда делают просто инлайн скрипт с сохранением времени, тогда это не совсем честный FMP получается, но примерное понимание критических ресурсов он дает.
В итоге, вроде как и считаем, а с другой стороны не идеально правильно.
Если же говорить как такую технику применить в хх, то питчинг можно выносить в реалиях hh.ru в виде сопроводительных писем.
Так как мы в компанию практически всё время нанимаем разработчиков через hh.ru, то могу сказать, что часто в сопроводительном письме разработчики пишут или ничего или «заинтересовала компания». Поэтому писать свое короткое «о себе» там, после условного «здравствуйте», вполне может сработать.
p.s. еще забыл про такой сервис как resume.io — я им не пользовался, но вроде он был популярен какое-то время назад.
Все же я не буду писать в статье информацию по типу: подал резюме в M компаний, в M — 1 позвали, в N прошел собеседование в K не прошел. Резюме, которое составляется, как в первом треде правильно написали, работает на то, чтобы тебя заметили, выбрали и позвали на собес. Из всех компаний, куда я подавался, была только 1 зарубежная компания, которая решила не говорить.
Могу сказать следующее:
1) Этот способ формирования резюме выстрадал через то, что сам проводил собеседования и через подачи в разные компании
2) Этот способ работает как на зарубежные, так и для российских компаний. Ну и честно говоря, способ несколько подсмотрен у американских «best practices».
Вот один из примеров резюме, которые мне нравятся github.com/donavon/resume/blob/master/donavon-west-resume-2019.pdf
3) Оферов было немало, но в хх мне всегда что-то нравилось больше. (не пытаюсь рекламировать, но согласитесь, я бы не сидел на попе ровно, если бы мне в хх что-то не нравилось). Так с 2016 года я полностью отвечал за фронтенд на отдельном проекте хх, с 2019 года за фронтенд-архитектуру основного сайта. Сюда можно добавить такие бонусы что:
3.1) Мне нравится коллектив
3.2) У нас есть школа разработчиков, а у меня страсть к выступлениям
3.3) Опять же, в ХХ у меня получилось много смен команд и контекстов внутри компании: Поиск => Мобильный сайт => Talantix 1 => Talantix 2 в качестве лида => Архитектура
Собственно, после этого и появилось желание написать свою точку зрения.
Но да, возьмут или нет — это уже собеседование.
1) Самые важные на ваш моменты выносим в блок «о себе».
2) Опыт работы по содержанию начинает постепенно деградировать от свежего и расписанного, к уменьшению подробностей и остановке только на ключевых пунктах 1-2 на место \ год и т.д.
К слову, это заметно даже не 15+ лет опыта работы, но и на мелких 6-7 годах, как у меня — xnim.ru/cv/ru вот тут можно проследить, что новое подробно, но чем старее, тем скупее.
Сам когда только стал фронтендером, мне часто писали с предложением C# работы :/ Итого, выкинул лишнее, жить стало легче.
А вот с третьим пунктом, не соглашусь. „Сильное“ резюме, которое строится от „достижений“ и интересов вполне могут зайти в конторы в которые очередь, я проверял :)
Если же вы о декораторе title, который был приведен в качестве одного из примеров, то аналогично вопросу axios vs http — у react-helmet много функций, в которых мы не нуждаемся. В таком случае лучше сделать маленькую «утилиту»\компонент, который решит потребности. А если требования изменятся, и нужен будет больший набор возможностей, то окей, перейдем.
Не натыкался на него)