Ворчанье деда Нас больше 1000. Спасибо вам! Сегодня пост б | perfScan - Секреты быстрых сайтов

Ворчанье деда

Нас больше 1000. Спасибо вам!

Сегодня пост будет необычным, возможно кому-то покажется менее полезным, и будет похож на ворчание старого деда, но я призываю вас максимально прислушаться и присоединиться к дискуссии. Раньше солнце ярче светило, трава была зеленее и о быстродействии думали больше, потому что был медленный интернет и компьютеры.

Почему все острее стоит проблема быстродействия сайтов и веб-приложений? Потому что все меньше внимания уделяется этому вопросу. Быстрый интернет и быстрые процессоры позволяют совсем расслабиться. Но проблема ещё и в самих разработчиках: уже изначально, при входе в профессию, учат не языки, а фреймворки: react, vue, angular. Это крутые инструменты, против них ничего не имею, но если человек не знает как работает JavaScript, то и использовать фреймворки он будет так же.

Я много общаюсь и знаю, что многие разработчики понимают важность быстродействия, но часто проблема системная, и в одиночку с ней не справиться. Например, маркетологи ставят задачу ускорить сайт и одновременно подключить 4 сторонних сервиса для "увеличения конверсии", которые наглухо блокируют основной поток на 4-6 секунд.

Непонимание языка или лень?

Библиотека для вычисления разницы между двумя датами. Серьезно? Это одна функция с совсем простой математикой. Зачем подключать библиотеку на 200 кб? Просто потому что торопился. Да, эта библиотека решает необходимую задачу, и еще 400 других, которые не нужны. Отсюда мы и получаем предупреждение Lighthouse о неиспользуемом коде. Хорошо еще, если используется система сборки и импорт происходит не всей библиотеки, а только необходимой части. Но это скорее исключение из правил. Ведь в Examples этой библиотеки был пример только с полным импортом, так ведь?

Непонимание проблемы производительности.

"8 мегабайт картинка? Ну, у меня за секунду загрузилась на моем гигабитном интернете по проводу, если у вас медленно, значит проблема на вашей стороне." Нет. Картинку можно и нужно сжимать, готовить к публикации. Если с сайтом работают неподготовленные люди, то это должно происходить без их вмешательства. Тоже касается и 8 мб js на странице. Четыре разных слайдера на разных библиотеках, только потому что в примерах один свайпится тачем, а второй по таймеру. Так и хочется процитировать классика "Астанавитесь!". Не у всех такой компьютер как у разработчика. У большинства пользователей будут устройства медленнее чем у разработчика. Это нормально. И даже рост вычислительной мощности процессоров не должен позволять забывать об оптимизации. Даже если это временное решение, то техдолг растёт и со временем становится неуправляемым.

Сложность алгоритмов.

Следите за сложностью алгоритмов. Всегда. Точка. Не сортируйте лишний раз большие массивы без спроса. Не перебирайте весь массив там, где можно вычислить алгоритмически. Изучите алгоритмы, например поиска, сортировки, чтобы использовать именно тот, который будет оптимальнее для каждого конкретного момента.

Важно: Я НЕ призываю отказываться от готовых библиотек - это нерационально писать велосипеды. Я призываю вдумчиво анализировать что подключается и используется на сайте.

У меня все. Пишите, что думаете по этому поводу в комменты.