Как уменьшить время первого байта или первое время загрузки

Я разработал сайт joomla 3.2. Я тестировал его с помощью webpagetest.org, и я получил следующие результаты.

First Byte Time-F
Keep-alive Enabled-A
Compress Transfer-A
Compress Images-A
Progressive JPEGs-F
Cache static content-A
Effective use of CDN-yes

ссылка для результата - http://www.webpagetest.org/result/140205_RX_DE5/1/details/ www.webpagetest.org/result/140205_RX_DE5/

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

Здесь ссылка на мой сайт- http://www.guru99.com

Пожалуйста, помогите мне улучшить работу сайта.

ОТВЕТЫ

Ответ 1

У меня было около 0,8/1 с ttfb с общим хостингом. Переместился на VPS с помощью службы apache на nginx и PHP-FCGI

Все еще не хватило. TTFB составлял 250/400 Поиск в Интернете в течение 3 дней. Без какого-либо результата при опускании ttfb.

Пока я не нашел это: http://help.directadmin.com/item.php?id=567

OpCache Помогите мне уменьшить ttfb до 0,12/0,2 мс для моего сайта joomla.

Ответ 2

  • Как уже упоминалось, речь идет примерно о двух вещах вашего сервера и вашего приложения.

  • Похоже, вы находитесь на общем хосте/ip-адресе в Hivelocity, чтобы это повлияло на ваш TTFB. Хотя для общего хоста 619 ms First Byte Time не ужасно. Помните, что A - только 192 мс, поэтому получение F на полсекунды больше.

  • Вы используете шаблон на основе каркаса Gantry, который, вероятно, является одним из самых тяжелых для шаблонов Joomla (хотя ни один из коммерческих поставщиков Joomla не очень легкий). RocketTheme предоставляет собственное расширение кеша для использования с их шаблонами, вы можете попробовать, хотя я не уверен, как это повлияет на остальную статистику.

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

Для прогрессивного JPEG мы использовали Optim в прошлом, а также на GitHub.

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

Ответ 3

Я должен признать, ваш вопрос вдохновил меня, поэтому я провел последние 2 дня, работая над оптимизацией. После экстремальных испытаний я получил Время первого байта B. Для этого я решил использовать плагин JCH Optimize. Что касается параметров, я включил все, кроме объединения CSS и JS, так как это привело к ошибке консоли.

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

Что касается изображений, любых изображений .jpg, которые я использовал, я открылся в Photoshop и сделал CTRL + Shift + ALT + S и выбрал опцию "Прогрессивный". Один из выполненных и загруженных, я снова проверил тест и получил A для прогрессивных JPEG.

Попробуйте сделать то же самое и посмотрите, каков результат. Надеюсь, что это поможет

Ответ 4

TTFB связан главным образом с двумя вещами: вашим сервером и вашим приложением.

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

Что касается уменьшения TTFB для Joomla, убедитесь, что вы включили кеширование (будьте осторожны, но кэширование Joomla происходит за счет).

Ответ 5

Я согласен с пользователем cppl в том, что TTFB не обязательно является значимым измерением и собирался ссылаться на та же статья о Cloudflare. В статье говорится: "С точки зрения конечного пользователя TTFB практически бесполезен... он фактически отрицательно коррелирует со временем загрузки: чем хуже TTFB, тем лучше время загрузки".

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

Чтобы ответить на ваш вопрос о том, как улучшить производительность сайта, я запустил ваш сайт через YSlow и обнаружил несколько вещей, которые должны улучшить производительность сайта с точки зрения конечного пользователя:

  • Есть HTTP-запросы для 26 внешних скриптов javascript и 15 внешних таблиц стилей. Вы считали, что объединить хотя бы некоторые из них в меньшее количество файлов? Один большой .js файл может быть предпочтительнее нескольких небольших .js файлов, а также файлов CSS.
  • Переместите файлы javascript в нижней части своей индексной страницы (только внутри тега тела) вместо загрузки их в голову документа. В некоторых исключительных случаях вам может понадобиться отдельный файл .js для загрузки до разметки страницы, но в большинстве случаев рекомендуется иметь javascript, загруженный в нижней части страницы, что позволяет разметку на первой странице.
  • По возможности уменьшите ваши javascript и файлы CSS.

Ответ 6

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

Ответ 7

Сжатие Gzip и время загрузки действительно живут в concurrency, но TTFB скорее всего является симптомом числа запросов и недействительности программ или SQL-запросов, и поскольку вы используете CMS очень вероятно.

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

Известно, что CMS выполняет множество запросов, так как общее число запросов на странице составляет 100+. Чтобы изучить время разработки, вы можете установить на сервере инструмент мониторинга запросов или профилирования, эквивалент Drupal - это модуль Devel, я полагаю, что на Joomla что-то похожее. Основные шаги к ускорить работу с каркасом приложения в моем опыте здесь.