Оптимизируешь такой, оптимизируешь... тут сжал, там асинхроночка, здесь почистил зависимости... а потом ХЕРАКС — приходит эффективный менеджер-аналитик, который впендюривает кучу трекеров и другого говна в GTM так, что твой сайт начинает лагать даже на мощной девелоперской машине...
А теперь идем на caniuse и понимаем, что JS вариант не так уж плох.
Про details/summary - не понятно что вообще там экономить. Две строчки кода?
Про Select2 - тут скорее проблема тех, кто его тянет по каждому поводу. Реализовать минимально необходимый подобный функционал можно гораздо меньшим кодом. Ну и без jQuery, от которого не убегает сейчас только ленивый.
Я бы добавил еще: 1. JS виджеты лучше грузить по клику. Например многие виджет-чаты запускаются хоть и асинхронно, но это все равно попадает в load (бывает сервер чата отвечает долго или вообще может отдать 50Х ответ). Поэтому лучше отверстать иконку чата SVG и запускать JS чата только по клику или вообще после load. 2. Также мало кто об этом говорит, но мобильный трафик уже давно преобладает, а скорость интернета ниже, поэтому лучше изолировать версии. То есть если пользователь заходит на сайт с мобильного устройство, то можно отдать отдельную облегченную версию (не адаптировать и не бустрапить), а именно отдельный CSS и JS конкретно для мобильных устройств (они всегда будут меньше весить). 3. Статичные блоки лучше кешировать на сервере. В некоторых случаях можно даже держать в кеше на сервере готовую страницу, чтобы сразу ее отдать, что сильно уменьшает TTFB. 4. Ну и самое главное, все сторонние JS лучше не использовать асинхронно. Потому что асинхронность хоть и грузит файл JS не останавливая парсинг, но при отработке останавливает его. Поэтому лучше использовать либо пост загрузку, либо defer загрузку.
Мог бы добавить еще много чего, но каждый проект индивидуален и надо смотреть на точки роста. Возможно где-то нужен CDN, где-то отдельно догружать блок на который php (или другой язык программирования) тратит много времени тормозя генерацию страницы на сервере. А иногда вообще бывает тупо загвоздка в большом количестве запросов, если можно, то лучше уменьшать.
Мы так делаем с подгрузкой ютуб-видео. Блок с плеером накрывается картинкой-превьюшкой, код плеера начинает грузиться по клику на нее. Сразу же минус 1мб к весу страницы.
Оптимизируешь такой, оптимизируешь... тут сжал, там асинхроночка, здесь почистил зависимости... а потом ХЕРАКС — приходит эффективный менеджер-аналитик, который впендюривает кучу трекеров и другого говна в GTM так, что твой сайт начинает лагать даже на мощной девелоперской машине...
А теперь идем на caniuse и понимаем, что JS вариант не так уж плох.
Про details/summary - не понятно что вообще там экономить. Две строчки кода?
Про Select2 - тут скорее проблема тех, кто его тянет по каждому поводу. Реализовать минимально необходимый подобный функционал можно гораздо меньшим кодом. Ну и без jQuery, от которого не убегает сейчас только ленивый.
строчка про jQuery немного обидная... почему в данное время я часто стал замечать информацию про избежание данной библиотеки ?
Спасибо за статью.
Я бы добавил еще:
1. JS виджеты лучше грузить по клику. Например многие виджет-чаты запускаются хоть и асинхронно, но это все равно попадает в load (бывает сервер чата отвечает долго или вообще может отдать 50Х ответ). Поэтому лучше отверстать иконку чата SVG и запускать JS чата только по клику или вообще после load.
2. Также мало кто об этом говорит, но мобильный трафик уже давно преобладает, а скорость интернета ниже, поэтому лучше изолировать версии. То есть если пользователь заходит на сайт с мобильного устройство, то можно отдать отдельную облегченную версию (не адаптировать и не бустрапить), а именно отдельный CSS и JS конкретно для мобильных устройств (они всегда будут меньше весить).
3. Статичные блоки лучше кешировать на сервере. В некоторых случаях можно даже держать в кеше на сервере готовую страницу, чтобы сразу ее отдать, что сильно уменьшает TTFB.
4. Ну и самое главное, все сторонние JS лучше не использовать асинхронно. Потому что асинхронность хоть и грузит файл JS не останавливая парсинг, но при отработке останавливает его. Поэтому лучше использовать либо пост загрузку, либо defer загрузку.
Мог бы добавить еще много чего, но каждый проект индивидуален и надо смотреть на точки роста. Возможно где-то нужен CDN, где-то отдельно догружать блок на который php (или другой язык программирования) тратит много времени тормозя генерацию страницы на сервере. А иногда вообще бывает тупо загвоздка в большом количестве запросов, если можно, то лучше уменьшать.
JS виджеты лучше грузить по клику.
Мы так делаем с подгрузкой ютуб-видео. Блок с плеером накрывается картинкой-превьюшкой, код плеера начинает грузиться по клику на нее. Сразу же минус 1мб к весу страницы.
С картами встроенными что делать?
lazy load. Либо загружать через 3-5 секунд после load.
Либо так https://sitehere.ru/optimizaciya-zagruzki-yandeks-karty-na-sajte