- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Просматриваю страницы своего сайта, сделанного десять лет назад. Скрипты, загружающие некритические ресурсы, в соответствии с тогдашними рекомендациями размещены мною в самом низу страницы, перед футером. Уже не помню, почему я отказался от loading="lazy", но какие-то доводы были.
В те годы на странице редко размещали контент длиной более 5-7 тысяч знаков и все работало нормально, а теперь есть страницы по 50 тысяч знаков и даже больше, которые на мобильнике долго загружаются. Размещенный внизу скрипт формирует всплывающее меню. И получается, что пока не закачается контент полностью, меню не будет готово к работе. Не если вернуть скрипт в head, где ему и положено быть, то его вес под 100кб. тоже будет изрядно тормозить.
Как здесь лучше поступить?
Вешать:
header link rel=preload;
ну или хотя бы тоже самое, но в <head> в HTML коде. Но header страницы лучше.
При этом включить http2
Из самого главного: реализовывайте асинхронную загрузку ресурсов. HTTP2-то используется? Учитывайте параметры первичного взаимодействия со страницей - ясно-понятно, что в приоритете - первый экран, но гуглобот прокручивать не умеет, поэтому этот самый первый экран должен быть сильно поболе реального, физического.
Важнейший контент (главная навигация - уж точно) лучше вообще реализовывать так, чтобы он был доступен без JS и до полной загрузки JS - там, в конце концов, не только интерактивность, там ключи.
Lazy-load же, как по мне - это зло. Лучше продумать и интегрировать продуманную последовательность запросов, чем такое вот решение.
Размещенный внизу скрипт формирует всплывающее меню. И получается, что пока не закачается контент полностью, меню не будет готово к работе. Не если вернуть скрипт в head, где ему и положено быть, то его вес под 100кб.
Для всплывающего меню не нужно 100кб. У вас там ещё какая-то хрень. И сами по себе 100кб ничего не тормозят, тормозит конкретный скрипт. Выдёргивайте оттуда критический код и размещайте его до загрузки всей страницы.
И сами по себе 100кб ничего не тормозят, тормозит конкретный скрипт.
Закреплю. TC, тормозит не объём данных (хотя и его по возможности надо сокращать), тормозит исполнение скриптов.
Как здесь лучше поступить?
Для начала показать сайт (можно в личку), чтобы проверить как рендерится страница и какие критические зоны используются в вашем коде. Выше даны резонные рекомендации, чтобы определить приоритетную и асинхронную нагрузку, но нередко бывает такое, что на странице работает ненужный или устаревший код, который нужно оптимизировать, а иногда переписать полностью (но это уже к программистам).
ни один из них не использует jquery
Значит, им это не надо
реально тяжелый
Как Вы можете говорить, что он тяжёлый, если только что написали, что у Вас недостаточно квалификации?
как-то они без этого обходятся, хотя функционал у этих сайтов весьма развитый.
Функциональность сайта никак не связана с использованием библиотеки jQuery.
Как на пример для подражания (или просто как на пример грамотно сделанного сайта) я смотрю на vc.ru и e-xecutive.ru. И ни один из них не использует ни preload, ни prefetch, ни preconnect, ни dns-prefetch, ни prerender. А скрипты они ставят, где ни попадя
vc по факту - приложение, там в RAW версии контента нету по сути. Я бы не стал сравнивать такое с обычным сайтом, пусть даже и js-rich.
Как на пример для подражания (или просто как на пример грамотно сделанного сайта) я смотрю на vc.ru и e-xecutive.ru.
Сравнивать свой сайт с другими некорректно, иная реализация, иной код, нельзя проводить прямое равнение и сходу заимствовать решение.
Если у вас популярная CMS, сравнивайте с аналогами.
У меня долгое время была ситуация когда я использовал готовый компонент и шаблон. Оптимизировать скрипты было невозможно без серьёзных передок. Попытки переделать и изменить порядок загрузки ломали необходимую функциональную последовательность. Для обновляемой линейки компонента подобные правки невозможны.
На одном из этапов обновления разработчик оптимизировал шаблон для связки с компонентом и после обновления проблема ушла сама собой.
Сейчас посмотрел скорость загрузки через pagespeed.
Для vc.ru моб. 29 (красн.), комп. 76 (желт.).
Для e-xecutive.ru моб. 44 (красн.), комп. 84 (желт.).
Для моего сайта 96/94, зеленый. Может, при таком раскладе, оставить все как есть? Если только redis добавить.