- slaFFik: I can't help you without seeing the site itself. Your problem might be installation related....
- Marc: Hi, thank you for developing this plugin. I'm very interested in using it but can't seem to get it w...
- slaFFik: Спасибо заинтересовавшимся и написавшим мне через форму на странице ...
- Zigzag: Я бы заплатил 50-100$ за плагин модерации. Требуется возможность блокировки юзеров с указанием причи...
- Developer: спасибо, за исправления....
- Роман: Дважды платил за доработку плагинов к WP оба раза по 50$ один раз за добавление в плагин ...
- slaFFik: Спасибо за такой детальный ответ....
- adar12: Нужен нормальный плагин приватности. Чтобы закрывал кроме главной всё (или по выбору), а на клик по ...
- slaFFik: Исправлено в 3.0.1. Релиз был пару часов назад....
- Riyusaki: Печально(( Собственно решение то несложное, я тут подумал, что можно через php решить. через обращен...
Анализ скорости загрузки сайта
На днях вспомнил про один сервис, который позволяет проверить не время генерации страницы, а скорость загрузки этой самой страницы. То есть вычислить время, которое пользователь будет ждать пока загрузится весь ваш сайт. Называется этот сервис .
Что он позволяет:
- узнать время загрузки вашего сайта в секундах (с точностью до сотых);
- иерархия ссылок;
- время начала загрузки каждого отдельного элемента сайта и время, когда он загрузился (то есть можно узнать дельту – разницу, равная времени загрузки элемента);
- размер каждого отдельного загружаемого элемента;
- можно сортировать результаты по времени и порядку загрузки элементов, по размеру и т.п.;
- ну еще много чего можно узнать.
Выглядят результаты вот таким образом:
Время загрузки элементов сайта
Загружаемые файлы и их размер
Советую проверять ваши сайты. Сайт запоминает историю проверок, так что можно сравнивать результаты за разные временные результаты. У меня, к примеру, полгода назад было 6-7 секунд, в январе 9 сек., а сейчас 2,5-3.
Время загрузки моего сайта
Для достижения такого результата я просто посмотрел, что именно загружается дольше всего, и подумал, как это можно уменьшить. В результате вырезал пару ненужных скриптов и рисунков. В скором времени планирую поработать над рисунками.
Если вы после проверки своего сайта не поняли, что надо изменять, сохраните ссылку на результат проверки, опубликуйте ее в комментариях – помогу.
Кстати, я ради интереса посмотрел на Demo.CosyDale.com. Результат меня порадовал – 2.5-3сек. Так что установленный BuddyPress влияет только на нагрузку вашего сервера, а не на время загрузки.
На данный момент 64 комментария ↓
12 мая 2009 в 12:48
Ну с nginx я не могу ничего сказать – не разбираюсь в этом пока. Хотя у самого сайт на нем :)
А про apache – это да, есть такой отрицательный пунктик у него :(
12 мая 2009 в 12:58
Сорри, что спалил тему про browsershots, я не нарочно ;)
12 мая 2009 в 13:03
@Александр:
Хех, да ничего :) У меня идея появилась одна. Раскрою ее на днях. Касаться она будет проверки дизайна сайта не через browsershots, а прямо на компе. Вместе с прогами пост будет, я думаю.
12 мая 2009 в 13:13
@Rastler:
Не делайте скоропалительных выводов о необходимости установки nginx.
Если у вас маленькая посещаемость и большое время загрузки страницы, то скорее всего дело в скорости выполнения php скриптов, а не в скорости отдачи статики. И тогда надо смотреть в сторону кэширования.
Для начала надо все-таки замерить время выполнения самого php скрипта.
12 мая 2009 в 13:18
@Александр: Это я понимаю. А как можно узнать некий benchmark скорости php?
12 мая 2009 в 13:25
У вас сайт на nginx ?
Правда он себя нигде в заголовках ответа не выдает (смотрел страницу и картинку). Ответ везде такой:
12 мая 2009 в 13:37
@Александр:
На nginx у меня. А у Rastler – apache.
@Rastler:
Сервер ваш собственный или виртуалка обычная?
12 мая 2009 в 13:38
@slaFFik: Собственный
12 мая 2009 в 13:42
Ух ты, тогда можно где-то раза в 1,5-2 его ускорить без особых проблем. Прочитайте вот эту запись: Производительность: BuddyPress. Часть 1..
Вам не сам BuddyPress нужен пока, а просто про кеширование (это вторая половина поста).
12 мая 2009 в 13:47
@slaFFik:
Я привел ответ сервера как раз от cosydale.com.
12 мая 2009 в 13:58
@Rastler:
1) Вот пример из документации php
Это ставим в самом начале скрипта:
$time_start = getmicrotime();
Это в самом конце:
$time_end = getmicrotime();
$time = $time_end – $time_start; – это разница в секундах. Т.е. общее время выполнения кода.
Для wordpress, насколько я помню, есть плагин, который выводит время генерации страницы и число запросов к базе.
Ну для простого wordpress можно все вставить в index.php.
Для mu/buddypress надо смотреть.
2) Если надо знать, какая именно функция сколько времени отрабатывет, то уже надо использовать другие методы. Например webgrind. Но тут важно что за хостинг и какой тарифный план.
12 мая 2009 в 13:59
@Александр:
О, значит когда я поменял хостинг-план пару месяцев назад и у меня был сайт недоступен сутки, мне сменили ip и перевезли на другой сервер вообще. Круто :)
Зимой еще стоял nginx. Я не за этим слежу, а за тем, как работает мой сайт и на какой скорости. Пока меня полностью устраивает.
Плагин, который показывает время генерации и запросы, называется WP-Tuner. Идет в сборке WP от Кактуса.
12 мая 2009 в 13:59
WP Super Cache дал 6.3 сек главной страницы, а какие минусы кеширования?
12 мая 2009 в 14:08
Минусы? Хм… Если неправильно настроить, то:
1) при создании новой записи она может некоторое время не появляться для пользователей на главной и странице рубрик, так как им будет подсовывать статичная страница, на которой этой записи еще нет;
2) комментирование может быть затруднено (то есть человек написал сообщение, а оно не появилось);
3) если на сайте очень много страниц, то будет расти его объем, так как кешируемые страницы сохраняются в 2х экземплярах: html (у меня это ~40кб) и gzip (~7-9кб) – второй, если поддерживает сервер;
4) а больше минусов я так вспомнить и не могу…
Но это все при неправильной настройке!
При правильной проблем не будет: кеш будет очищаться при создании новой записи/комментировании (если не очень много записей на сайте), поэтому и комментирование, и новые записи будут появляться вовремя. Значительное ускорение загрузки страниц/записей, если много пользователей одновременно на сайте.
12 мая 2009 в 14:14
@Rastler:
Все зависит от конкретной реализации плагина кэширования.
Можно кэшировать как всю страницу целиком, так и только какие-то блоки на странице.
Например, если плагин будет кэшировать главную страницу на сутки, а вы пишите несколько постов в сутки, то это не очень хорошо. Если же он будет обновлять кэш страницы при добавлении новых постов, то тогда все нормально.
Т.е. логика плагина для кэширования должна быть наиболее
подходящей для конкретных задач.