Комментарии 35
wp-cache и wp-super-cache рулят, остальное — в топку.
как потом обновлять такой блог?
как потом обновлять такой блог?
Насколько я в курсе, wp-cache и wp-super-cache совместимы с wordpress только до версии 2.5.2. Во всяком случае, у меня (2.6.2) они не работали, и, как я слышал, у многих также не работали.
Впрочем, 1 Blog Cacher тоже далеко не идеально работает — к примеру, если вносятся правки в пост, то кеш не удаляется, приходится руками его удалять.
Пожалуй, стоит приписать, что использовать эти плагины надо с осторожностью.
Впрочем, 1 Blog Cacher тоже далеко не идеально работает — к примеру, если вносятся правки в пост, то кеш не удаляется, приходится руками его удалять.
Пожалуй, стоит приписать, что использовать эти плагины надо с осторожностью.
Спасибо, как раз борюсь со скоростью загрузки wp, тема нагруженная очень js и картинками) сделаю все по вашему рецепту)
По поводу сжатия картинок и скриптов — глупо, по-моему…
Насчет кэширования и т. д. — настройка отдачи статики через легкий сервер типа nginx (раз уж у вас есть возможность ковырять такие странные модули апача, значит у вас что-то типа сервера или vds?), кстати, он же и созмет все на лету…
Насчет кэширования и т. д. — настройка отдачи статики через легкий сервер типа nginx (раз уж у вас есть возможность ковырять такие странные модули апача, значит у вас что-то типа сервера или vds?), кстати, он же и созмет все на лету…
насчет оптимизации картинок и скриптов/стилевых файлов — как сказать, как сказать. уменьшение размера на 20-80% это не фигня. вот, к примеру, у вас картинки+js+css размером в 200 KB. Уменьшили вы их на 20 процентов (самый плохой случай), итого размер стал 180 KB, или экономия 20 KB. Теперь прикинем, что у блога посещаемость 500 уников в день. 500*20 = 10000 KB, или почти 9.8 мегабайт. Теперь умножим на 31, и получим, что экономия достигает 300 мегабайт. И это не учитывая сжатых картинок, которые не относятся к файлам темы.
Думаю, экономия значительная, особенно, если у вас сервер на коллокейшене, у которого исходящий трафик лимитирован и платный сверх определенного предела, а блог — только довесок к основным сайтам, вертящимся на нем.
Отчего же? Да, у меня сервер, но редактирование .htaccess доступно даже на самых дешевых хостинговых планах (а на них, думаю, большинство блогов на таких и вертится), так что ничего странного в этих модулях апача нет.
Ну а nginx тоже надо настраивать, чтобы он выставлял заголовки кеширования и жал файлы. Во всяком случае, я настраивал на своих серверах.
Думаю, экономия значительная, особенно, если у вас сервер на коллокейшене, у которого исходящий трафик лимитирован и платный сверх определенного предела, а блог — только довесок к основным сайтам, вертящимся на нем.
Отчего же? Да, у меня сервер, но редактирование .htaccess доступно даже на самых дешевых хостинговых планах (а на них, думаю, большинство блогов на таких и вертится), так что ничего странного в этих модулях апача нет.
Ну а nginx тоже надо настраивать, чтобы он выставлял заголовки кеширования и жал файлы. Во всяком случае, я настраивал на своих серверах.
у меня js и css жмется gzip-ом, картинки изначально обрабатываются в фотошопе и им делается save for web — зачем весь этот изврат?
Уменьшение (minify) css и js перед сжатием (таким образом, мы сначала уменьшаем файл, а потом жмем его) позволяет (хотя и очень на немного, 0.5-1%) уменьшить размер итогового файла.
Цифра невелика, но, опять же, если перемножать на все заходы, и учесть пусть ничтожное, но уменьшение времени ожидание пользователя, я считаю использование minify оправданным, благо, YUICompressor (или другая утилита, которую вы используете), есть не просит и на карман не давит.
Что касается «save for web» в фотошопе, то pngcrush может и после этого уменьшить размер файлов еще на 2-7 процентов. Имхо, эту утилиту стоит использовать.
Цифра невелика, но, опять же, если перемножать на все заходы, и учесть пусть ничтожное, но уменьшение времени ожидание пользователя, я считаю использование minify оправданным, благо, YUICompressor (или другая утилита, которую вы используете), есть не просит и на карман не давит.
Что касается «save for web» в фотошопе, то pngcrush может и после этого уменьшить размер файлов еще на 2-7 процентов. Имхо, эту утилиту стоит использовать.
а как сделать чтобы динамические части сайта не кешировались
Автор начитался webo.in и решил пост (точнее кросс пост)?
Для пиара своего блога чтоль?
Для пиара своего блога чтоль?
Эта статья скорее сборник готовых решений именно для движка wordpress.
Если ты не заметил, здесь довольно много материала, которого нет на webo.in. Одновременно, здесь много отсылок к webo.in, так как это лучший ресурс по оптимизации загрузки сайта в рунете.
Я не думаю, что каким-то образом отбираю славу у webo.in — скорее, показываю на частном случае (блог на движке wordpress), как применить то, о чем пишет sunnybear
Если ты не заметил, здесь довольно много материала, которого нет на webo.in. Одновременно, здесь много отсылок к webo.in, так как это лучший ресурс по оптимизации загрузки сайта в рунете.
Я не думаю, что каким-то образом отбираю славу у webo.in — скорее, показываю на частном случае (блог на движке wordpress), как применить то, о чем пишет sunnybear
НЛО прилетело и опубликовало эту надпись здесь
Ускорить Wordpress? Отличная идея.
Наверное, мало кого сейчас надо убеждать в выигрышности div'овой верстки по сравнению с табличной, но если уж у Вас поднята тема «таблицы vs дивы»… ИМХО, полезно добавить, что верстка div-ами вместе с разбиением странички на файлы типа left-sidebar, right-sidebar, header, footer etc. позволит быстрее и проще поменять какой-нибудь небольшой кусочек кода прямо из панели управления движком (Дизайн -> Редактор тем), чем попытки из этой же панели управления поменять кусочек своей табличной верстки, в которой можно потеряться за забором из tr и td.
Наверное, мало кого сейчас надо убеждать в выигрышности div'овой верстки по сравнению с табличной, но если уж у Вас поднята тема «таблицы vs дивы»… ИМХО, полезно добавить, что верстка div-ами вместе с разбиением странички на файлы типа left-sidebar, right-sidebar, header, footer etc. позволит быстрее и проще поменять какой-нибудь небольшой кусочек кода прямо из панели управления движком (Дизайн -> Редактор тем), чем попытки из этой же панели управления поменять кусочек своей табличной верстки, в которой можно потеряться за забором из tr и td.
Думаю, эта статья подойдет для многих сайтов, не только wordpress.
несколько сумбурно получилось. Я бы закончил статью выкладкой всех полезных конфигов/скриптов и цифрами: время загрузки было таким-то, стало таким-то. Иначе разговор немного в пустоту получается. Прямо как у Пелевина :)
По поводу переноса javascript в конец файла — а что будет, если js еще не загрузился, а пользователь кликнул на кнопку с onclick=«doSomathing()»? Будет ошибка яваскрипта, а это плохо (первое пришедшее в голову решение: ненавязчиво перейти к «ненавязчивому»яваскрипту )
В таком случае лучшим выходом, имхо, в данном случае будет применение unobtrusive javascript.
Если же javascript занимает в работе приложения такое большое место, то и оптимизировать его надо по-другому.
К примеру, yahoo на странице своей почты при первом посещении грузит сразу одним файлом все — и html, и css, и js, а затем в фоновом режиме подгружает js/css файлы с тем же содержимым, что уже загружено и выставляет куки «ресурсы загржены», и в следующий раз, когда вы идете на эту страницу, сервер смотрит, есть ли у вас куки «ресурсы загружены», и если да, то отдает уже другой файл, который содержит только html данные, а js/css берется из кеша.
А гугл в gmail выставляет прелоудер, который сначала грузит все необходимые js-файлы, а потом только начинает отрисовывать страницу.
Также интересна техника <a href=«ajaxpatterns.org/On-Demand_Javascript'>on-demand javascript.
Если же javascript занимает в работе приложения такое большое место, то и оптимизировать его надо по-другому.
К примеру, yahoo на странице своей почты при первом посещении грузит сразу одним файлом все — и html, и css, и js, а затем в фоновом режиме подгружает js/css файлы с тем же содержимым, что уже загружено и выставляет куки «ресурсы загржены», и в следующий раз, когда вы идете на эту страницу, сервер смотрит, есть ли у вас куки «ресурсы загружены», и если да, то отдает уже другой файл, который содержит только html данные, а js/css берется из кеша.
А гугл в gmail выставляет прелоудер, который сначала грузит все необходимые js-файлы, а потом только начинает отрисовывать страницу.
Также интересна техника <a href=«ajaxpatterns.org/On-Demand_Javascript'>on-demand javascript.
ну уж таблицы отрисоввывались после полной загрузки только в Netscape 4 и более старых. Все современные броузеры рендерят таблицы по мере загрузки
Пару полезны ссылок: «Я хочу WordPress плагин» altblog.ru/wordpress-plugins-i-want/
И альтернативный способ кэширования — превратить всё в статику: kmb-tips.blogspot.com/2008/03/php.html
И альтернативный способ кэширования — превратить всё в статику: kmb-tips.blogspot.com/2008/03/php.html
Увы, слитие всех JS и CSS в WP — не идеальный вариант. Многие плагины, как автор справедливо заметил, имеют гадскую привычку подключать свои файлы в хидер, и их можно собрать в один. Но. Делать это придётся КАЖДЫЙ раз, когда какой-нибудь плагин надумает обновиться (а происходит это не реже, чем раз в неделю при небольшом числе плагинов). То есть придётся каждую неделю проводить ряд мероприятий, а с автообновлением придётся попрощаться.
Я от такого решения из-за природной лени отказался, ограничившись WP-Cache и отдачей статики Nginx.
Я от такого решения из-за природной лени отказался, ограничившись WP-Cache и отдачей статики Nginx.
Вот-вот! Есть у моего дневника плагин wp-page-navi, который подключает свой CSS в хеадер.
Так вот, в этом CSS всего несколько строк, и конечно же я изменил стили для своей темы.
Плагин чувствую придется вручную обновлять (ведь я внес в него изменения получается), и в хеадере наравне с моим основным CSS подключаются отдельным файлом еще эти несколько строк((
Таким образом, чтобы HTML-разметка была красивой (CSS и яваскрипта по минимуму, а не этот бардак), надо вручную править под себя плагины, и потом вручную же их обновлять. Брррр!!!
Так вот, в этом CSS всего несколько строк, и конечно же я изменил стили для своей темы.
Плагин чувствую придется вручную обновлять (ведь я внес в него изменения получается), и в хеадере наравне с моим основным CSS подключаются отдельным файлом еще эти несколько строк((
Таким образом, чтобы HTML-разметка была красивой (CSS и яваскрипта по минимуму, а не этот бардак), надо вручную править под себя плагины, и потом вручную же их обновлять. Брррр!!!
Было бы интересно прочитать про ускорение непосредственно PHP в WordPress, т.е. серверную, а не клиентскую оптимизацию.
Монстры типа mashable и Дж.Чау используют для кеширования плагин W3 Total Cache. Вот только… насколько хорошо он работает? Кто-нибудь пробовал?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ускоряем wordpress