но прежде было значение 99 для ПК и 48 примерно для мобильных. Сейчас — 66 и 15.
Это наверняка гуглопопугаи от гуглофейка? Так он просто их изменил.
Скорость вообще измеряется не в них, а в объёме, полученном за единицу времени. Напр байт/сек.
С «скорость» Вашего сайта относительно не плохая, но работать есть над чем https://tools.pingdom.com/#5a2b49c7fe000000
Модератор
Yui
(@fierevere)
永子
работать есть над чем
в частности — обязательно включите сжатие gzip и заголовки кеширования для браузера expires
за них вы и получаете основной «штраф»
ps:
Хотя с другой стороны, возможно это просто анализатор глючит,
т.к. сжатие у вас есть — br (brotli), вместо gzip, это даже лучше, но анализаторы могут пока его не учитывать
заголовки кеширования, как минимум для нужных ресурсов я тоже вижу
значит побольше скепсиса на эти «попугаи»
-
Ответ изменён 5 лет, 7 месяцев назад пользователем
Yui.
Это наверняка гуглопопугаи от гуглофейка? Так он просто их изменил.
Я именно про скорость, два файла созданных WPFC:
sviv.css(vkususpeha.ru):
115 KB — 2 730 ms
sviv.js(vkususpeha.ru)
105 KB — 2 730 ms
Думаю, это довольно долго (и точно было гораздо быстрее).
Я отключал на днях гугл шрифт, потом вернул его (решив позже взяться за css, переписать).
Может совпадение, после этого заметил эти проблемы. Опять же, хостинг вроде довольно надежен, не очень верится, что проблема у них.
То есть, 4 дня назад были значения 99 — 48, сегодня 66 — 16, и наибольшая потеря времени именно в 2 созданных плагином файлах.
Или проблема может быть в самом сервисе, он указывает неверные значения? Заранее извиняюсь, если вопросы странные — первый сайт. Но как я понимаю, потенциальная экономия времени — это по сути и есть время загрузки и обработки файла?
Модератор
Yui
(@fierevere)
永子
эти файлы периодически ( по времени, по изменению остальных файлов js и css )
пересоздаются и обычно кешируются, чтобы отдаваться без задержек.
Попробуйте несколько раз прогнать тесты
а еще лучше посмотреть у себя в инспекторе браузера на вкладке сеть
с перезагрузкой страницы по Ctrl F6
Не исключен вариант что веб-сервер LiteSpeed вашего хостинга совершает принудительную оптимизацию-минификацию используя mod_pagespeed,
в таком случае оптимизирующие css и js плагины на стороне WordPress нужно отключить.
эти файлы периодически ( по времени, по изменению остальных файлов js и css )
Я поэтому и написал про гугл шрифт (отключал его плагином) — по логике, после этого файлы должны были пересоздаться, и новые стали очень долго грузиться. Возможно, совпадение, просто в голову больше ничего не приходит, почему вдруг скорость упала.
в таком случае оптимизирующие css и js плагины на стороне WordPress нужно отключить.
Пробовал отключать WPFC совсем, а также оптимизацию css и js — еще медленнее грузится сайт (и по PageSpeed Insights, и по ощущениям).
Щас и админка стала тупить — напишу в саппорт, возможно проблема у хостинга.
Но если предположить, что дело именно в плагине — никаких вариантов нет, что может быть?
Модератор
Yui
(@fierevere)
永子
возможно ваш хостинг только перешел на использование LiteSpeed или провели реконфигурацию сервера, узнайте у них.
Спасибо за ответы) Подожду, что ответят. Если проблема не на хостинге, и не в плагине, ума не приложу, что еще могло резко измениться за 3 дня…
Будет видно, еще раз спасибо за помощь)
Я именно про скорость, два файла созданных WPFC:
sviv.css(vkususpeha.ru):
115 KB — 2 730 ms
sviv.js(vkususpeha.ru)
105 KB — 2 730 ms
Вообще-то 192 и 376 соответственно: https://i.imgur.com/6DuS86P.jpg
Но работать стоит в первую очередь над этим
И если первое решается частично удалением ненужного а остальное серверным сжатием (без всяких кеш-плагинов), то второе нужно делать руками.
И если первое решается частично удалением ненужного а остальное серверным сжатием (без всяких кеш-плагинов), то второе нужно делать руками.
js для меня «темный лес», не смог в свое время его понять, в отличии, к примеру, от php — за подсказку спасибо, в будущем попробую разобраться. Но сейчас для меня это невыполнимая задача, привести в порядок js.
С картинками проще и сложнее, они важны для сайта и совсем в плохом качестве их выкладывать не хочется — но опять же спасибо, потом попробую уменьшить их, без особой потери качества.
А насчет времени — упорно PageSpeed Insights показывает, что потенциальная экономия (для мобильных) 2 700 мс. Может правда проблема в сервисе. Хотя я не понимаю, по логике это довольно объективный показатель должен быть — если потенциальная экономия 2 700, значит эти файлы загружаются и обрабатываются дольше этого времени. Или я чего-то просто не понимаю.
ПС: На хостинге все хорошо, ответил саппорт.
js для меня «темный лес»,
В него и не надо лезть. Стоит удалить ненужные плагины и по возможности из темы вызовы ненужных скриптов. Но главное — это серверное сжатие.
Но тут см выше:
Хотя с другой стороны, возможно это просто анализатор глючит,
т.к. сжатие у вас есть — br (brotli), вместо gzip, это даже лучше, но анализаторы могут пока его не учитывать
упорно PageSpeed Insights показывает,
Да забейте на него. Это фейковый сервис, ни на что не влияющий. Почитайте лучше те два топика на сёрче что я давал выше.
Модератор
Юрій
(@yube)
Или я чего-то просто не понимаю.
Того, что Гуглю нельзя безоговорочно доверять. Ни в чём. 🙂
Да забейте на него. Это фейковый сервис, ни на что не влияющий. Почитайте лучше те два топика на сёрче что я давал выше.
Того, что Гуглю нельзя безоговорочно доверять. Ни в чём. 🙂
Смирюсь с этими ненавистными цифрами. А как время будет воспользуюсь советами из этой темы, еще раз спасибо)
Модератор
Yui
(@fierevere)
永子
На хостинге все хорошо, ответил саппорт.
солнце будет всходить на западе, а садиться на востоке, если поддержка хостинга начнет отвечать иначе 😉
