Как стать автором
Обновить
55
Карма
0
Рейтинг
Ник Мостовой @xnim

Пользователь

Перфоманс фронтенда как современное искусство: графики, код, кулстори

Привет!
Не писал в этой статье, потому что ответом будет: "it depends" :) В общем случае, мы начинаем профилировать страницу на предмет проблем.


Самый ТОП проблем у нас был из-зи большого (огромного) количества мусорных объектов.
Скриншотов у меня уже не осталось, но вот пример:
время рендера на сервере увеличивается до 120мс, гидрейта драмматически больше.
По логам смотрим requiresId пользователя, смотрим на объем данных отправляемых ему.
Смотрим вызовы GC через profile — для node.js и\или браузера. Поняв, что он вызывается крайне часто, собираем JS Heap.
В хипе выясняется, что у нас каждый компонент генерировал свой объект переводов (сами переводы инкапсулируются в redux стор при запросе страницы, но каждый компонент добирал себе переводы). Компонентов очень много, особенно на поисковых страницах.
Итого меняем систему переводов, делаем общий прокси, который по ключу валидирует доступ к объекту переводов. Избавляемся от кучи объектов. Для того, чтобы понимать порядок, на странице поиска резюме у нас активно более 9000 react компонентов.
Время рендера на сервере падает до 90мс, при гидрейте видим также падение на графиках

Перфоманс фронтенда как современное искусство: графики, код, кулстори

не, от RAF в итоге мы отказываемся и по факту получаем завязку только на марки для понимания, когда браузер справляется с документом (парсинг, дошел до нужного момента, отправил загрузку критикал ресурсов). Их нам как раз хватает на текущий момент, чтобы реагировать на проблемы.


От RAF как раз отказались из-за искажений

Перфоманс фронтенда как современное искусство: графики, код, кулстори

да, все верно, но метрика fmp_body у нас стоит перед концом самого боди:


<body>
<div class="root" data-test="вот тут очень много ненужных символов, которые будут влиять на парсинг">
    <!-- или вот сюда можно наставить -->
   Куча контента, который рисуется на сервере
</div>
<script>window.performance.mark('fmp_body')</script>
</body>

На картинке:


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

Оптимизация производительности фронтенда. Часть 2. Event loop, layout, paint, composite

1) Да, конечно


2) Да, анимация будет больше похоже на включение-выключение старых телевизоров, при изменении только scaleY

Оптимизация производительности фронтенда. Часть 2. Event loop, layout, paint, composite

Я думал, что ответы легко определяются по мере продвижения по event loop, но да, их будет не лишним кратко описать:


  1. Будет ли выведено "1" в консоль? Почему?


    function loop() {
      Promise.resolve().then(loop);   
    }
    setTimeout(() => {console.log(1)}, 0);
    loop();

    Ответ: 1 выведено не будет, страница зависнет. Дело в том, что на каждый виток loop, мы получаем микротаску, которая попадает в microtask queue и по окончании функции loop мы будем доставать следующую микротаску loop. До получения задачи из TaskQueue мы никогда не дойдем. Подробнее описано в разделе: Что же такое микротаски?


  2. Есть сайт, а на сайте ссылка, у которой при наведении cursor: pointer ставится через :hover стиль CSS и кнопка, у которой также по :hover меняется background-color c серого на синий. Добавляем скрипт:


    while (true);

    Вопрос: Что будет если навести мышку на ссылку? А на кнопку? Почему?


    Ответ: Мы получаем бесконечный цикл, поэтому задачи из RenderQueue никогда выполнены не будут. Это означает, что мы вообще никогда не выполним ни один из этапов: Style\Paint\Layout\Composite, стили на :hover не применятся. Подробнее про это в TaskQueue


  3. Как анимировать выпадающий элемент по 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 решения, то можно воспользоваться следующим подходом:


    div1.style.height = 'auto' // Запланировали изменение высоты
    const animateTo = div1.offsetHeight; // форсим layout, размеры будут пересчитаны, но пользователь изменений не увидит
    div1.style.height = '0' // возвращаем первоначальное значение

    После этого кода animateTo знает до какого размера анимировать элемент. Дальше уже дело техники. Подробнее почему так происходит можно почитать в блоке RenderQueue и в частности в Layout разделе статьи


Оптимизация производительности фронтенда. Часть 1. Critical Render Path

Секунды честные.
Проблема в том, что на главной у нас большое количество ресурсов. Из наиболее тяжелых на главной:

1) картинки
2) Рекламные баннеры — много разных видов
3) Вакансии дня, которые подгружаются асинхронно

Рекламные баннеры мы грузим только после физической загрузки и инициализации страницы, чтобы их загрузка и исполнение (например, нашей рекламной сети) не влияло на основные возможности сайта.
TTI трекает загрузку абсолютно всех ресурсов и исполнение всех скриптов.
Поэтому если уйти с главной хх на страницу, где меньше рекламы TTI вырастает.

Оптимизация производительности фронтенда. Часть 1. Critical Render Path

Иногда делают просто инлайн скрипт с сохранением времени, тогда это не совсем честный FMP получается, но примерное понимание критических ресурсов он дает.


это как раз про performance.mark я писал. Просто он не отображает идеальный fmp, а только дает понимание, когда мы дошли до нужного места :)
Но из его преимуществ: он дает уже достаточно данных для аналитики производительности сайта.

Оптимизация производительности фронтенда. Часть 1. Critical Render Path

да, видел эту новость тоже.

Кстати, FMP еще бывает накладно «правильно» считать сторонним средством, так как появляется вопрос: а что является тем самым meaningful контентом.

Поэтому и способов подсчета его несколько. Вот тут про это говорил: www.youtube.com/watch?v=4joeMk5v8Rw

Если коротко, то иногда, если снимают данные со стороны клиента, делают через 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 со стенда HeadHunter на HolyJs 2018

Да, действительно, имеется в виду конечное состояние компонента после updating цикла.

Разбор конкурса-квиза по React со стенда HeadHunter на HolyJs 2018

Разбор вопросов по JS — здесь habr.com/post/431698

Нянчим проект на React-redux с пелёнок

Главный поинт в том, что react-helmet решает только работу с head документом. Декораторы же могут использоваться для значительно большего спектра задач (в статье, например, разобрано 4 способа использования).

Если же вы о декораторе title, который был приведен в качестве одного из примеров, то аналогично вопросу axios vs http — у react-helmet много функций, в которых мы не нуждаемся. В таком случае лучше сделать маленькую «утилиту»\компонент, который решит потребности. А если требования изменятся, и нужен будет больший набор возможностей, то окей, перейдем.

Нянчим проект на React-redux с пелёнок

Способ интересный, спасибо за ссылку!

Не натыкался на него)

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Зарегистрирован
Активность