Почему моя самая большая содержательная краска намного больше, чем время загрузки моей страницы?

Я оптимизирую сайт WordPress для скорости страницы. Для этого я использую Google PageSpeed ​​Insights, чтобы найти свои слабые места. Речь идет о веб-сайте goedkopewebsitezzp.nl.

Несколько мер, которые я предпринял:

  • каждая страница кешируется
  • Я оптимизировал каждое изображение с помощью ShortPixel, и они обслуживаются как WebP
  • весь CSS и JS минимизированы и объединены с помощью плагина. К сожалению, CSS все еще разделен на три файла, но я не могу найти способ снова скомпилировать его в один.
  • Я использую Cloudflare CDN
  • jQuery загружается из Cloudflare CDN.

Моя текущая оценка скорости страницы составляет около 65-68. Самый большой «красный» фактор - это самая большая содержательная краска.

введите описание изображения здесь

В настоящее время я немного не понимаю, как продолжить работу с LCP, и я не понимаю, почему это значение так велико. Если вы посетите веб-сайт, это будет довольно быстро. Мой опыт составляет около 2 секунд с пустыми кешами и т. Д.

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

Я думаю, что что-то не в порядке с темой. У меня такая же проблема на другом веб-сайте, где я также использовал ту же тему. На ЛКП тоже около 9 секунд.

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

Я действительно не понимаю, как поступить с этим, и, поскольку LCP составляет 25% от общего количества очков, мне бы очень хотелось сократить его до нескольких секунд.

Заранее большое спасибо. Любая помощь очень ценится!


person ralphjsmit    schedule 28.10.2020    source источник
comment
Wordpress и Cloudflare загружают внешние файлы, которые необходимо проанализировать перед отрисовкой страницы (отрисовка содержимого). Зачем вообще вам нужен Wordpress? Можете ли вы получить учетную запись хостинга, а затем разместить нужные файлы локально на сервере хостинга? Это значительно улучшило бы время рендеринга, оставаясь при этом более безопасным.   -  person SJacks    schedule 28.10.2020
comment
моя догадка: h1 помечен, потому что вы загружаете шрифт из Google, и это занимает некоторое время. также у вас нет свойства font-display: swap на ваших шрифтах   -  person Ifaruki    schedule 28.10.2020
comment
Привет, @SJacks примет это во внимание. Нет очевидной причины использовать WordPress; просто я привык пользоваться WordPress. У вас есть руководство или что-нибудь о том, как экспортировать простые файлы HTML и т. Д. Из WP?   -  person ralphjsmit    schedule 28.10.2020
comment
@SJacks, хотя и лучше знает, обслуживает ли кешированные файлы через Cloudflare CDN - это не то же самое, что не использовать WP? Причина, возможно, в том, что я регулярно хочу добавлять страницы, а делать это с WP и Elementor гораздо менее трудоемко, чем кодировать все вручную или регулярно обновлять кучу HTML-файлов.   -  person ralphjsmit    schedule 28.10.2020
comment
Привет, @Ifaruki, спасибо за предложение. Я проверил, но насколько я знаю, правило применяется.   -  person ralphjsmit    schedule 28.10.2020
comment
@ralphsmit: да, использование внешних фреймворков менее трудоемко, но, как видите, за это приходится платить. Файлы кэшируются только после того, как они были загружены и сохранены локально пользователем. В ваших интересах предоставить все необходимые данные как можно быстрее, чтобы снизить показатель отказов. Если вы можете писать свой собственный код и размещать свои собственные файлы и если у вас есть время, это лучшее возможное решение, так как оно даст вам максимальный контроль над временем загрузки.   -  person SJacks    schedule 28.10.2020
comment
@SJacks, пожалуй, лучшая идея. Есть ли у вас опыт работы с таким плагином экспорта WP, как этот wordpress. org / plugins / export-wp-page-to-static-html?   -  person ralphjsmit    schedule 28.10.2020
comment
Извините, я не могу вам помочь. Помимо jQuery, я кодирую только в необработанном формате, никогда раньше не использовал фреймворки вроде Wordpress, никогда не приходилось.   -  person SJacks    schedule 30.10.2020


Ответы (1)


Индекс скорости

Индекс скорости здесь довольно сложно объяснить, поэтому я дам ссылку на эту статью и исходный индекс скорости, на котором основан индекс скорости Lighthouse

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

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

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

#ambition_body.fade_in_out {
    transition-duration: 400ms;
}

Таким образом, ваш индекс скорости может немного отличаться, но во всяком случае он ниже, чем есть на самом деле, так как ваша белая обложка остается дольше 3,4 секунды, когда я применяю регулирование сети и дросселирование ЦП в соответствии с Lighthouse (движком, лежащим в основе Page Speed ​​Insights).

примечание: Вот почему вы видите 9 секунд по сравнению с наблюдаемыми 2 секундами, Lighthouse учитывает дросселирование в сети и ЦП, как указано в связанной статье в предыдущем абзаце.

Самая большая содержательная краска

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

трассировка, показывающая, когда происходит LCP

Похоже, это происходит из-за чего-то странного, возможно, с вашим меню.

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

У меня нет времени искать для вас основную причину, но мое чутье подсказывает, посмотрите, что делает меню при загрузке страницы, и посмотрите, скрываете ли вы это с помощью JS.

Если вы скрываете это с помощью JS и у вас есть 0,2-секундная анимация для каждого элемента на сайте (что не очень хорошая идея) с html * {transition: all 0.2s ease;}, то это может вызвать ненужную перерисовку и задержать LCP.

Актуальная проблема.

Проблема в том, что мы можем немного поспорить о цифрах, но ваш сайт действительно не очень быстрый.

Его вес составляет 1,4 мегабайта, что является высоким показателем, если учесть, что скорость мобильного 3G-соединения может составлять всего около 2 мегабита в секунду (то есть около 250 килобайт в секунду).

Также у вас есть почти мегабайт несжатого кода JavaScript для компиляции и выполнения на сайте (около 250 КБ заархивировано).

Это очень тяжелая работа для мобильного процессора.

Попробуйте избавиться от лишнего JavaScript, однако это сложно при использовании чего-то вроде elementor (как кажется на вашем сайте).

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

person Graham Ritchie    schedule 29.10.2020
comment
Привет, Грэм, большое спасибо за анализ сайта и объяснение всех концепций! Я внимательно все прочитаю и внесу необходимые изменения! Спасибо за уделенное время! ???? - person ralphjsmit; 30.10.2020
comment
Не проблема, надеюсь, это проясняет, почему анализ мобильных устройств занимает больше времени, и что нужно решать. И последнее, что я хотел бы сказать, это меньше сосредотачиваться на оценке и больше на элементах возможностей и диагностики, поскольку они дают вам множество вещей, которые нужно изучить, попробовать и реализовать. Удачи с сайтом! - person Graham Ritchie; 30.10.2020