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