Похоже, что Lighthouse 6 вводит некоторые новые метрики и удаляет некоторые другие из v5, поэтому изменение оценки, безусловно, вероятно. В этой статье объясняется, что изменилось:

https://web.dev/lighthouse-whats-new-6.0/

В конце также есть ссылка на калькулятор баллов, который действительно полезен для разбивки баллов и понимания того, какие факторы вносят наибольший вклад.

https://googlechrome.github.io/lighthouse/scorecalc

У меня сложилось впечатление, что в версии 6 больше внимания уделяется интерактивности основного потока, поэтому, если ваш сайт включает в себя большие пакеты JS, это, вероятно, является значительным фактором.

Да @shanekenney , я в курсе, но на самом деле не знаю, как уменьшить его, кроме удаления частей сайта, чтобы увидеть, какие части провоцируют это

Вы также замечаете влияние на сайты gaysbyjs и theme-ui? Мне любопытно / хотелось бы узнать, о каких оптимизациях на своем сайте они думают или заметили ли они какую-то конкретную причину.

Это серьезная проблема, поэтому мы можем обсудить общие оценки Lighthouse / PageSpeed ​​Insights и возможные регрессии, которые мы наблюдаем с v6.

@kuworking Стоит отметить одну вещь:

Этот тест для 922 сайтов утверждает, что в версии 5 средняя оценка производительности для сайта Gatsby составляет 75 . Я попытаюсь сделать быстрый просмотр, используя размещенные решения, чтобы моя локальная сеть не была еще одним фактором изменчивости.

В настоящее время (с Lighthouse v5.6 / PageSpeed ​​Insights)

PSI работает на Moto G4 на «Fast 3G». Источник

Некоторые сайты-пометки, созданные с использованием Gatsby, на самом деле не очень эффективны на PageSpeed ​​Insights (который, как я полагаю, все еще использует Lighthouse v5.6 - с учетом стандартной изменчивости при каждом запуске, возможно, запуск 3x или 5x и усреднение будет весить более надежные показатели ) .

• gatsbyjs.org (Mobile 72/100, TTI 9s) Источник
• reactjs.org (Mobile 62/100, TTI 9.5s) Источник
• gatsbyjs.com (Mobile 77/100, TTI 6.6s) Источник

Однако некоторые другие сайты (и большинство начинающих) очень хорошо работают с PageSpeed ​​Insights:

• store.gatsbyjs.org (Mobile 99/100, TTI 2.5s) Источник
• thirdandgrove.com (Mobile 91/100, TTI 4.0s) Источник

Средний TTI заметен - и хотя v6 изменяет общий вес TTI с 33% до 15% и снижает First CPU Idle, он добавляет TBT с весом 25%, что, возможно, может объяснить регрессию оценок, вообще говоря, просто из-за общий анализ и выполнение JS.

Lighthouse v6 (с WebPageTest.org )

• Это запускало WPT на _Moto G (поколение 4), Moto G4 - Chrome_ с подключением _3G Fast (1,6 Мбит / с / 768 кбит / с 150 мс RTT) _. Похоже, что это максимально возможное совпадение устройства / сети до того, как PSI обновит свою базовую версию Lighthouse.
• Не забудьте проверить _Capture Lighthouse Report_ в _Chromium_. Я отключил повторный просмотр, чтобы сохранить область видимости для первого посетителя при первой загрузке страницы.

Вот результаты, вы можете увидеть отчет Lighthouse, нажав на его номер. Я извлекаю значения из этого отчета.

• gatsbyjs.org (72 -> 67/100, TTI 7,5 с, TBT 2150 мс) Источник
• reactjs.org (62 -> 66/100, TTI 7.8s, TBT 3520ms) Источник
• gatsbyjs.com (77 -> 66/100, TTI 8,4 с, TBT 2440 мс) Источник

Однако обратите внимание на регресс на следующих двух сайтах:

• store.gatsbyjs.org ( 99 -> 54/100 , TTI 6,8 с, TBT 1300 мс) Источник
• thirdandgrove.com ( 91 -> 63/100 , TTI 14s !, TBT 1330ms) Источник

Некоторые из открытых вопросов у меня есть.

1. Объясняется ли общий TTI (и TBT) парсингом + выполнением JS, или есть другие факторы, мешающие интерактивности?
2. Если это так, можем ли мы быть более агрессивными (либо в Gatsby по умолчанию, например, последние изменения, такие как включение гранулированных фрагментов , или под некоторым экспериментальным флагом) при создании фрагментов, чтобы _только_ посылать то, что требуется этой первой загрузке (то есть предотвращать приложение- [хэш] .js от избытка)? Это также может быть просто документирование способов поиграть с расширением конфигурации веб-пакета с дополнительными инструкциями.
3. Могут ли такие шаблоны, как Module / nomodule, помочь уменьшить количество фрагментов? Рекомендовать / документировать использование @ loadable / components? Частичная регидратация ?
4. Это может быть вторым шагом на пути к достижению высоких результатов, но поскольку FMP больше не является фактором, помогает ли LQIP на gatsby-image когда дело касается LCP? LCP store.gatsby.org на показанном выше прогоне составлял 4,7 секунды!

(Я использую приведенные выше ссылки только в качестве примеров - если кто-то захочет удалить определенную ссылку, я с радостью могу отредактировать сообщение)

Мой сайт (https://matthewmiller.dev/), похоже, стал лучше (от ~ 92 до ~ 95), но некоторые из новых тестов выявили несколько вещей, которые, вероятно, можно было бы улучшить.

Например, ненужный тест JavaScript,
(Первый столбец - размер, второй столбец - ненужная сумма)

Я предполагаю, что это связано с тем, что сюда включены элементы, необходимые для других страниц, поэтому использование чего-то вроде loadable-components может немного помочь.

Для меня у меня большие трудности с пониманием Largest Contentful Paint , в том смысле, что я получаю очень большие значения, не зная почему, и вижу расхождение между значением в отчете (например, 7,4 с и LCP метка, которая появляется на вкладке Performance - ViewTrace (~ 800 мс)

Я вижу, что что-то похожее происходит в стартере https://parmsang.github.io/gatsby-starter-ecommerce/

В качестве обновления - похоже, что PageSpeed ​​Insights мягко запустила обновление для запуска Lighthouse v6 (возможно, это еще не во всех регионах).

Ссылка на тест https://gatsbyjs.org/ . В настоящее время получаются результаты, варьирующиеся от низких 60 до середины 80, в основном в зависимости от значений TBT и TTI.

@kuworking может быть проблема с Lighthouse v6, распознающим gatsby-image.

Согласно webdev

Для элементов изображения, размер которых был изменен по сравнению с их внутренним размером, размер, о котором сообщается, является либо видимым размером, либо внутренним размером, в зависимости от того, что меньше.

В моем случае я думаю, что Lighthouse не соблюдает размер обзора.

И вот изображение, о котором идет речь

Возможно, это связано с внутренним размером, который составляет 3000 пикселей, поэтому для меня 13s LCP.

@ daydream05 У меня тоже были похожие теории и выводы, поэтому я тестировал свои страницы без изображений, и у меня все еще был сумасшедший длинный LCP (10-12 секунд). В моем проекте много чего происходит, так что это могут быть и другие переменные, но мне любопытно, тестировали ли вы страницу с текстовым контентом и еще без изображений.

Недавно упало со 100 до 79 ~ https://dougsilkstone.com/ . Повышается до 90 при удалении Диспетчера тегов Google (и Google Analytics).

Сообщу о других выводах по мере того, как буду тестировать.

Изменить: нажмите 100 при удалении шрифта, загруженного набором шрифтов, из gatsby-plugin-web-font-loader (также с использованием кеша предварительно загруженных шрифтов).

GTM в целом влияет на мой проект, но это не так уж и радикально, когда я удаляю его (5–10 баллов при оценке ниже 50 после LH6). Мне все еще нужно провести дополнительное тестирование, но я просто хотел выбросить это там.

@Jimmydalecleveland интересно! У меня также есть другой сайт, где на экране я просто текст, и он обвиняет текст героя в качестве основной причины LCP. И LCP учитывает только то, что находится в поле зрения, что не имеет смысла. Как текст может быть такой большой проблемой.

@dougwithseismic Я также использую typekit, и он определенно является одним из основных виновников низких оценок Lighthouse. Я бы хотел, чтобы был способ исправить typekit, так как они не поддерживают отображение шрифтов

Я думаю, что Lighthouse v6 действительно сложен для JS-фреймворков, потому что они изменили вес баллов. (Больше внимания уделяется времени блокировки). А сайты Gatsby имеют исторически низкие оценки скриптов / основных потоков из-за регидратации и других факторов.

@dougwithseismic как вы связали шрифт typekit без использования таблицы стилей?

У меня похожий опыт: с Lighthouse 5.7.1 моя оценка производительности была около 91, однако Lighthouse 6 резко снизила мою оценку примерно до 60.

Недавно упало со 100 до 79 ~ https://dougsilkstone.com/ . Повышается до 90 при удалении Диспетчера тегов Google (и Google Analytics).

Сообщу о других выводах по мере того, как буду тестировать.

Изменить: нажмите 100 при удалении шрифта, загруженного набором шрифтов, из gatsby-plugin-web-font-loader (также с использованием кеша предварительно загруженных шрифтов).

У меня даже не установлены эти плагины, но мой мобильный рейтинг упал с 90+ до 60 ~ 70+.

Тоже самое. Значительное падение с 90 до 60 на нескольких сайтах.

+1 падение около 30+ очков

Кто-нибудь занимается этим? Похоже, нет смысла использовать Gatsby вместо Next, если он не дает лучших результатов сразу.

Кто-нибудь занимается этим? Похоже, нет смысла использовать Gatsby вместо Next, если он не дает лучших результатов сразу.

У вас есть номера из Next?

Мне интересно, являются ли эти оценки новой нормой для быстрых веб-сайтов (которые не статичны, не содержат JS и, вероятно, также не содержат изображений)

У вас есть номера из Next?

https://nextjs.org/ набрал 85 баллов, причем главными нарушителями являются как самая большая Contentful Paint (3.8), так и First Contentful Paint (2.8). Также в нем есть "Неиспользуемый JS". Это ниже ~ 95 в Lighthouse 5.7.1. Это «всего» падение примерно на 10 баллов, тогда как сайты гэтсби, кажется, теряют вдвое больше баллов.

Я новичок в этом мире, но я слежу за этой проблемой после того, как мой сайт gatsby потерял около 25 баллов при тестировании с lighthouse 6.0.0 от npm. Интересно, что если я использую Pagespeed Insights, а не npm lighthouse, мой сайт возвращается к ~ 99. В то время как gatsbyjs.org получает ~ 70 по скорости страницы, но ~ 84 с npm lighthouse. Наверное, что-то где-то подправляют? Все они получают предупреждения о неиспользованном JS, хотя

Кто-нибудь занимается этим? Похоже, нет смысла использовать Gatsby вместо Next, если он не дает лучших результатов сразу.

У вас есть номера из Next?
Мне интересно, являются ли эти оценки новой нормой для быстрых веб-сайтов (которые не статичны, не содержат JS и, вероятно, также не содержат изображений)

Сайт Next.js -> https://masteringnextjs.com/ 77 баллов для мобильных устройств. Много "неиспользованного JS".

Я вижу лучшие результаты с Lighthouse-metrics https://lighthouse-metrics.com/one-time-tests/5edfbbb1cf858500080125f7

Но я также не вижу там изображений, и по моему опыту изображения, кажется, имеют большое (и законное ИМО) влияние.

Тем не менее, у gatsbyjs.org нет изображений, и его оценка (относительно) плохая https://lighthouse-metrics.com/one-time-tests/5edfbc58cf858500080125ff (по сравнению с примером @cbdp )

Посмотрим, что думают об этом разработчики Gatsby

С некоторыми изменениями сайт вернулся к лучшим результатам.

Мне кажется, что Google переместил цели, чтобы они были более
строгое отношение к производительности - особенно FCP.

Наши сайты ни в коем случае не медленные, более того, их оценивают разными
критерии. Я помогу с этим ✌️

Во вторник, 9 июня 2020 г., 18:48 kuworking, [email protected] написал:

Кто-нибудь занимается этим? Кажется, нет смысла использовать Гэтсби вместо
Затем, если он не дает лучших результатов сразу же.

У вас есть номера из Next?
Мне интересно, являются ли эти оценки новой нормой для быстрых сетей (что
не статичны, не содержат JS и, вероятно, также не содержат изображений)

Сайт Next.js -> https://masteringnextjs.com/ 77 баллов для мобильных устройств. Много
"Неиспользуемого JS".

Я вижу лучшие результаты с Lighthouse-Metrics
https://lighthouse-metrics.com/one-time-tests/5edfbbb1cf858500080125f7

Но я также не вижу там изображений, и по моему опыту изображения кажутся
иметь высокое (и законное ИМО) влияние

Тем не менее, у gatsbyjs.org нет изображений, и его оценка (относительно) плохая.
https://lighthouse-metrics.com/one-time-tests/5edfbc58cf858500080125ff
(по сравнению с примером @cbdp https://github.com/cbdp )

Посмотрим, что думают об этом разработчики Gatsby

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/gatsbyjs/gatsby/issues/24332#issuecomment-641433463 ,
или отписаться
https://github.com/notifications/unsubscribe-auth/ALSIKRH4G74CRN2FNCUO4NDRVZRVNANCNFSM4NHP7XCA
.

Просто хотел отказаться от этого полезного калькулятора для сравнения результатов v6 с v5: https://googlechrome.github.io/lighthouse/scorecalc/

Оценки Lighthouse обычно сильно различаются, даже при использовании его через PageSpeed ​​Insights. Например, для https://www.gatsbyjs.org/ я получил все от 64 до 88 мобильной производительности после 5 прогонов. Следовательно, для отслеживания этой проблемы калькулятор может быть полезен, чтобы увидеть последствия разных весов в одном и том же прогоне (примечание: поскольку метрики немного отличаются, некоторые значения, такие как FMP, должны приниматься с использованием предыдущих измерений).

PS: Здесь у меня есть сравнение двух прогонов из PageSpeed ​​Insights для gatsbyjs.org:
Запуск 1 - v6: 67 - v5: 85
Запуск 2 - v6: 78 - v5: 87
Наибольшее влияние оказывает новая метрика «Общее время блокировки», которая в обоих прогонах ниже 70 баллов и имеет вес 25%.

Да, чтобы добавить к @Pyrax : LCP (самая большая содержательная краска) и TBT весят по 25% каждый в Lighthouse v6. Поэтому мы сосредоточили свои усилия на их решении. Мы нашли:

LCP

• Удаление любых анимаций, которые могут запускаться при загрузке (например, cookie 💩 баннер).
• Переход на tracedSVG gatsby-img, похоже, немного помог, поскольку на большинстве страниц у нас есть большие изображения героев. (Не уверен, почему на самом деле, без дальнейшего исследования. UX тоже немного улучшается.)

TBT

• По большому счету, Unused JS из пакета Gatsby кажется самым большим cuplrit (резервная копия документации web.dev ), по большому счету. Несомненно, здесь можно улучшить дрожание деревьев на уровне страниц?

Это недавнее обновление Lighthouse, кажется, только что испортило все показатели производительности, включая их собственные:

Единственный мой сайт о Гэтсби, который на самом деле не был уничтожен, - это сайт, который в основном состоит из одной страницы и на 99% похож на HTML. Но даже этот упал примерно на 5-10 баллов.

Хотя я вижу обратное для большинства людей, то есть Lighthouse в браузере Chrome по-прежнему показывает хорошие результаты для моего сайта, но при запуске на PageSpeed ​​Insights он снижает оценку производительности на 20-30 баллов ... возможно, моя версия Chrome Lighthouse позади? Chrome последняя версия, не знаю, как проверить встроенную версию Lighthouse ...

Это недавнее обновление Lighthouse, кажется, только что испортило все показатели производительности, включая их собственные:

Единственный мой сайт о Гэтсби, который на самом деле не был уничтожен, - это сайт, который в основном состоит из одной страницы и на 99% похож на HTML. Но даже этот упал примерно на 5-10 баллов.

Хотя я вижу обратное для большинства людей, то есть Lighthouse в браузере Chrome по-прежнему показывает хорошие результаты для моего сайта, но при запуске на PageSpeed ​​Insights он снижает оценку производительности на 20-30 баллов ... возможно, моя версия Chrome Lighthouse позади? Chrome последняя версия, не знаю, как проверить встроенную версию Lighthouse ...

Версия Lighthouse показана внизу аудита.

@dylanblokhuis а, да, вот оно что. Я использую версию 5.7.1, версия 6 еще не поставляется в Chrome?

@dylanblokhuis а, да, вот оно что. Я использую версию 5.7.1, версия 6 еще не поставляется в Chrome?

Нет. Во всяком случае, пока нет. Если вам нужна последняя версия, вы можете установить ее из npm, а затем запустить lighthouse https://yoursite.com --view и вы получите свой результат в том же формате, что и при аудите Chrome :)

Для всех, кто получил большой успех, # 24866 также может быть актуален. По-видимому, произошли довольно значительные изменения в том, как Гэтсби передает фрагменты. Хотя это изменение определенно имеет большой смысл, по крайней мере для нас, это изменение привело к тому, что код, который был распределен по фрагментам, сконцентрировался в фрагментах commons и app . Это означает значительно большую загрузку / синтаксический анализ js.

Больше всего беспокоит то, что эти показатели сравнительно скоро начнут влиять на Page Rank.

Я удалил все сторонние запросы (Диспетчер тегов / Typekit / Pixel / Analytics / ReCaptcha), и это дает лишь относительно небольшой прирост очков, так что здесь есть кое-что еще.

Кроме того, для всех, кто хочет запустить Lighthouse 6 локально, он теперь доступен в Chrome Canary и планируется к выпуску в Chrome в июле.

Во-первых: я связался с инженером Google, работающим над web.dev, и спросил об этом. Не уверен, что это приведет к большему объяснению, но, похоже, они намереваются помочь. Я свяжусь с ними, когда мне удастся поговорить с ними.

Моя успеваемость повысилась с 94–99 до 40–55. 😢

Самая большая Contentful Paint для моего сайта в основном применяется на страницах с большими изображениями. По какой-то причине говорится, что изображения загружаются около 14 секунд.

Если вы откроете любой из минимальных стартовых сайтов Gatsby , любые страницы с изображениями будут соответствовать максимальному значению 70-х годов.

Вот первые два стартера, которые я видел на многих изображениях:

ghost.gatsby.org :

gcn.netlify.app :

Тем не менее, у стартового блога Gatsby 98 производительность (конечно, это супер-минимальная страница с небольшим количеством текста):

gatsbyjs.com :

Сравните старые результаты с новыми результатами в Chrome

Вы по-прежнему можете сравнивать оценки старого и нового метода Lighthouse без использования интерфейса командной строки. Я считаю полезным посмотреть, что изменилось.

Посмотреть старые тесты Lighthouse

Чтобы просмотреть старые оценки Lighthouse, запустите расширение Lighthouse для Chrome из инструментов разработчика Chrome, а не из панели инструментов браузера.

Посмотреть новые тесты Lighthouse

Щелкните значок на панели расширений Chrome.

Моя страница меняется

Вот две оценки одной и той же страницы:

Старый маяк (с помощью инструментов разработчика Chrome)

Новый маяк (через расширение Chrome в адресной строке)

🤷‍♂️

@nandorojo, у меня впечатление от изображений, что эмуляция выполняется с очень медленным соединением, и там изображения действительно долго обрабатываются

Поскольку возможность удаления изображений не всегда возможна, возможно, эти оценки 70-х являются нормальными для этого типа страниц.

И возможность отложить их загрузку, чтобы пользователь мог начать свое взаимодействие раньше, похоже, не помогает (в моем случае)

Эй, извините за поздний ответ. Я работал над Lighthouse, постараюсь объяснить как можно лучше.

Разработчики Chrome опубликовали «Web Vitals», основные показатели для работоспособности сайта. Он содержит множество метрик, но основными из них являются наибольшая отрисовка содержимого (LCP) , задержка первого ввода (FID) и совокупный сдвиг макета (CLS) . Для таких инструментов, как Lighthouse, FID заменяется на общее время блокировки (TBT) .

Lighthouse v6 также принимает во внимание эти показатели и изменился. Это не значит, что Гэтсби медлителен. Возможно, потребуются другие оптимизации.

Вот как все изменилось:

Если вы хотите узнать больше о LCP, посетите https://www.youtube.com/watch?v=diAc65p15ag.

Итак, поговорим о Гэтсби. Сам Гэтсби по-прежнему довольно быстр, и мы улучшаем его еще больше. Мы создаем новый API, чтобы конструкторы страниц, такие как MDX, форматированный текст Contentful, ... также могли оптимизировать пакет. Многое можно сделать, оптимизировав LCP. Убедитесь, что при использовании шрифтов и изображений они не загружаются лениво и загружаются как можно скорее. Эти ресурсы должны быть загружены из того же источника, что и ваш сайт, они не должны загружаться из CDN.

К сожалению, TBT - это сложная проблема, для которой React не оптимизирует. Если вы хотите отказаться от TBT, вам следует заранее оформить заказ. Preact имеет тот же API, что и React, но занимает меньше места в javascript. Они работают по-другому, но компоненты React совместимы. Вы устанавливаете его, запустив gatsby recipes preact .

При профилировании gatsbyjs.com и gatsbyjs.org я заметил кое-что, что мы должны загрузить аналитику Google и т. Д. Немного позже, чем сейчас, чтобы убедиться, что она не станет частью TBT.

Если мы посмотрим на .com, отложив аналитику и GTM и убедившись, что шрифты загружаются быстрее, мы уже увидим улучшение на +17. Если мы добавим преакт в микс, мы увидим +6.

Мы можем сделать то же самое для .org, начнем с 63 баллов. С некоторой оптимизацией LCP и TBT мы можем получить 75.

Я не уверен, что нам делать с этой проблемой. Я чувствую, что мы можем закрыть его, потому что здесь мы больше ничего не можем сделать. Что вы все думаете?

@wardpeet Тая за дополнительную информацию.

Мы много копались в этом вопросе в большом проекте Gatsby, который у нас есть, который использует Contentful и будет использоваться для нас на нескольких сайтах (темы Gatsby потрясающие). Я поделюсь некоторыми выводами на случай, если они будут полезны для всех, кто смотрит на это.

1. У нас есть ситуация, которая может быть не очень распространенной, но я видел ее достаточно, чтобы поверить, что она не такая уж уникальная, когда нам пришлось использовать useStaticQuery для захвата изображений, поступающих из Contentful и .find one по идентификатору. Мы всегда знали, что это неправильно, но не получали за это заметных наказаний, пока масштаб сайта не увеличился до 300+ изображений, и LH6 не появился и не поразил нас.

Причина этого в том, что изображения являются частью встраивания Rich Text, и мы не можем использовать для них graphql на уровне запроса страницы (по сути, это поле json, которое Contentful имеет пакеты для анализа). При использовании анализатора пакетов Webpack мы заметили большой файл JSON (около 720 КБ) и отследили, что это данные этого запроса, которые были сгруппированы в шаблон, который мы используем для большинства страниц с помощью Webpack. Это означало, что каждый пользователь, посещающий наш сайт, загружал его как часть блока для всего шаблона страницы, независимо от того, использует ли страница какие-либо изображения или нет.

С нашей стороны, это большая глупость, но если кто-то еще выполняет большие статические запросы (которым вы, конечно, не можете передавать параметры, чтобы уменьшить размер), убедитесь, что вы следите за этими ситуациями и следите за своими фрагментами пакета.

1. Только сегодня мы добились определенного успеха, применив опору loading для изображения Гэтсби на изображениях, которые находятся в верхней части страницы (изображения Hero для нас). Мы пытались работать над самой большой Contentful Paint, и это дало хорошие результаты в некоторых начальных тестах. Есть важная часть, которую я почти пропустил: если вы установите loading="eager" для самого верхнего изображения, вы можете также установить fadeIn={false} для этого изображения, потому что переход между base64 и полностью загруженным изображение требует времени, которое задерживает LCP.

Вот документация по реквизитам, о которой я говорю, а заметка о fadeIn находится внизу: https://www.gatsbyjs.org/packages/gatsby-image/#gatsby -image-props

Я хотел бы поделиться скриншотами, но не знаю, можно ли, извините. Если вы используете Chrome devtools и посмотрите на панель производительности, вам будут предоставлены маленькие симпатичные теги под строкой «тайминги» для FP, FCP, FMP и LCP. Когда мы перешли на критическую загрузку первого изображения, мы не только увидели увеличение производительности на ~ 8-10, но и вы можете увидеть, что тег LCP загружается сразу после FMP, а не через секунду или около того в моем случае.

Надеюсь, что это поможет кому-нибудь устранить эту неполадку, и спасибо всем, кто ответил до сих пор.

При профилировании gatsbyjs.com и gatsbyjs.org я заметил кое-что, что мы должны загрузить аналитику Google и т. Д. Немного позже, чем мы знаем, чтобы убедиться, что она не станет частью TBT.

@wardpeet, как ты откладываешь аналитику и GTM?

@wardpeet благодарит за ответ. Это полезно. Возможно, лучшим выходом из этой проблемы будет некоторая документация, описывающая, как оптимизировать для каждого из показателей в новом Lighthouse. Я уверен, что наш сайт воспринимается пользователями быстро, и что сам Гэтсби проделывает большую работу по оптимизации сайта для реальных пользователей. Однако, если Google Web Vitals начнет информировать о рейтинге страницы, получение хорошей оценки маяка станет критически важным для большинства сайтов.

@Jimmydaleclevel и у нас была аналогичная проблема, когда нам нужно было загрузить все элементы ресурса, чтобы мы могли использовать данные из разметки для настройки фильтра (т.е. мы не могли фильтровать с помощью GraphQL) и оптимизировали с помощью различных фрагментов ( гораздо меньшее подмножество полей) при загрузке полного ресурса по сравнению с загрузкой всех ресурсов для фильтрации. Это значительно уменьшило наш JSON и, следовательно, размер нашего пакета.

@treyles, вам нужно быть осторожным, откладывая загрузку Analytics, так как это может означать, что ваша статистика неполная. Например, это может означать, что ваш отчетный показатель отказов не точен. Есть некоторые скрипты, которые маркетинг не позволяет нам отложить (пиксель, аналитика, hotjar и, следовательно, менеджер тегов), но другие, например, Intercom, подходят и требуют оптимизации. Что касается того, как отложить эти сценарии, сценарии, предоставленные третьими сторонами, обычно загружают асинхронно, но одного этого недостаточно. Вам, вероятно, потребуется заменить эти скрипты своими собственными. Прослушайте window.load, затем запустите загрузку. Тем не менее, вам нужно быть осторожным, так как некоторые скрипты для инициализации полагаются на window.load, и если вы использовали его для загрузки скрипта, он больше не запустится, поэтому вам нужно инициализировать их вручную. Например, с помощью Intercom мы:

• удалили ошибку <script>...</script> предоставленную Intercom.
• добавил слушателя для window.load
• добавлена ​​небольшая задержка в этом слушателе
• запустил измененную версию скрипта по умолчанию Intercom, который загрузил их lib async.
• опрашивается, чтобы узнать, когда был загружен скрипт (Интерком не обеспечивает надежного события)
• вручную инициализировали свой скрипт (что было сделано на странице page.load скриптом по умолчанию).

@wardpeet спасибо за очень полезную информацию!

Относительно этого решения:

Убедитесь, что при использовании шрифтов и изображений они не загружаются лениво и загружаются как можно скорее. Эти ресурсы должны быть загружены из того же источника, что и ваш сайт, они не должны загружаться из CDN.

Разве это не противоречит принципу работы образа Гэтсби? Кроме того, большинство CMS обрабатывают преобразование изображений на сервере и размещаются в их собственной CDN. (И это хорошо, имо). Но если мы разместим его на нашем собственном сайте, разве это не будет контрпродуктивным?

Добавляя к тому, что сказал @Undistraction , Гэтсби быстр, но если он не быстрый, по мнению Google, это становится проблематичным. Тем более, что они включают это в обновление рейтинга страниц в следующем году.

@Jimmydalecleveland Я нашел способ работать с изображением Гэтсби внутри расширенного текста контента без этого взлома запроса! Вот в чем суть . Код был скопирован из gatsby-source-contentful . По сути, вы можете создавать наполненные жидким содержимым или фиксированные свойства вне GQL. Что идеально подходит для насыщенного текста.

Я также создал запрос на gatsby-source-contentful .

Что-то меня просто не устраивает. Я создал очень упрощенный веб-сайт с изображением на странице, я использую SVG для изображений без gatsby-image, я также попытался удалить аналитику Google, и это не имело большого значения, моя оценка была около 50-60 по производительности.

Что меня действительно озадачивает, так это то, что только домашняя страница (index.js) получает очень низкий балл, тогда как другие страницы, такие как страница служб или страница контактов, получают оценку ~ 80. Я построил этот сайт довольно последовательным образом, поэтому между страницами нет огромной разницы, и все же по какой-то причине главная страница имеет оценку ~ 50, а страницы служб - ~ 80.

Как я упоминал ранее, с Lighthouse v5 оценка была ~ 90, просто нет никакого смысла, что простой сайт, подобный этому, теперь будет иметь низкий рейтинг ~ 50.

Кстати, пробовал ли кто-нибудь из вас установить изображение в верхней части страницы как eager ?
Это отключает отложенную загрузку и может увеличить результат. Размытие или svg
эффекты загрузки могут сбивать с толку Lighthouse (что, если это так,
изъян в их алгоритме).

В сб, 13 июня 2020 г., 10:48 t2ca [email protected] написал:

Что-то меня просто не устраивает. Я создал очень простой веб-сайт
примерно с изображением на страницу, я использую SVG для изображений без gatsby-image,
Я также попытался удалить Google Analytics, и это не помогло
Разница, моя оценка была примерно 50 - 60 за исполнение.

Что меня действительно озадачивает, так это то, что только домашняя страница
(index.js) получает очень низкий балл, в то время как другие страницы, такие как
страница служб или страница контактов получает оценку ~ 80. Я построил это
сайт достаточно согласован, поэтому нет большой разницы между
страниц, но по какой-то причине главная страница имеет оценку ~ 50, в то время как
страницы сервисов имеют оценку ~ 80.

Как я уже упоминал ранее, в Lighthouse v5 оценка была ~ 90, это просто
нет никакого смысла в том, что у такого простого сайта, как этот, теперь будет низкий
оценка ~ 50.

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/gatsbyjs/gatsby/issues/24332#issuecomment-643648423 ,
или отписаться
https://github.com/notifications/unsubscribe-auth/AAARLB2Q2IVSNVKGGBZ3ZPDRWOUU5ANCNFSM4NHP7XCA
.

@KyleAMathews У нас есть, и это значительно повысило показатели производительности и первых красок. Это то, что я обозначил в пункте 2 моего длинного комментария выше. Отмена fadeIn - вот что наконец порадовало LH.

Изменить : я, вероятно, по незнанию, чувствую, что сосредоточение внимания на LCP не является правильным подходом к повсеместному отношению к изображениям. Очевидно, анекдотично, но я чувствую, что веб-сайт работает намного быстрее, когда весь контент загружен, а изображения блекнут в послесловиях, если только изображение не имеет решающего значения для контента.

Одним из распространенных примеров может быть статья на Medium. Конечно, вы могли бы сказать, что это недостаток дизайна, но большинство статей на Medium (и многих других блогов) начинаются с большого старого изображения вверху, которое предназначено только для создания настроения или декораций, и меня не волнует, загружается ли оно лениво. .

Кстати, пробовал ли кто-нибудь из вас установить изображение в верхней части страницы как eager ? Это отключает отложенную загрузку и может увеличить результат. Эффекты размытия или загрузки svg могут сбивать с толку Lighthouse (что, если это так, является недостатком в их алгоритме).
…

Сейчас попробую.

Думаю, здесь я добился неплохого прогресса. Я повысил свои оценки с 57 до 84 с очень простыми изменениями. Моя LCP увеличилась с 12 до 2 .

Тем не менее, это непоследовательно. После внесения изменений, которые я опишу ниже, моя оценка варьируется от 69 до 84. Очевидно, что есть некоторая случайная разница в оценках производительности.

TL; DR

Во-первых, как предложили @KyleAMathews и @Jimmydalecleveland , я попытался установить loading="eager" и fadeIn={false} на компоненты изображения Gatsby, которые были выше сгиба.

Затем я избавился от base64 из моих запросов.

Это имело огромное значение.

Добро

• Добавление _noBase64 к моим фрагментам изображения принесло мне 20 баллов!

  • Кажется, что изображения base64 добавляют большой вес на мобильных устройствах. Я запрашиваю изображения из содержимого, используя localFile -> childImageSharp -> fluid -> GatsbyImageSharpFluid_withWebp_noBase64 .

• loading="eager" и fadeIn={false} сократили время моей самой большой Contentful Paint примерно на 50%!

  • Моя реальная оценка производительности по какой-то причине поднялась только на 6-7 баллов, но LCP определенно прогрессирует ...

Мой запрос выглядит так:

localFile {
  childImageSharp {
      fluid(maxWidth: 800, quality: 100) {
        ...GatsbyImageSharpFluid_withWebp_noBase64
      }
   }
}

А мои gatsby-image выглядят так:

<Image 
  fluid={localFile.childImageSharp.fluid}
  fadeIn={false} 
  loading="eager"
/>

Менее хорошо

Мой UX на моем сайте теперь выглядит намного хуже. Переход на base64 + обеспечил отличный UX. Теперь это немного неспокойно. Я думаю, это компромисс, который мы должны сейчас рассмотреть?

До и после eager & fadeIn={false}

Вот несколько параллельных сравнений одних и тех же страниц. Единственное отличие состоит в том, что справа у изображений есть loading="eager" и fadeIn={false} .

1. Домашняя страница

LCP упала на 49%. Оценка производительности на 6 баллов.

2. Страница продукта

LCP снизился на 46%. Оценка производительности 7 баллов.

Что странного в приведенном выше примере: скриншоты слева имеют поведение gatsby-image по умолчанию (они исчезают, и на них нет eager ). И все же, хотя оценка производительности ниже , небольшие скриншоты внизу создают впечатление, что он загружается быстрее, чем изображение справа.

Может быть, это в пределах погрешности того, как они оценивают производительность, или, может быть, это ошибка с их стороны, связанная с эффектом затухания, как упоминал @KyleAMathews .

После установки _noBase64 во фрагментах изображения

Вот те же экраны, что и в примере выше. У всех есть реквизиты loading="eager" , fadeIn={false} на Gatsby Image. Также фрагменты изображения в graqhql: GatsbyImageSharpFluid_withWebp_noBase64

Это немного необъяснимо, но я снова и снова провожу тест Lighthouse на одной и той же странице и получил 84, 75 и 69.

Довольно странно, но в любом случае это повысило мою оценку.

Я думаю, что алгоритм Lighthouse был здесь необычайно щедрым, lol ^

После дальнейшего расследования я обнаружил, что Lighthouse жаловался на определенный элемент, который влиял на оценку LCP.

Все, что я сделал, это просто переместил этот элемент, который представляет собой всего лишь абзац, и моя оценка подскочила выше 80. Поймите. Не совсем уверен, почему перемещение абзаца увеличило мою оценку с ~ 50 до ~ 80.

@nandorojo Спасибо за подробное

После дальнейшего расследования я обнаружил, что Lighthouse жаловался на определенный элемент, который влиял на оценку LCP.

Все, что я сделал, это просто переместил этот элемент, который представляет собой всего лишь абзац, и моя оценка подскочила выше 80. Поймите. Не совсем уверен, почему перемещение абзаца увеличило мою оценку с ~ 50 до ~ 80.

@ t2ca Это то, что я получил (хотя у меня был тег заголовка). Но куда вы его переместили?

@ t2ca Это то, что я получил (хотя у меня был тег заголовка). Но куда вы его переместили?

@michaeljwright Первое, что я сделал, это удалил абзац и проверил счет маяка. После того, как я удалил абзац, моя оценка увеличилась примерно на 20 баллов. Я повторял тест много раз, чтобы убедиться. Я также вернул абзац и сделал дополнительные тесты, и моя боль снова уменьшилась.

Наконец, я решил просто переместить абзац, я использовал framer-motion внутри div, и я просто переместил абзац за пределы div. Это дает мне тот же результат, что и при удалении абзаца.

@ t2ca Я думаю, что LCP штрафует за любую анимацию на страницах наших героев, что является обломом.

Вот мои оценки LCP, где тег абзаца - это LCP

С анимацией:

Без анимации:

@ t2ca Я думаю, что LCP штрафует за любую анимацию на страницах наших героев, что является обломом.

Вот мои оценки LCP, где тег абзаца - это LCP

С анимацией:

Без анимации:

@ daydream05 Спасибо за подтверждение!

@ daydream05

Разве это не противоречит принципу работы образа Гэтсби? Кроме того, большинство CMS обрабатывают преобразование изображений на сервере и размещаются в их собственной CDN. (И это хорошо, имо). Но если мы разместим его на нашем собственном сайте, разве это не будет контрпродуктивным?

Нет, поскольку gatsby-image работает и с локальными образами, нет необходимости размещать его на другом CDN. Все сводится к оптимизации вашего первого рендера (того, что находится в области просмотра). Размещение его в другом домене / CDN означает, что вам нужно открыть новое соединение (разрешение DNS, рукопожатие tls, ...). Это может занять до 300 мсек на медленном устройстве, а затем вам все равно придется загрузить изображение.

Добавляя к тому, что сказал @Undistraction , Гэтсби быстр, но если он не быстрый, по мнению Google, это становится проблематичным. Тем более, что они включают это в обновление рейтинга страниц в следующем году.

Мы будем еще больше оптимизировать Gatsby, чтобы наши пользователи могли получить 100 баллов бесплатно.

@ t2ca Я думаю, что LCP штрафует за любую анимацию на страницах наших героев, что является обломом.

Это ожидаемо, потому что ваш экран никогда не перестает рисовать. Обычно LCP должен игнорировать анимацию CSS, но это зависит от того, как вы ее выполняете.

@ t2ca

Если вы можете показать нам сайт, мы поможем выяснить, как его улучшить, но, вероятно, это заставит изображение активировать.

@nandorojo

Замечательная запись! Есть ли шанс дать нам ссылки на отчеты о маяках?

Это ожидаемо, потому что ваш экран никогда не перестает рисовать ...

@wardpeet Не могли бы вы

@DannyHinshaw Я получил это объяснение от маяка
«Я думаю, что происходит то, что LCP действительно заботится о том, чтобы изображения были полностью загружены, и время, о котором сообщается, - это когда изображение полностью загружено, а не когда оно впервые отображается. Это время может быть другим из-за прогрессивных изображений и итеративных красок. "

И тогда эта ссылка, возможно, поможет
https://web.dev/lcp/#when -is-large-contentful-paint-reports

Тем временем вы также можете попробовать изменить самую крупную Contentful Paint (LCP) с изображения на текст (если у вас есть такая роскошь), предварительно загрузив / предварительно выбрав шрифты и ленивую загрузку изображений. В моем случае это означало уменьшение размера изображения героя на мобильном телефоне, что повысило наш рейтинг до более высоких 90, пока проблема обсуждается.

import semiBoldFont from 'static/fonts/SemiBold-Web.woff2';
...
<Helmet>
   <link rel="prefetch" href={semiBoldFont} as="font"></link>
</Helmet>

https://lighthouse-dot-webdotdevsite.appspot.com//lh/html?url=https%3A%2F%2Fwhatsmypayment.com%2F
https://developer.mozilla.org/en-US/docs/Web/HTML/Preloading_content

Это ожидаемо, потому что ваш экран никогда не перестает рисовать ...

@wardpeet Не могли бы вы

Конечно, я не знаю, какой это был сайт, я пытался найти URL-адреса в этой ветке, но это было сложно. LCP не учитывает CSS-анимацию (переходы, свойства анимации в css). Однако, если у вас есть контент, который использует setTimeout / setInterval, который переключает реагирующий компонент, он будет учитывать это. Последний подход даст вам очень плохие оценки CLS.

Итак, если вы хотите анимировать текст / изображение вашего героя. Пожалуйста, используйте анимацию css.

Всем привет,

Я попытался выяснить, почему мой проект так низко оценивается в Google Page Speed ​​Insights, аудита Google Lighthouse и многом другом.

Если не начинать с нуля, я не уверен, в чем проблема. Для начала я использовал эту стартовую тему / тему: https://github.com/alexislepresle/gatsby-shopify-theme

Я в основном и сейчас нахожусь в процессе изменения таких вещей, как переход от bulma к chakra-ui.

Это мое репо: https://github.com/Chizzah/genesis-style
Я попытался удалить все данные об учетной записи и gatsby-plugin-appollo-shopify, но это ничего не меняет.

Вот живая ссылка: https://genesis-style.netlify.app

Кажется, ничто из того, что я делаю, не меняет. Я бы предпочел не начинать с нуля. Если кто-нибудь может дать мне подсказку, я буду признателен.

Думаю, я слишком привык к Гэтсби, раздающему бесплатные 90-100

Спасибо за эту ветку, поскольку необходимо обсуждение достижения хороших оценок Lighthouse. С v6 стало труднее получать отличные оценки, в основном из-за новой метрики LCP. Мой сайт (https://www.jamify.org) упал с ~ 100 до ~ 70 с Lighthouse v6.

Чтобы вернуть 100 на рабочем столе, мне пришлось

• удалить ненужное фоновое изображение (так как оно было ошибочно выбрано в качестве LCP)
• оптимизировать размер изображений
• установить gatsby-image в loading="eager" и fadeIn=false
  (это действительно облом, потому что мне нравится эффект размытия)

На мобильном телефоне я все еще застреваю на 80, опять же из-за 5 секунд LCP. Это можно улучшить, правильно изменив размер изображений специально для мобильных устройств:

В целом, эти оптимизации вполне осуществимы, однако я очень недоволен тем, что теперь мне приходится выбирать между ленивой загрузкой изображений с размытием или хорошей оценкой Lighhouse: roll_eyes:

Кто-нибудь делал еще какие-нибудь тесты на lighthouse v6.1? Я заметил улучшение своей успеваемости.

Спросил Адди из Google о проблеме размытия LCP, и они работают над ее исправлением https://twitter.com/addyosmani/status/1277293541878673411

Урок здесь в том, что пока не относитесь к новым показателям производительности как к абсолютным - они все еще совершенствуют крайние случаи.

Я считаю, что с Lighthouse 6.1 проблема усугубляется. Здесь есть несколько хороших предложений, касающихся LCP, но мы не уделяем так много внимания TBT, который, я думаю, является самой большой причиной плохих результатов на мобильных устройствах и является наиболее сложной для решения.

Вы можете протестировать Lighthouse 6.1 в Chrome Canary. Я сравнил свой сайт между 6.0 и 6.1, а также несколько других, упомянутых здесь, и TBT резко увеличился. Например, в моих тестах 6.1:

• gatsbyjs.org TBT: 2550 мс
• мой сайт TBT: 2200 мс
• TBT сайта : 1250 мс

Все, что превышает 600 для TBT, является красным, а вес согласно калькулятору составляет 25%, что является основным фактором. TBT вызывается функциями, выполнение которых между FCP и Time to Interactive занимает более 50 мс.

На приведенном выше снимке экрана показан профиль с моего сайта. Если вы используете Lighthouse в Chrome, вы можете нажать кнопку «Просмотреть трассировку», чтобы загрузить результаты на вкладку профиля и увидеть то же самое. Любое задание после FCP с красным флажком в углу засчитывается в TBT. Мне еще предстоит вникнуть в суть задач, так что, возможно, кто-нибудь с большим знанием Гэтсби может помочь в этой области, и, возможно, @wardpeet поделится своим

@IanLunn , это интересный след, вы смогли понять, что за задачи скрывались?

Вероятно, существует корреляция между количеством JS на каждом сайте Gatsby и тем, насколько дорого он становится в основном потоке браузера. Однако я думаю, что может быть открыта возможность для обсуждения, может ли Гэтсби помочь «смягчить» влияние тем, как он загружает запросы и скрипты в целом?

На данный момент я пытаюсь лучше понять три области:

• Гэтсби по умолчанию добавляет <link rel=preload/> для каждого необходимого скрипта (в соответствии с шаблоном PRPL ) независимо от того, сколько их существует. Я заметил некоторые различия в измеренных FCP (что меня очень удивило), но в основном это разрыв между FCP / LCP при их удалении (что, вероятно, не является хорошей идеей без других изменений). В этом выпуске о маяке обсуждается последний.
• В итоге запросы создают файлы JSON (page-data.json и хешированные для статических запросов), которые оцениваются в основном потоке. См. Https://github.com/gatsbyjs/gatsby/issues/18787, но похоже, что мы не нашли (или если есть) альтернативу, которая не блокирует основной поток. Чем больше данные, тем больше падает производительность (поэтому бюджеты производительности для размеров запросов , безусловно, были бы очень кстати), но данные действительно не нужны до процесса регидратации, или нет?
• Фактические фрагменты добавляются как <script src=foo.js async /> в конец </body> . Это означает, что как только браузер закончит синтаксический анализ HTML (который должен вскоре появиться в трассировке), он начнет синтаксический анализ и выполнение этих сценариев (поскольку они уже были предварительно загружены). Неизбежно возникнут длинные задачи, поскольку основной поток запрашивается для анализа и выполнения всего этого javascript. Есть ли лучший способ справиться с этим (по крайней мере, _ когда_ эти сценарии начинают анализироваться), чтобы избежать блокировки основного потока? Есть ли способ сделать это (синтаксический анализ или выполнение) в небольших инкрементных задачах, которые не задерживают обратную связь по входу (и, таким образом, не наносят вред TTI), ни блокируют основной поток по частям (и, таким образом, вредят TBT)?

Хотя на данный момент это правда, что сайты Гэтсби немного наказываются из-за того, что LCP еще не распознает шаблон LQIP из gatsby-image - когда дело доходит до всего, что связано с TBT / TTI (и, возможно, серьезным штрафом за стоимость Javascript по сравнению с Lighthouse v5) Я не думаю, что в дорожной карте команды Lighthouse есть что-то, что улучшило бы текущие результаты.

@juanferreras Самая большая задача - это domready / ready.js (сторонний). Мне кажется, ваше утверждение о том, что Lighthouse наказывает JavaScript, является правильным, и хотя в Gatsby возможны небольшие оптимизации, это не то, что можно решить.

Если в Lighthouse все будет именно так, я склонен хотя бы попросить их уменьшить вес TBT или дать возможность установить желаемую среду тестирования. Оценка на основе бюджетного телефона не всегда подходит для тестируемого сайта. Мы должны иметь возможность показать начальникам / клиентам, что да, бюджетный телефон получает 75 баллов, а более дорогой телефон, который есть у 95% наших пользователей, например, получает 90 баллов.

• В итоге запросы создают файлы JSON (page-data.json и хешированные для статических запросов), которые оцениваются в основном потоке. См. # 18787, но похоже, что мы не нашли (или если есть) альтернативу, которая не блокирует основной поток. Чем больше данные, тем больше падает производительность (поэтому бюджеты производительности для размеров запросов , безусловно, были бы очень кстати), но данные действительно не нужны до процесса регидратации, или нет?

@juanferreras , в связи с этой проблемой анализа данных json в основном потоке на ум приходит веб-воркер. Гэтсби может зарегистрировать веб-воркера, если он доступен на клиенте, и буферизовать ему подобные вещи, процесс регидратации на самом деле не нужен немедленно, поэтому я считаю, что это выполнимо

Web worker поддерживается в основных браузерах, включая IE10.

… Мы не уделяем так много внимания TBT, что, по моему мнению, является самой большой причиной плохих результатов на мобильных устройствах и которую труднее всего решить.

Я хочу добавить кое-что, что, по моему мнению, имеет отношение к общему времени блокировки. Изучив свои пакеты с анализатором пакетов Webpack, я заметил, что данные из статических запросов включены в пакеты JavaScript. Я уверен, что для этого есть веская причина, но это работает против низкого TBT.

TBT - сложная проблема, особенно потому, что React не создан для этого. Переход к preact - хороший первый шаг. В ближайшие месяцы мы будем все больше и больше улучшать TBT, мы хотим, чтобы Gatsby занимал очень мало места.

В версии gatsby> 2.24.0 мы добавили улучшенную поддержку полифиллов, поэтому мы загружаем полифилы только в устаревшие браузеры, такие как IE11. Мы также удалили статические запросы из webpack несколько дней назад (@MarkosKon).

@Teclone, к сожалению, веб-воркеры не подходят для синтаксического анализа JSON. Вы по-прежнему платите цену за сериализацию и десериализацию между потоками. С ShardArrayBuffer все было бы по-другому, к сожалению, они отключены по умолчанию из-за Meltdown / specter

Я просто отлично получал 100/100 на всем на встроенном Lighthouse (6.0) в Chrome, а затем использовал версию web.dev (6.1), и она вернулась с производительностью в 70-х годах из-за LCP (около 5-6 секунд в 6.1, примерно 0,5 секунды в 6.0). Это декоративное изображение заголовка (с использованием gatsby-background-image), на которое он жалуется.

Глядя на мой собственный веб-сайт, среда выполнения Webpack имеет наибольшее время выполнения javascript. То, что странице даже не нужно, пока пользователь не начнет взаимодействовать со страницей.

Кажется, что Гэтсби просто загружает все эти ресурсы (фрагменты) сразу. Сам файл js очень маленький, это загрузчик, вы можете видеть, что для передачи файла требуется всего 2 мс. Но сам файл загружает фрагменты и файлы шаблонов.

Фактически, когда я проверяю файлы фрагментов, я обнаруживаю, что все они являются динамическими импортами, которые, мы надеемся, загружаются только тогда, когда они необходимы, но нет, все они загружаются по умолчанию. Я не ожидал такого поведения.

Немного оптимизировали наше изображение заголовка, например, использовали изображение напрямую, а не Gatsby-Image, и уменьшили разрешение и сжатие, и наше изображение намного лучше. Только я только что на собственном опыте обнаружил, что Safari не поддерживает WebP (grr). И по-прежнему веб-версия Lighthouse намного менее снисходительна, чем встроенная в Chrome, по крайней мере, для нашего «скрытого» сайта разработки. Время покажет, помогут ли агрегированные пользовательские данные, когда они появятся вживую - я не уверен, что многие используют Moto G5 в реальном мире!

@derykmarl Скоро появится поддержка: https://www.macrumors.com/2020/06/22/webp-safari-14/
Я не понимаю, почему Apple потратила столько времени на поддержку широко распространенного формата изображений ...

Я читал, что pagespeedinsight имитирует подсчет очков. Похоже, они не ограничивают сеть, чтобы вы могли быстрее получить отчет. Я лично использую https://lighthouse-metrics.com/, но они пока не поддерживают 6.1.

Проблема с lighthouse 6.x заключается в том, что он зависит от времени восприятия, вы можете запустить один и тот же тест 10 раз, и вы не получите одинаковых результатов в зависимости от условий сети.

он вернулся с производительностью в 70-х благодаря LCP

У меня был LCP, который был фоновым изображением для моего веб-сайта, я смог резко сократить LCP, разделив изображение на 6 дополнительных изображений. Я сделал скрипт Python, чтобы сделать это легко, если вы знаете высоту, на которой вы хотите, чтобы каждый из ваших сегментов был

from PIL import Image
import os
import ntpath

def crop(pathToFile, height, width=False):
    im = Image.open(pathToFile)
    imgwidth, imgheight = im.size
    [name, ext] = ntpath.basename(pathToFile).split('.')

    if(not width):
        width = imgwidth

    k=1
    for i in range(0,imgheight,height):
        for j in range(0,imgwidth,width):
            box = (j, i, j+width, i+height)
            a = im.crop(box)
            a.save(os.path.join("./" + name + "-" + str(k) + "." + ext), compress_level=9, optimize=True)
            k +=1

pathToFile = '/path/to/your/img.jpg'
crop(pathToFile, 933)

Я также обнаружил, что этот веб-сайт сжатия изображений действительно хорошо работает для уменьшения размера вашего изображения без слишком большой потери качества. Обычно я мог опуститься до отметки качества 20% -30% и резко сократить размер файла.

Я задал несколько вопросов об этом в Интернете, и некоторые люди рекомендуют мне разделить изображение только на 2, для верхней и нижней части, но я обнаружил, что разделение на 6 работает намного лучше.

@wardpeet в примечании TBT / TTI, мы можем увидеть, как другие сайты, основанные на реакции, теперь смягчают общее влияние на основной поток браузера.

Сам responsejs.org (который, насколько мне известно, также построен с использованием Gatsby), кажется, имеет значительно меньший TTI (7-8 ~ против 12 ~), чем новый gatsbyjs.com (кстати, поздравляем с запуском!). NextJS также поддерживает очень хорошие показатели по TTI / TBT, несмотря на то, что они сами основаны на React (это также может быть связано с относительным размером скриптов - где gatsby.com имеет около 628,3 КБ скриптов согласно PSI, reatjs.org 466,1 КБ , а nextjs.org всего 216,8 КБ)

(очевидно, что это один прогон, и его не следует использовать в качестве фактического сравнения, но тенденция довольно последовательна для нескольких прогонов).

Является ли большая часть разницы в баллах общей стоимостью Javascript ™? Если команда Гэтсби оптимизирует новый веб-сайт в какой-то момент, это может быть прекрасной возможностью поделиться некоторыми взглядами на процесс, при условии, что не останется много волшебства, чтобы добавить к тому, как фреймворк Гэтсби уже обрабатывает javascript внутри.

@juanferreras @wardpeet , Есть кое-что, что я узнал на собственном проекте. Если вы используете стилизованные компоненты, по некоторым причинам стили пересчитываются / регенерируются во время гидратации и повторно вводятся в браузер. Это занимает много основного потока.

Это связано с проблемами гидратации у гэтсби. https://github.com/styled-components/styled-components/issues/2171

Гэтсби также работает над запуском ssr во время разработки, https://github.com/gatsbyjs/gatsby/issues/25729 , это поможет выявить такого рода проблемы с производительностью. тоже.

@teclone

https://github.com/styled-components/styled-components/issues/2171 , похоже, не предлагает решения. Как вы исправили это в своем проекте?

@dfguo , на данный момент для этого нет исправления, потому что никто точно не знает, почему стили регенерируются во время регидратации, потому что gatsby в производстве не предлагает помощь в разработке с ошибками регидратации.

То есть нет консольного журнала из React, указывающего на различия во время регидратации, потому что он отключен в производственной сборке gatsby.

Цель этой незавершенной работы № 25729 - запустить настоящий SSR в процессе разработки, поэтому мы сможем понять, почему. включая команду Гэтсби.

Кстати, вы можете создать сайт Gatsby с gatsby build --no-uglify чтобы создать свой сайт с разрабатываемой версией React для просмотра журналов. https://www.gatsbyjs.com/docs/gatsby-cli/#build

Dev SSR будет очень полезен в будущем для подобных вещей!

Итак, я решил перенести свой сайт с @emotion и theme-ui на linaria при реализации режима dark-light с пользовательскими переменными css.

Целью было уменьшить время блокировки / основной поток / все, что связано с js, поскольку теперь css больше не оцениваются во время выполнения, а компилируются во время сборки (на самом деле linaria кажется гораздо более согласованным с gatsby чем @emotion в этом отношении)

Процесс не совсем гладкий, большинство вещей, которые я сделал с @emotion просто работают с linaria , но некоторые другие нет, и вам нужно переписать их и / или повторно реализовать их через пользовательский CSS переменные

Опыт DX с gatsby - __bad__, горячая перезагрузка не работает (вам нужно останавливаться и начинать заново при любом изменении, так как браузер, кажется, теряет соединение), но в целом процесс был приятным, так как заставляет вас более внимательно относиться к тому, что вам действительно нужны возможности выполнения

__Тем не менее, показатели маяков очень похожи __

Я могу сравнить два развертывания netlify, и на самом деле у сайта @emotion высокие 70, а у сайта linaria низкие-средние 70

Излишне говорить, что я не очень взволнован

Анализируем комплект:

• документ сайта увеличен с 14 Кб до 28 Кб
• скрипт фреймворка остался идентичным на уровне 38,7 кб
• Скрипт приложения уменьшился с 58,2 кб до 46,1 кб.
• А четвертый сценарий ( component--content.. . Тогда, 20bae078.. сейчас) увеличился с 44,2 КБ до 46,8 КБ.

Итак, я предполагаю, что стили в js переместились в стили в css (и ~ 12 КБ являются значительными IMO), но это не оказало никакого реального влияния на показатели Lighthouse (и это то, что важно, не так ли?)

Итак, я вовсе не говорю, что переход на linaria не имеет смысла, я не удивлюсь, если кто-то сделает то же самое и получит лучшие результаты (теоретически это должно быть так (?)), но в моих руках процесс не стоил

Тем не менее, исследуя сценарий приложения, я открыл новую проблему, пытаясь выяснить, как уменьшить пакет js https://github.com/gatsbyjs/gatsby/issues/26655

Опыт DX с Gatsby плохой , горячая перезагрузка не работает (вам нужно останавливаться и начинать заново при любом изменении, так как браузер, кажется, теряет соединение), но в целом процесс был приятным, так как вынуждает вас более внимательно относиться к тому, что вам действительно нужны возможности выполнения

@kuworking Я столкнулся с подобной проблемой, но заметил, что это происходит только в версиях gatsby новее, чем 2.24.9 ; Не уверен, что причина та же, но я подумал, что кому-то может быть полезно узнать, что

@kuworking Я столкнулся с подобной проблемой, но заметил, что это происходит только в версиях gatsby новее, чем 2.24.9 ; Не уверен, что причина та же, но я подумал, что кому-то может быть полезно узнать, что

Я был бы с "gatsby": "2.24.14" течение нескольких недель, я бы сказал, и пока я испытал это только с linaria
Но зная это, я не буду обновлять Гэтсби, пока это не выяснится, спасибо 👍

@kuworking Я хотел 2.24.9 то проблема с остановкой сервера разработки не возникнет даже с linaria ; но это всего лишь идея. Мне было бы любопытно узнать, так ли это.

Опыт DX с Gatsby плохой , горячая перезагрузка не работает (вам нужно останавливаться и начинать заново при любом изменении, так как браузер, кажется, теряет соединение), но в целом процесс был приятным, так как вынуждает вас более внимательно относиться к тому, что вам действительно нужны возможности выполнения

Вы пробовали быстрое обновление ?

Недавно я перенес производственный сайт gatsby (~ 120 страниц) на предварительную версию в надежде улучшить TBT и LCP. Наш сайт сильно загружен svg и использует компоненты response svg, созданные с помощью svgr и оформленные с использованием стилей material-ui. Средние результаты производительности находились в диапазоне + -5 от начального балла (~ 45 производительность мобильных устройств по сравнению с ~ 85 до v6), и хотя переход с использованием темы был относительно безболезненным, он действительно потребовал перехода на быстрое обновление, которое было не.

Честно говоря, немного разочарован тем, что нет никаких других оптимизаций, которые я могу найти, чтобы попробовать, или более подробных метрик, кроме общего предупреждения маяка «Удалить неиспользуемый javascript».

Скорость - одна из основных причин, по которой мы выбрали Гэтсби, и даже несмотря на то, что страницы по-прежнему быстро загружаются, трудно оправдать с точки зрения SEO, когда ваши оценки получают такой большой удар ...

шепчет: Я перешел на NextJS и набираю больше очков 🤭

шепчет: Я перешел на NextJS и набираю больше очков 🤭

А что насчет Svelte?

Было бы хорошо узнать, придают ли разработчики Gatsby определенное ощущение важности / приоритета в дорожной карте (кроме ожидаемого), поскольку я предполагаю, что нет немедленных решений, но, возможно, какие-то будущие направления и реализации, ориентированные на это или то

Поскольку gatsby выполняет некоторую компиляцию с помощью gatsby-node *, мне интересно, изучают ли они способы увеличения этой части и удаления клиентской части.

* Чтобы уменьшить используемое мной pageContext (данные обо всех опубликованных сообщениях), в настоящее время я сохраняю (через gatsby-node ) большую часть этих данных в файлах json и получать их при необходимости с сайта, что уменьшает размер пакета, но также кажется более логичным

Не зацикливайтесь на счетах маяка, особенно когда они
используется в качестве ориентира по сравнению с другими сайтами, а не целью, в которой мы должны
стремиться достичь наивысшего балла.

Лишь недавно Гэтсби набирал чистые сотни - конечно, там
есть некоторые проблемы, которые нужно решить, но сейчас SEO-игра - это скорость плюс контент
плюс ссылки, и у нас это есть.

Мои два цента.

Пт, 28 авг.2020, 16:57 kuworking, [email protected] пишет:

шепчет: Я перешел на NextJS и набираю больше очков 🤭

А что насчет Svelte?

Было бы неплохо узнать, дают ли разработчики Gatsby некоторые конкретные
чувство важности / приоритета в дорожной карте (кроме ожидаемого
one), поскольку я предполагаю, что немедленных решений нет, но, возможно, некоторые
вид будущих направлений и реализаций, ориентированных на то или иное

Поскольку gatsby выполняет некоторую компиляцию с помощью gatsby-node *, мне интересно,
исследуют способы увеличить эту часть и удалить клиентскую часть

* Чтобы уменьшить pageContext, который я использовал (данные обо всех
опубликованные сообщения), в настоящее время я храню (через gatsby-node) большую часть
этих данных в файлах json и при необходимости получить их с сайта,
что уменьшает размер пакета, но также кажется более логичным

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/gatsbyjs/gatsby/issues/24332#issuecomment-682664232 ,
или отписаться
https://github.com/notifications/unsubscribe-auth/ALSIKRHQUIKR5YO6OGA3DC3SC7AWPANCNFSM4NHP7XCA
.

Приносим извинения за поздний ответ, но производительность очень важна, а показатели нагрузки - лишь небольшая часть головоломки. В этом и следующем квартале мы заинтересованы в том, чтобы уменьшить размер Гэтсби и снизить TBT. На данный момент самые большие проблемы - это размер пакета React, многомерные выражения, большие страницы (контент / стиль), скрипты отслеживания и шрифты / изображения в качестве основного контента при первой загрузке.

В настоящее время я изучаю сценарии gatsby-image и аналитики, чтобы увидеть, как мы можем сократить время загрузки и отложить аналитику.

К сожалению, я не могу дать никаких оценок. Мы также изучаем наш сайт .com и наших клиентов, чтобы узнать, каковы общие проблемы, чтобы мы могли встроить эти оптимизации в gatsby или в наши плагины.

Редактировать:

Я счастлив взглянуть на любой из ваших исходных кодов, чтобы получить больше информации о том, что вы все делаете, и увидеть, как мы можем улучшить.

Я сделал сообщение на Reddit, в котором попытался собрать все советы по улучшению, которые смог найти. Если вы можете придумать больше советов, перечислите их

Удаление только изображения gatsby (

В некоторых недавних тестах, которые я проводил, я обнаружил, что использование tracedSVG самом деле значительно улучшило оценку производительности Largest Contentful Paint. Я предполагаю, что это будет исправлено в Lighthouse, но на данный момент это происходит потому, что SVG считается теми же размерами, что и изображение с полным разрешением, поэтому он никогда не переключается с SVG в качестве цели LCP на полное изображение.

При использовании base64 небольшое разрешение делает его не кандидатом для LCP, поэтому Lighthouse использует изображение с полным разрешением всякий раз, когда оно загружается.

Так что, если вы не возражаете против того, как выглядят отслеженные SVG (я предпочитаю их лично), вы можете попробовать.

Почему v5 лучше, чем v6? Я использую NextJS, результат всегда менялся с 60 на 85.

+1

Я работал над преемником образа Гэтсби. Это еще не на 100%, все еще нужно написать составную версию, чтобы вы могли создать свой собственный вкус изображения Гэтсби, но он исправит большинство плохих оценок маяка.

Вы уже можете использовать его, но он еще не прошел боевые испытания.
https://github.com/wardpeet/gatsby-image-nextgen/tree/main/gatsby-image

Вы можете установить его с помощью npm install --save @wardpeet/gatsby-image-nextgen . Для текущих пользователей gatsby-image есть

То, что еще не поддерживается:

• объектная подгонка должна выполняться css вне компонента
• арт-директор

Текущая демонстрация gatsby-image:
сайт: https://wardpeet-using-gatsby-image.netlify.app/
pagespeed-insights: https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwardpeet-using-gatsby-image.netlify.app%2F
webpagetest: https://webpagetest.org/result/200928_4M_0879160e38bb6c5489f85534de2dd197/

Новая демонстрация gatsby-image-nextgen:
сайт: https://gatsby-image-nextgen.netlify.app/
pagespeed-insights: https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fgatsby-image-nextgen.netlify.app%2F
webpagetest: https://webpagetest.org/result/200928_C0_63317160bdfc71ece1a2057df8b08133/

@wardpeet Ваша ссылка pagespeed-insights для текущей демонстрации переходит к следующему поколению, поэтому они показывают те же оценки.
Замечательная работа, кстати. Действительно интересно видеть прогресс.

Спасибо, исправили!

Это обновление показало мне кое-что, чего я раньше не подключал, я не использую gatsby-image но на самом деле gatsby-background-image который, по-видимому, не использует gatsby-image под капотом ... Мне, возможно, придется переписать этот компонент с новым @wardpeet/gatsby-image-nextgen если это возможно ....

В этой статье перечислены некоторые дополнительные советы https://www.freecodecamp.org/news/gatsby-perfect-lighthouse-score/, хотя я думаю, что многие из них уже упоминались в этой теме ...

@DannyHinshaw, когда плагин будет

Я опубликовал новую версию @wardpeet/gatsby-image-nextgen - 0.0.2.

1. минимизирует css и js в html
2. загружать только необходимые биты, когда включена загрузка собственных изображений, мы загружаем только около 2 КБ (без сжатия).
3. убедитесь, что заполнитель вызывается только при первой загрузке, кешированные изображения загружаются немедленно
4. Исправить размытие анимации путем асинхронного декодирования

Мне интересно, скольким из вас нужен составной компонент изображения, в котором вы можете создать свою собственную оболочку, и сколько из вас на самом деле используют художественное направление и хотят, чтобы это было внутри изображения gatsby по умолчанию? Моя первая идея заключалась в том, чтобы отключить эту функциональность, но включить ее с помощью составного gatsby-image, чтобы вам пришлось создать свой собственный компонент изображения для его поддержки.

Последняя демонстрация: https://gatsby-image-nextgen.netlify.app/

@wardpeet Это здорово! Я сильно полагаюсь на встроенное художественное руководство gatsby-image. Но я думаю, что пример / плавный путь обновления тоже подойдет!

Я всегда получал 99 на мобильном телефоне, теперь 76. Все отлично, кроме моего LCP, он 7.0s и говорит, что это мой образ героя. Без разницы. Когда я открываю свой сайт на любом мобильном телефоне, он молниеносно. Люди удивляются, я знаю? Он также говорит мне помещать свои изображения в webp или другие, но я уже использовал childImageSharp_withWebp, поэтому я его не понимаю. Я начинаю понимать, что Gastby Image и background-image не работают с этой новой версией в lighthouse и pagespeedinsight. Мой ум ошеломлен. Я убил анимацию, уменьшил размер всех изображений вдвое, и это не сдвинулось с места ни на одну точку. Я читаю это и не вижу ничего, что могло бы мне помочь .... О, я просто посмотрел вверх ... Я думаю, @wardpeet, я на что-то наткнулся 👍🏻

@davidpaulsson не могли бы поделиться примером того, как вы это делаете? Поскольку художественное оформление по-прежнему возможно с новым изображением gatsby, вам нужно выполнить некоторые действия вручную.

@davidpaulsson не могли бы поделиться примером того, как вы это делаете? Поскольку художественное оформление по-прежнему возможно с новым изображением gatsby, вам нужно выполнить некоторые действия вручную.

Конечно! Я использую это сейчас

const artDirection = [
  medium.childImageSharp.fluid,
  {
    ...large.childImageSharp.fluid,
    media: `(min-width: 1390px)`,
  },
];

return <Img fluid={artDirection} />

@wardpeet Привет, Вард. Может ли blurha.sh быть полезным для следующего поколения изображений Gatsby?

@wardpeet Я использовал ваш плагин gatsby-image-nextgen, и он действительно улучшил мое время LCP (уменьшил его с ~ 5 с до ~ 1,5 с). Спасибо тебе за это!

Однако мы также используем художественное направление, подобно тому, как его использует

Не могли бы вы подробнее рассказать о ручных шагах, необходимых для того, чтобы сделать это возможным с помощью плагина nextgen? Еще раз спасибо!

@Jimmydalecleveland Спасибо, Джимми! Замена GatsbyImageSharpFluid_withWebp на GatsbyImageSharpFluid_withWebp_tracedSVG резко улучшила показатели производительности моего нового Gatsby Webiste. Я получал не более 54%, а теперь с tracedSVG я получаю более 80%. Это огромное улучшение 💯

В некоторых недавних тестах, которые я проводил, я обнаружил, что использование tracedSVG самом деле значительно улучшило оценку производительности Крупнейшей Contentful Paint. Я предполагаю, что это будет исправлено в Lighthouse, но на данный момент это происходит потому, что SVG считается теми же размерами, что и изображение с полным разрешением, поэтому он никогда не переключается с SVG в качестве цели LCP на полное изображение.

При использовании base64 небольшое разрешение делает его не кандидатом для LCP, поэтому Lighthouse использует изображение с полным разрешением всякий раз, когда оно загружается.

Так что, если вы не возражаете против того, как выглядят отслеженные SVG (я предпочитаю их лично), вы можете попробовать.

@abdullahe Мы уже проверяли это раньше, и он зависит от холста, а узел-холст не очень надежен. По крайней мере, этого не было в прошлом. Я дам вам знать, если мы еще раз рассмотрим это :)

@guydumais не забудьте поставить loading="eager" это также должно изменить ваш счет.

@BenjaminSnoha и @davidpaulsson Я

@wardpeet, как использовать @wardpeet/gatsby-image-nextgen с gatsby-remark-images ? Это случай простого указания на него как на плагин в gatsby-config.js , или это невозможно до тех пор, пока он не будет объединен с монорепозиторием gatsby?

хотя это может не иметь ничего общего с lighthouse, мне интересно, почему файлы JSON данных страницы gatsby не поддерживают хеширование содержимого, как и файлы js.

Я знаю, что хеширование содержимого для файлов js выполняется Webpack, но gatsby также может делать то же самое для файлов JSON данных страницы. это может сэкономить много сетевых запросов cdn

Файлы @teclone page-data.json не должны загружаться снова и снова, если ваше кеширование настроено правильно. Они загружаются один раз, а затем браузер повторно проверяет их. Проблема с хешированием содержимого для данных страницы (по сравнению с файлами JS / CSS) просто в том, что их очень много. При хешировании содержимого, прежде чем вы сможете загрузить файл, вам необходимо загрузить манифест, который преобразует x в x.LONG_HASH поскольку хеш-код непредсказуем. С JS / CSS загрузка манифеста является разумной, так как файлов JS очень мало даже на очень больших сайтах. Но с данными страницы по одному на страницу, поэтому манифест может стать довольно большим. Раньше мы это делали и обнаружили на сайте размером 10 тыс. Страниц манифест уже был сжат на ~ 500 тыс. https://github.com/gatsbyjs/gatsby/pull/13004

Если вы видите, что файлы page-data.json загружаются снова и снова - проверьте, не отключили ли вы кеширование в своих инструментах разработки, и проверьте заголовки кеширования с помощью https://www.npmjs.com/package/check-gatsby-caching

@KyleAMathews , спасибо за разъяснения. Это очень разумный подход

@wardpeet правда ли, что image-nextgen не поддерживает fadeIn="false" или fadeIn="{false}"

Однако он работает намного лучше, с ~ 80 до ~ 95

@MelleNi нет, я не думаю, что это необходимо, но мы рады это рассмотреть.

вы можете взглянуть на https://github.com/gatsbyjs/gatsby/discussions/27950, чтобы узнать, что мы отправляем.

@wardpeet, как использовать @wardpeet/gatsby-image-nextgen с gatsby-remark-images ? Это случай простого указания на него как на плагин в gatsby-config.js , или это невозможно до тех пор, пока он не будет объединен с монорепозиторием gatsby?

Мы собираемся перенести и реплику в этот плагин :)

@MelleNi нет, я не думаю, что это необходимо, но мы рады это рассмотреть.

Вы можете посмотреть номер # 27950, чтобы узнать, что мы отправляем.

@wardpeet, как использовать @wardpeet/gatsby-image-nextgen с gatsby-remark-images ? Это случай простого указания на него как на плагин в gatsby-config.js , или это невозможно до тех пор, пока он не будет объединен с монорепозиторием gatsby?

Мы собираемся перенести и реплику в этот плагин :)

Приятно слышать это замечание, так как я заметил значительное улучшение скорости.

Однако я заметил, что не могу получить 99-100 без отключения javascript Гэтсби (и повторной интеграции определенных функций вручную). Я могу заставить старый образ Гэтсби работать без javascript, используя fadeIn={false} , но не image-nextgen. (Может, мне чего-то не хватает, и это абсолютно возможно?) Теперь без javascript я никогда не опускаюсь ниже 99 без nextgen.

Я понимаю, что отключение javascript разрушает идею Гэтсби, ну да ладно.

Интересно, что я заметил улучшение мобильной производительности (от ~ 70 до ~ 90), когда перестал использовать автономные шрифты (fontsource) и переключился на "системные" шрифты.

@wardpeet Есть ли шанс, что вы можете поделиться примером того, как создать составной компонент изображения с художественным руководством? Я нахожусь в одной лодке с @BenjaminSnoha и @davidpaulsson , и я не против создания компонуемого компонента в моем собственном проекте.

Самая большая проблема, которую я вижу, - это медиа-запросы и SSR. Такие библиотеки, как Френель, работают, но страдают от производительности, потому что они загружают все компоненты, а затем очищают DOM после того, как компонент window становится доступным.

На моем веб-сайте кажется, что все страницы, созданные с помощью createPage, имеют исходный код (компоненты реакции уценки и уценки внутри уценки) в тяжелом javascript для страниц (удалите неиспользуемый JavaScript)

Я только что запустил Plaiceholder, который можно использовать для создания размытых заполнителей на чистом CSS . Возможно, это будет интересно? Более чем счастлив поговорить с любой из основной команды о вариантах форварда

Я сделал версию Jamify Blog Starter для Next.js, которая хорошо работает с последней версией Lighthouse 6.4.0:

Вы можете ознакомиться с демонстрационным сайтом по адресу next.jamify.org .

Я публикую это здесь, а НЕ для того, чтобы предложить вам перейти на Next.js. Скорее, чтобы узнать, как того же можно достичь с помощью Гэтсби. Я считаю, что ключевыми факторами успеха являются:

• высокооптимизированные изображения (Next достигает этого с помощью оптимизатора лямбда, но это также можно сделать с помощью gatsby-plugin-sharp).
• простой заполнитель svg (приятные эффекты, такие как размытие, замедляют страницу).
• использование наблюдателя пересечения, чтобы показывать изображения только тогда, когда они находятся в поле зрения (см. следующий / изображения).
• обеспечить ленивую загрузку изображений.
• небольшой размер пачки.

Если вы хотите обсудить это дальше, вы можете связаться со мной в твиттере .

@styxlab Я получаю немного меньшие результаты в web.dev/measure

но лучше по результатам публикации, определенно очень хорошие значения в любом случае и заметно отличается от версии gatsby https://demo.jamify.org/

Я также опубликую, что на одном сайте я изменил gatsby на 11ty , и производительность улучшилась, но не значительно

(Гэтсби)

(другой дизайн, по сути тот же контент, 11ты)

Или на аналогичной странице, на этот раз с изображением

(Гэтсби)

(другой дизайн, по сути тот же контент, 11ты)

Я скажу, что опыт разработчика 11ty очень приятный (вы также можете экспериментально использовать jsx и styled-components ), но все js на стороне клиента теряются (вы можете вставить его и сражаться с веб-пакетом, именно в этот момент вы пропустите Гэтсби)

Пока я использовал 11ty, я также думал, как было бы хорошо, если бы gatsby включил какую-то стратегию рендеринга 11ty, чтобы можно было развертывать смешанные и нереагирующие статические страницы в одной структуре ...

какие-нибудь обновления по этому поводу? У меня нет изображений, и я получаю 76 по производительности из-за общего времени блокировки