Comments 18
И в карму и статье. Браво! погромистам Сбера и всех остальных "ведущих" площадок - изучать наизусть! :)
К вам вопрос: что Вы им посоветуете (да вот даже Хабру) если страница тянет на 100+ запросов дозагрузки и весит 10+ метров? А то .. легко оптимизировать то, что весит 40килобайт.. там и так нет ничего..
Кстати, вопрос №2: как быть, если на страницу одновременно тянется тайпскрипт, вуй и ангуляр с реактом? ;)
ПС. вот выдача рыжелиса по этой страничке после написания основной части коммента. Да, стало заметно лучше, но .. как думаете, что тут можно оптимизировать ещё? :)
А чёт тут изучать то собственно? Лид учит джунов? Дожили. Ну пусть так, ладно.
Если осмыслить суть статьи, то тут банально везде "рекомендуется" применять паттерн Lazy Load. Это классика проектирования вообще-то. Хочешь чтоб быстро грузилось? Грузи только то что действительно нужно! Чаще всего это некий "общий скелет" (структура) и "первое мясо" (первый блок наполнения).
Всё "большое" очень и очень плохо! Всегда держи всё мелкими нарезками и подгружай лениво по необходимости. Это придумано ещё в прошлом веке. Этим помнится гордо били себя в грудь противника МСа 20 лет назад, гордо называя это AJAXом. Хотя МС ещё в 30 лет назад делал тоже самое, но под другим соусом. Паттерн ленивой загрузки известен уже полвека.
Ну для джунов я думаю статья "очень даже". Заодно есть повод изучить паттерны.
Всех с наступающим! )
Спасибо за обратную связь :)
По вашему вопросу: каждый сайт как правило уникальный, поэтому тут нет универсальной формулы. Как подметил @bert2000 , в статье я описала паттерн Lazy Load, можно следовать его принципам при оптимизации. На Хабре, например, ситуация не такая и плохая, просто немного раздутый js и внешние скрипты - можно поработать с этой частью.
По второму вопросу: а для чего это все на одной странице? В таком случае лучшая оптимизация - переписать фронт!)
Я, как "революционер" (и профессионал) конечно согласен с Вашим тезисом "лучшая оптимизация - переписать фронт!" (если это не шутка). Но Вас "за такое" могут и "к стенке поставить" же! ))) Слишком радикально и "дорого" (с нуля считай всё писать). Но по-сути верно. Применение паттерна ленивой загрузки можно автоматизировать. И да, это давно есть в виде компоновки (сборки) страниц, т.е. их генерации движками.
Такой же подход я использую и в базах данных , точно с таким же гарантированным результатом охрененного "повышения" производительности. Почему в кавычках написал? Да потому что изначально пишу оптимальный код и проекты, которые из коробки не нуждаются в оптимизациях и повышении производительности. Спагетти код действительно проще выбросить и на его месте написать нормальный. К сожалению столь "радикальные" для всех и вполне привычные для меня меры, часто просто всех пугают и всё. В общем и Вам не советую! ))))
С днём энергетика всех причастных.
Да, радикально и "дорого", но очень эффективно, плюс помимо оптимизации клиент получает современный дизайн и, как правило, лучшее ранжирование поисковиками
Такой же подход я использую и в базах данных
Что вы имеете ввиду, можете поподробнее?
А что там подробнее? Такая же ленивая загрузка из БД. Грузишь только то надо и первую страницу (пейджинг на 20-50 максимум 100 записей). Большие поля грузятся только по требованию, автоматически они вообще не загружаются. А вот системные (ID, метки разные, сессия, линки) грузятся "всегда" (без требований). Всё это базовые функции в моих ORM.
Т.е. суть та же - "первое мясо" (первая страница) + скелет (ID, метки и связи) загружаются сразу. Остальное потом-лениво (смотря что понадобится).
Не фронтендер, но приходилось тоже. Я бы дополнил паттерн ещё и YAGNI - стоит тщательно смотреть на полезность конкретно этой загрузки на конкретно этом этапе показа той или иной страницы. Часто браузеры ограничивают количество одновременных запросов на сайт небольшой чиселкой в 16шт одновременно, остальные да, встают в очередь.
И таки соглашусь, рефакторинг - перманентное состояние фронтов, т.к. новые дизайны, новые идеи .. всё это надо не только дополнять, но и вдумчиво рефакторить имеющееся.
Интересный туториал, было бы интересно узнать материал по кешированию
Мы наоборот разделили стили: выделили общие - в один файл, и разные файлы для разных категорий страниц (чтобы не тянуть на хомпейдже стили из блога). Но у нас огромная легаси база, до сих пор от третьего бутстрапа избавляемся
Отличный подход! На наших некоторых проектах используем тоже самое, так как почти все страницы уникальные и стили изначально пишем отдельно на каждую страницу. Но, как правило, на 90% сайтов нужно вручную разделять стили. Это крутой способ оптимизации, но очень трудозатратный, поэтому редко его используем
Туториал? Спасибо за заботу о джунах)
Кэширование (про генерацию страниц, а не статику) - это конечно хорошо, но нельзя забывать что кэш не вечен. И если некэшированная страница генерируется 5с, а после кэша 0.1с,то очень рано считать работу законченной...
Также бывает что кэширование работает только для анонимных запросов, а стоит пользователю войти на сайт в свой аккаунт, кэширование для него отключается и снова привет 5сек задержки при переходах по страницам.
А еще розовые мечты оптимизаторов про кэширование могут легко разбиться о хотелки владельца сайта :)
Например он заявит мол остатки или цены часто меняются и хочу чтоб всегда актуальные отображались, выключайте кэш...
Или например хочу чтоб в зависимости от того что за пользователь зашел (работа с geoip к примеру) отображалось что-то соответствующее на сайте, выключайте ваш дурацкий кэш, он мне мешает...
И ему не объяснишь что страницы долго генерируются, что нагрузка на сервер высокая - плевать, я перейду на тариф выше, пусть тормозит, пусть дорого будет, но я хочу вот так...
И в таком духе :(
И он абсолютно прав - если проблему можно решить просто отмасштабировавшись - это не проблема. Он смотрит с тз бизнеса, вы - как технарь. Об этом стоит помнить, принимая решения об оптимизации, в тч кэшировании.
Ну и большинство проблем, вами описанных, можно решить комбинированно, если это и поддержка этого будет стоить меньше простого масштабирования.
вы что то знаете о разных уровнях/видах кэширования?
например приведённых в 11 видов кэширования для современного сайта / Хабр (habr.com)
Да, вы правы - если страница генерируется 5 секунд, то работа еще не окончена! В приведенном мною примере, кеш собирается по блокам и имеет разное время жизни, поэтому 5 секунд она генерируется только при полной очистке кеша. Ну и@Shado_vi привел отличную статью про виды и уровни кеширования, поэтому отключать кеш не нужно, так как его можно настроить под все потребности бизнеса
Если страница генерируется 5 секунд на сервере, то что-то не так с кодовой базой бэка. Основная задержка генерации часто - выборка данных из БД, а не их пред- или пост- обработка. Современные БД при правильной архитектуре на современном сервере .. получить время отклика в секундах даже на 3-4 миллиардных данных, кмк, проблематично.
Скорее всего, проблема в правильном индексировании и тюнинге как архитектуры БД, запросов, так и самого сервера СУРБД или NoSQL, просто как пример:
Hidden text
Очень часто видел на беках применение разных фреймворков с автопостроителями запросов, где предварительно вытаскивается 100500 записей с идентами сущностей по условиям фильтрации, а потом с дополнительным фильтром в цикле запрашивает 2000 объектов из БД для формирования данных к странице поштучными запросами (Active Record во второй части) - никакой сервер не выдерживает сколько нибудь серъезной нагрузки! А ведь решение "на поверхности": достаточно собирать запрос, отдающий сразу нужное количество на страницу. Это редко где превышает сотню объектов, а часто 10-30, ибо "больше не лезет на экран". Но! Такой рефакторинг требует:
а) построения сложного запроса к БД, зачастую с позиционированием выдачи этого десятка, которая часто не тривиальна;
б) наличия спеца по (No)Sql, который напишет рабочий запрос в разумное время и сможет гарантировать его правильную работу для всех кейсов фильтра. Фильтр может оказаться сильно большим.
Как пример, параметрическая выдача набора товарных позиций (100шт, со второй страницы) по фильтру из десятка свойств товара на базе в миллион товаров в табличке и сервере Мускл 5.1 на 4-х ядерном ксеоне 3Ггц и 16Гб ОЗУ (больше не влезало) отдавал результат за 0.15сек, с дисковой подсистемой всего в 160мб/сек и гарантированным не впихиванием в память ни кеша ни тем более таблиц БД. При этом, на популярных позициях (кеширование индексов InnoDB - тюнингом) попадания в кеш наблюдались примерно в 95% случаев... 2011год. Выдача картинок к товарам - статикой nginx.
Но .. примерно подобная задача и "микросервисная архитектура" со всего тремя "микросервисами" уже на существенно усиленном сервере выполняется на порядок медленее, т.к. один микросервис делает модно-молодежную аутентификацию запроса (а вдруг кто пробрался внутрь системы? мелочь, но есть), второй выбирает из БД набор данных (часть) а третий добирает остатки из другой БД ибо "требуется рефакторинг, но пока никак" .. таймаут промеж микросервисов и 2 загрузки .. 1.5секунды "в кармане". :(
Ускорение загрузки сайта: туториал для джунов