Comments 39
когда бекенд фреймворк вроде Spring
или Asp.Net занимаются раздачей статики
Результаты тестов производительности dotnet не сходятся с этим утверждением.
https://www.ageofascent.com/2019/02/04/asp-net-core-saturating-10gbe-at-7-million-requests-per-second/
Вообще-то весь перечисленный Вами функционал есть в коробке.
Соединения устанавливаются :)
Файлы читаются, сжимаются, кэшируются и отдаются.
Для этого надо отконфигурировать приложение в startup.cs
Насчёт производительность поменьше: на чём именно поменьше?
Производительность в том что С++ программы работают быстрее C# программ, а nginx годами затачивался на производительность отдачи статики.
Не говоря уже о попытке поделиться такой страницей в социальных сетях у которых вообще NOSCRIPT.
Так что серверный рендер все еще ого-го. Впрочем ничто не мешает сделать очень упрощенный серверный рендер — только метатеги и минимальный контент для ботов.
Во вторых, вы пропустили параграф. В котором говорится про ситуацию с ботами.
В третьих, вы пропустили раздел в котором говорится что надо поставить интересы пользователей выше интересов ботов.
Вот для примера два сайта вики и промо. И как вы думаете какой из них выберет пользователь? Там где скучный текст, или там где можно трейлеры посмотреть, музыку послушать, но все на скриптах…
Если мне интересен фильм, как видео, то я его целиком посмотрю, а не на трейлеры любоваться буду.
А если я ищу информацию. то вики намного удобнее (и грузится быстрее).
Где встречал рекомендации по разработке сайтов, в котором говорилось, что главное — это контент. Если сайт будет красивым, то на него зайдут, скажут прикольно, покликают и уйдут навсегда. Также со временем все эти анимации и красивости надоедают пользователям, т.к. мешают сосредоточится на контенте и функциональности
Так что определённо первый.
Но вот с этим не соглашусь:
если вы все еще рендерите html на сервере, то перестаньте уже это делать. Перенос процесса рендеринга на клиента на два порядка сокращает нагрузку на сервер и как результат стоимость поддержки серверного приложения. А клиенты получают приложение с мгновенной реакцией на их действия.Во-первых, не очень понятно, что включает в себя «стоимость поддержки серверного приложения», во-вторых: почему она растет то, если рендеринг происходит на стороне сервера перед отдачей клиенту и занимает в худшем случае 20% от всего времени обработки реквеста, а чаще 5%… ну 10% на очень сложных страницах. И это под нагрузкой, и хорошо видно в jprofiler.
И еще одна из рекомендаций, на которую имхо не стоит обращать внимание по причине невозможности исправлений
А вот это как раз решается проще, чем глобальная переопитимизация дерева DOM и сложности JS.
Скрипты яндекса и гугла загружаются кроном в локальную директорию по ночам и отдаются с нужным кешем (pragma/last-modified etc).
Ютуб iframe-ы (в нижних частях страницы) скрываются и грузятся в момент прокрутки страницы (таймауты всё равно нагрузят браузер через какое-то время и все равно гуглбот лайтхаусом ловит).
С яндекс картами сложнее — но если они в нижней части страницы, то грузить после прокрутки. Если в верхней — то загрузка будет долгой, никуда не денешься и кеш не выключишь.
В случае отсутствия серверного рендеринга время до окончания запуска программы сильно меньше, а при повторном заходе вся программа уже будет на клиенте.
Время жизни кеша тоже полезная фича, хоть и не привычная. Lighthouse рекомендует выставить год. По хорошему для сброса такого кеша надо использовать хеш файла (как делает ангуляр), но я просто использую версии /scripts/main.min.js?v={version} которые расставляются при компиляции статики.
/scripts/main.min.js?v={version}
Речь шла про сторонние ресурсы, а не свои собственные. Хотя пейдж спид ругается и на время жизни 90 дней.
сам гугл рекомендует SSR в своих видео по SEO, заодно там же рассказывают про то, почему и как хром обходит SPA(пусть и очень коротко, но примерно понять его логику становится возможно)
https://www.youtube.com/user/GoogleWebmasterHelp/playlists?view=50&sort=dd&shelf_id=10
Но как пользователь — я вас ненавижу. Я не хочу смотреть на глюкавую анимацию загрузки, я хочу получить контент (пускай без css и скриптов, которые всё равно зарезаны noscript). Я хочу получить контент, даже если javascript не работает. Я хочу получить контент, даже если сижу в emacs из tty, и пускай контент будет уродливым — но он должен быть! Показывайте мне рекламу в текстовом виде или картинкой — я не против, но дайте мне контент без javascript и css!
Как только вижу такой сайт, как вы описываете, закрываю вкладку, ибо хочу, чтобы веб был простым и контент-ориентированным, а не набором жирных, кривых, уродливых, жрущих память и циклы процессора приложений.
Извините, накопилось.
В 2012 на i7-3770 можно было открывать сотни сайтов без какой-либо загрузки cpu + было достаточно 4gb памяти, а если на борту было 8gb то даже не было мыслей что память может закончится.
В 2019 уже i9-9900k с 16gb при открытии gmail загружается на 20%. Можно создать ситуацию когда открытие сразу нескольких тяжелых сайтов доведет загрузку почти до 100%. А все из-за огромного количества логики которая стала лишней на сервере. Кстати, тот же gmail на raspberry pi 3b+ уже едва можно открыть: загрузка и инициализация занимает более 30 секунд, забирая почти всю доступную память на устройстве. Так что нет, лучше не надо переносить логику с сервера если того не требуют обстоятельства.
Так же мало кто задумывается про fps в браузере. Да, да, он так же важен как и в играх. Например, сайт Uber Eats использует React (если не ошибаюсь), все рендерится на фронте. Открываешь такой сайт чтобы заказать поесть, выбираешь ресторан, но то и дело картинка какая-то дерганная, глаз постоянно цепляется. А все дело в том что компоненты рендерятся налету и, видимо, без перерыва, что заставляет браузер постоянно перерисовывать страницу. На 165гц мониторе особенно заметно, будто смотришь на кинескоп, как в девяностые. Уверен что рано или поздно разработчики станут обращать внимание на провалы в fps и станут относиться к этому так же как к оптимизации много-мегабайтных картинок.
Остальные советы как по мне — годные. Отметил бы что начинать надо с сервера. Слабая машина не сможет выполнять работу с любыми оптимизациями. Далее нужно более-менее грамотно настроить nginx (apache стараться избегать). Два этих действия вместе уже дадут 80% оптимизации которой очень не хватает половине всех сайтов.
Решил добавить пример сайта где соблюден баланс в фичах и быстродействии. DTF.
Чтобы приблизиться к нестабильной сотне ( потому, что эта штука даже не может генерировать одинаковый результат ), уходит слишком много усилий и многие — на какую-то ерунду.
Приложение, делающее акцент на дизайн (никаких жутких подзагрузок), фоновые картинки и шрифты обязательны, SSR необходим, как на зло Offline-first используется и полезен.
На входе:
Серверный рендеринг с кешированием всего, что "толкается" — делает свое дело.
Скрипты подгружаются асинхронно; по HTTP/2; сжаты. Бандл поделен на множество модулей.
CDN отдает изображения в WebP, в 3 размерах и ориентациях.
Offline-first после первой загрузки.
Приходится бороться с снижением рейтинга за низкую скорость загрузки шрифтов…
Гуглом. С CDN гугла. Перенося все на слоупок-локальный сервер.
Проблемами с кешированием SW (дикий рост TTI), с интерпретацией defer скриптов как обязательных.
По итогу, в борьбе за последние 10-15 рейтинга(mobile) приходится использовать оптимизации и технологии, которые не сдались даже крупнейшим проектам. Буквально кровью, потом и перебором.
И вроде все это круто. А приятель рядом открывает страничку с идеальной сотней…
(у посетителей нормально рендерится)
Это не мои фантазии, а то, с чем я сейчас борюсь :) Хотя, правда, благодаря всем предыдущим наработкам, приведшим к такой проблеме, у меня есть работа… «Нет худа без добра» (с), как гласит народная мудрость :)
Я это к тому рассказал, что любое утверждение надо сопровождать пояснением, когда оно применимо. И все его плюсы и минусы. Ибо нет ничего однозначно хорошего или плохого.
ПыСы. На англоязычных сайтах утверждается (если надо, найду ссылки), что будущее за «универсальными приложениями», SPA + SSR (Single Page Application + Server Site Rendering). А именно, это когда начальная версия страницы рендерится на сервере. Затем, пока юзер читает полученное, туда подтягиваются все файлы и данные, после чего начинает работает уже JS. При этом юзер может даже кликать по ссылкам и переходить на другие страницы сайта, не дожидаясь полной загрузки всего и вся. Ну и что также существенно, вся эта конструкция будет работать даже при выключенном JS, пусть бы даже и не столь «красиво», как предполагалось.
GZIP Включите и настройте сжатие ответов клиенту.
Кроме GZIP еще включаю Brotli — скорость быстрее, компрессия больше. Ну и прекомпрессию с максимальным уровнем сжатия для статичных файлов. Прекомпрессию для GZIP лучше всего делать через Zopfli c предварительной минификацией кода.
Минификация картинок
Для PNG лучший компрессор в WebP на базе Zopfli — zopflipng.
Для jpeg остановился на cwebp (меньше всего сбоев и размер файлов получается чуть меньше, чем у других компрессоров). Если жать с потерей качества, то нужно делать проверку на размер исходного файла и если размер меньше 100кб, жать с меньшими потерями или без них, а если больше, то можно поиграться с настройками.
Chrome Audit на 500: Часть 1. Лендинг