Comments 39
когда бекенд фреймворк вроде Spring
или Asp.Net занимаются раздачей статики
Результаты тестов производительности dotnet не сходятся с этим утверждением.
https://www.ageofascent.com/2019/02/04/asp-net-core-saturating-10gbe-at-7-million-requests-per-second/
Я сам шарпист и пишу уже на .net core 3. Да, шарп действительно быстр, но реальная жизнь не ограничивается отдачей строки из программы. Нужно еще установить соединение, считать файлы с диска, сжать их, закешировать, навесить правильные заголовки и только потом отдать клиенту. На шарпе мало того что из коробки этого функционала нет, так и производительность будет все же поменьше.
Вообще-то весь перечисленный Вами функционал есть в коробке.
Соединения устанавливаются :)
Файлы читаются, сжимаются, кэшируются и отдаются.
Для этого надо отконфигурировать приложение в startup.cs
Насчёт производительность поменьше: на чём именно поменьше?
Со стороны java оставлю тут это
Как раз сравнение отдачи статики аппликейшен сервера vs nginx. Тесты не свежие, но тенденция сохраняется и сейчас. Nginx мы любим не только за скорость отдачи статики, но еще и за бесплатную возможность балансировки.
Как раз сравнение отдачи статики аппликейшен сервера vs nginx. Тесты не свежие, но тенденция сохраняется и сейчас. Nginx мы любим не только за скорость отдачи статики, но еще и за бесплатную возможность балансировки.
Прекрасные рекомендации подходящие, к сожалению, только для посадочных страниц не нуждающихся в индексации. Ибо гуглобот имеет версию хрома 42, а значит не загрузит ничего.
Не говоря уже о попытке поделиться такой страницей в социальных сетях у которых вообще NOSCRIPT.
Так что серверный рендер все еще ого-го. Впрочем ничто не мешает сделать очень упрощенный серверный рендер — только метатеги и минимальный контент для ботов.
Не говоря уже о попытке поделиться такой страницей в социальных сетях у которых вообще NOSCRIPT.
Так что серверный рендер все еще ого-го. Впрочем ничто не мешает сделать очень упрощенный серверный рендер — только метатеги и минимальный контент для ботов.
Во первых, вы не правы, гугл бот исправно индексирует SPA. И я вижу в результатах поиска содержимое своих SPA.
Во вторых, вы пропустили параграф. В котором говорится про ситуацию с ботами.
В третьих, вы пропустили раздел в котором говорится что надо поставить интересы пользователей выше интересов ботов.
Во вторых, вы пропустили параграф. В котором говорится про ситуацию с ботами.
В третьих, вы пропустили раздел в котором говорится что надо поставить интересы пользователей выше интересов ботов.
А с чего вы взяли, что пользователю нужна ваша анимация и тонны каких-то скриптов вместо простого текста, содержащего нужную ему инфу?
Ну, тогда вместо сплеш скрина можно поставить игрушку, чтобы посетитель не скучал пока загружается всё это добро.
Боюсь что вы не входите в большинство пользователей. Большинство более требовательно и хотят что бы не только работало, но и было красиво, эффектно, удобно.
Вот для примера два сайта вики и промо. И как вы думаете какой из них выберет пользователь? Там где скучный текст, или там где можно трейлеры посмотреть, музыку послушать, но все на скриптах…
Вот для примера два сайта вики и промо. И как вы думаете какой из них выберет пользователь? Там где скучный текст, или там где можно трейлеры посмотреть, музыку послушать, но все на скриптах…
Конечно же вики =)
Если мне интересен фильм, как видео, то я его целиком посмотрю, а не на трейлеры любоваться буду.
А если я ищу информацию. то вики намного удобнее (и грузится быстрее).
Если мне интересен фильм, как видео, то я его целиком посмотрю, а не на трейлеры любоваться буду.
А если я ищу информацию. то вики намного удобнее (и грузится быстрее).
Начинающие программисты как правило делают акцент на разработке разного рода красивостей (анимация, много графики), более опытные программисты акцентируют на функциональности и контенте.
Где встречал рекомендации по разработке сайтов, в котором говорилось, что главное — это контент. Если сайт будет красивым, то на него зайдут, скажут прикольно, покликают и уйдут навсегда. Также со временем все эти анимации и красивости надоедают пользователям, т.к. мешают сосредоточится на контенте и функциональности
Где встречал рекомендации по разработке сайтов, в котором говорилось, что главное — это контент. Если сайт будет красивым, то на него зайдут, скажут прикольно, покликают и уйдут навсегда. Также со временем все эти анимации и красивости надоедают пользователям, т.к. мешают сосредоточится на контенте и функциональности
Второй мне сперва дольше ждать загрузки пришлось, а потом ещё и скролить, чтоб получить хоть минимальную информацию о фильме.
Так что определённо первый.
Так что определённо первый.
Вы не том сайте спрашиваете мнение. Думаю что среди молодежи будет выбор марвела, а среди бородатых программистов вики, тем более таких как на хабре.
Судя по рейтингу интернет тотально сломан, и вместо html с анимашками надо возвращать epub =)
Непрерывно используем Lighthouse/PageSpeed Insights для оптимизации. С большинством постулатов соглашусь, особенно по части кол-ва узлов в DOM. Также много профита принесла выдача webp вместо jpg/png (кстати фаерфокс уже тоже поддерживает webp)
Но вот с этим не соглашусь:
И еще одна из рекомендаций, на которую имхо не стоит обращать внимание по причине невозможности исправлений
Но вот с этим не соглашусь:
если вы все еще рендерите html на сервере, то перестаньте уже это делать. Перенос процесса рендеринга на клиента на два порядка сокращает нагрузку на сервер и как результат стоимость поддержки серверного приложения. А клиенты получают приложение с мгновенной реакцией на их действия.Во-первых, не очень понятно, что включает в себя «стоимость поддержки серверного приложения», во-вторых: почему она растет то, если рендеринг происходит на стороне сервера перед отдачей клиенту и занимает в худшем случае 20% от всего времени обработки реквеста, а чаще 5%… ну 10% на очень сложных страницах. И это под нагрузкой, и хорошо видно в jprofiler.
И еще одна из рекомендаций, на которую имхо не стоит обращать внимание по причине невозможности исправлений
Задайте правила эффективного использования кеша для статических объектов
> И еще одна из рекомендаций, на которую имхо не стоит обращать внимание по причине невозможности исправлений
А вот это как раз решается проще, чем глобальная переопитимизация дерева DOM и сложности JS.
Скрипты яндекса и гугла загружаются кроном в локальную директорию по ночам и отдаются с нужным кешем (pragma/last-modified etc).
Ютуб iframe-ы (в нижних частях страницы) скрываются и грузятся в момент прокрутки страницы (таймауты всё равно нагрузят браузер через какое-то время и все равно гуглбот лайтхаусом ловит).
С яндекс картами сложнее — но если они в нижней части страницы, то грузить после прокрутки. Если в верхней — то загрузка будет долгой, никуда не денешься и кеш не выключишь.
А вот это как раз решается проще, чем глобальная переопитимизация дерева DOM и сложности JS.
Скрипты яндекса и гугла загружаются кроном в локальную директорию по ночам и отдаются с нужным кешем (pragma/last-modified etc).
Ютуб iframe-ы (в нижних частях страницы) скрываются и грузятся в момент прокрутки страницы (таймауты всё равно нагрузят браузер через какое-то время и все равно гуглбот лайтхаусом ловит).
С яндекс картами сложнее — но если они в нижней части страницы, то грузить после прокрутки. Если в верхней — то загрузка будет долгой, никуда не денешься и кеш не выключишь.
Серверный рендеринг увеличивает время до Time to Interact. С начало сервер тратит время на рендеринг, потом нарендереное передается клиенту (клиенты любуются белым экраном), потом клиенту передается SPA (что бы у пользователей не мелькал экран между переходами), потом происходит расчет нового дома и гидрация…
В случае отсутствия серверного рендеринга время до окончания запуска программы сильно меньше, а при повторном заходе вся программа уже будет на клиенте.
Время жизни кеша тоже полезная фича, хоть и не привычная. Lighthouse рекомендует выставить год. По хорошему для сброса такого кеша надо использовать хеш файла (как делает ангуляр), но я просто использую версии /scripts/main.min.js?v={version} которые расставляются при компиляции статики.
В случае отсутствия серверного рендеринга время до окончания запуска программы сильно меньше, а при повторном заходе вся программа уже будет на клиенте.
Время жизни кеша тоже полезная фича, хоть и не привычная. Lighthouse рекомендует выставить год. По хорошему для сброса такого кеша надо использовать хеш файла (как делает ангуляр), но я просто использую версии /scripts/main.min.js?v={version} которые расставляются при компиляции статики.
А какое значение tti считается допустимым? Пусть это будет страница продукта, как наиболее подходящая по понятие «лендинг страница»
Речь шла про сторонние ресурсы, а не свои собственные. Хотя пейдж спид ругается и на время жизни 90 дней.
/scripts/main.min.js?v={version}
Речь шла про сторонние ресурсы, а не свои собственные. Хотя пейдж спид ругается и на время жизни 90 дней.
сам гугл рекомендует SSR в своих видео по SEO, заодно там же рассказывают про то, почему и как хром обходит SPA(пусть и очень коротко, но примерно понять его логику становится возможно)
https://www.youtube.com/user/GoogleWebmasterHelp/playlists?view=50&sort=dd&shelf_id=10
Автор, снимаю шляпу. Можете сказать адрес сайта (или в личку кинуть)?
Я как разработчик (не веб) понимаю, что технологии не стоят на месте, «html не нужен», «сервер-рендеринг не нужен» и всё в таком духе, что это упрощает разработку и развёртывание сайта, что это на 3.5% ускоряет загрузку и что это best practices.
Но как пользователь — я вас ненавижу. Я не хочу смотреть на глюкавую анимацию загрузки, я хочу получить контент (пускай без css и скриптов, которые всё равно зарезаны noscript). Я хочу получить контент, даже если javascript не работает. Я хочу получить контент, даже если сижу в emacs из tty, и пускай контент будет уродливым — но он должен быть! Показывайте мне рекламу в текстовом виде или картинкой — я не против, но дайте мне контент без javascript и css!
Как только вижу такой сайт, как вы описываете, закрываю вкладку, ибо хочу, чтобы веб был простым и контент-ориентированным, а не набором жирных, кривых, уродливых, жрущих память и циклы процессора приложений.
Извините, накопилось.
Но как пользователь — я вас ненавижу. Я не хочу смотреть на глюкавую анимацию загрузки, я хочу получить контент (пускай без css и скриптов, которые всё равно зарезаны noscript). Я хочу получить контент, даже если javascript не работает. Я хочу получить контент, даже если сижу в emacs из tty, и пускай контент будет уродливым — но он должен быть! Показывайте мне рекламу в текстовом виде или картинкой — я не против, но дайте мне контент без javascript и css!
Как только вижу такой сайт, как вы описываете, закрываю вкладку, ибо хочу, чтобы веб был простым и контент-ориентированным, а не набором жирных, кривых, уродливых, жрущих память и циклы процессора приложений.
Извините, накопилось.
Ничего страшного, всё то вы описали имеет отношение к кривым рукам, и никак не связано с использованием js вместо html. Просто на js гораздо проще бездумнее выжрать всю память, чем на html =)
Пусть сайт хотя бы работает без JS — это решает проблему кривых рук.
Я не против расклада, когда желающие получают контент с помощью прогрессивного приложения на JS с заставками, анимациями и клиент-рендерингом. Только дайте же вы возможность получать контент в чистом HTML! Мне плевать, что он кривовато выглядит, зато меня выбешивает, когда его нет.
Я не соглашусь с выражением что необходимо переносить рендер html на клиент. Особенно если в первую очередь подразумевается экономия ресурсов сервера.
В 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.
В 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.
Считаю ленивую отрисовку бичом просто. Ну, открываете вы некую страницу в поисках конкретной инфы. а тебе на 1 экране вводный текст, шапка, баннер, ты начинаешь резко скроллить вниз, ибо контента дофига, а не скроллится, внизу же всё белое, всё ломается, а мне вывод нужен из этого контента, а он всегда снизу. И этот кошмар теперь повсеместно почти. Да, вы победили циферки в аудите, заказчик писает кипятком от радости, а UX просто в ноль.
Мне кажется, что основной контент и элементы навигации — это основное. На его скорость загрузки и отображения нужно поставить приоритет выше, чем для остальных свистелок. И пусть это будет просто текст на белом фоне — не важно. Красота пусть подтягивается своим ходом через несколько секунд, хотя даже в этом случае она не желательна, ибо трафик, память, батарейка.
Чтобы приблизиться к нестабильной сотне ( потому, что эта штука даже не может генерировать одинаковый результат ), уходит слишком много усилий и многие — на какую-то ерунду.
Приложение, делающее акцент на дизайн (никаких жутких подзагрузок), фоновые картинки и шрифты обязательны, 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, пусть бы даже и не столь «красиво», как предполагалось.
Это не мои фантазии, а то, с чем я сейчас борюсь :) Хотя, правда, благодаря всем предыдущим наработкам, приведшим к такой проблеме, у меня есть работа… «Нет худа без добра» (с), как гласит народная мудрость :)
Я это к тому рассказал, что любое утверждение надо сопровождать пояснением, когда оно применимо. И все его плюсы и минусы. Ибо нет ничего однозначно хорошего или плохого.
ПыСы. На англоязычных сайтах утверждается (если надо, найду ссылки), что будущее за «универсальными приложениями», SPA + SSR (Single Page Application + Server Site Rendering). А именно, это когда начальная версия страницы рендерится на сервере. Затем, пока юзер читает полученное, туда подтягиваются все файлы и данные, после чего начинает работает уже JS. При этом юзер может даже кликать по ссылкам и переходить на другие страницы сайта, не дожидаясь полной загрузки всего и вся. Ну и что также существенно, вся эта конструкция будет работать даже при выключенном JS, пусть бы даже и не столь «красиво», как предполагалось.
GZIP Включите и настройте сжатие ответов клиенту.
Кроме GZIP еще включаю Brotli — скорость быстрее, компрессия больше. Ну и прекомпрессию с максимальным уровнем сжатия для статичных файлов. Прекомпрессию для GZIP лучше всего делать через Zopfli c предварительной минификацией кода.
Минификация картинок
Для PNG лучший компрессор в WebP на базе Zopfli — zopflipng.
Для jpeg остановился на cwebp (меньше всего сбоев и размер файлов получается чуть меньше, чем у других компрессоров). Если жать с потерей качества, то нужно делать проверку на размер исходного файла и если размер меньше 100кб, жать с меньшими потерями или без них, а если больше, то можно поиграться с настройками.
Sign up to leave a comment.
Chrome Audit на 500: Часть 1. Лендинг