Pull to refresh

Comments 35

wp-cache и wp-super-cache рулят, остальное — в топку.
как потом обновлять такой блог?
Насколько я в курсе, wp-cache и wp-super-cache совместимы с wordpress только до версии 2.5.2. Во всяком случае, у меня (2.6.2) они не работали, и, как я слышал, у многих также не работали.

Впрочем, 1 Blog Cacher тоже далеко не идеально работает — к примеру, если вносятся правки в пост, то кеш не удаляется, приходится руками его удалять.

Пожалуй, стоит приписать, что использовать эти плагины надо с осторожностью.
в 2.6.2 у меня все отлично работает.
возможно, wp-cache использует какие-то платформенно-зависимые возможности php.

у меня сервер, на котором вертится блог, на винде, так что, возможно, в этом дело.
ну да, там симлинк на файл надо делать, php под виндой — это просто мегажесть ::)
Посмотрю, поверчу, попробую.
Может, получится что-то сделать.
Спасибо, как раз борюсь со скоростью загрузки wp, тема нагруженная очень js и картинками) сделаю все по вашему рецепту)
По поводу сжатия картинок и скриптов — глупо, по-моему…
Насчет кэширования и т. д. — настройка отдачи статики через легкий сервер типа nginx (раз уж у вас есть возможность ковырять такие странные модули апача, значит у вас что-то типа сервера или vds?), кстати, он же и созмет все на лету…
насчет оптимизации картинок и скриптов/стилевых файлов — как сказать, как сказать. уменьшение размера на 20-80% это не фигня. вот, к примеру, у вас картинки+js+css размером в 200 KB. Уменьшили вы их на 20 процентов (самый плохой случай), итого размер стал 180 KB, или экономия 20 KB. Теперь прикинем, что у блога посещаемость 500 уников в день. 500*20 = 10000 KB, или почти 9.8 мегабайт. Теперь умножим на 31, и получим, что экономия достигает 300 мегабайт. И это не учитывая сжатых картинок, которые не относятся к файлам темы.
Думаю, экономия значительная, особенно, если у вас сервер на коллокейшене, у которого исходящий трафик лимитирован и платный сверх определенного предела, а блог — только довесок к основным сайтам, вертящимся на нем.

Отчего же? Да, у меня сервер, но редактирование .htaccess доступно даже на самых дешевых хостинговых планах (а на них, думаю, большинство блогов на таких и вертится), так что ничего странного в этих модулях апача нет.

Ну а nginx тоже надо настраивать, чтобы он выставлял заголовки кеширования и жал файлы. Во всяком случае, я настраивал на своих серверах.
у меня js и css жмется gzip-ом, картинки изначально обрабатываются в фотошопе и им делается save for web — зачем весь этот изврат?
Уменьшение (minify) css и js перед сжатием (таким образом, мы сначала уменьшаем файл, а потом жмем его) позволяет (хотя и очень на немного, 0.5-1%) уменьшить размер итогового файла.
Цифра невелика, но, опять же, если перемножать на все заходы, и учесть пусть ничтожное, но уменьшение времени ожидание пользователя, я считаю использование minify оправданным, благо, YUICompressor (или другая утилита, которую вы используете), есть не просит и на карман не давит.

Что касается «save for web» в фотошопе, то pngcrush может и после этого уменьшить размер файлов еще на 2-7 процентов. Имхо, эту утилиту стоит использовать.
а как сделать чтобы динамические части сайта не кешировались
Приведите пример, пожалуйста.
Так, в общем случае, сложно ответить.
ну например есть виджет с последними комментариями который обновляется каждый раз когда кто-то оставит комментарий, если поставить плагин кеширования то это виджет не обновляется. Как сделать так чтобы он не кешировался?
Автор начитался webo.in и решил пост (точнее кросс пост)?
Для пиара своего блога чтоль?
Эта статья скорее сборник готовых решений именно для движка wordpress.
Если ты не заметил, здесь довольно много материала, которого нет на webo.in. Одновременно, здесь много отсылок к webo.in, так как это лучший ресурс по оптимизации загрузки сайта в рунете.

Я не думаю, что каким-то образом отбираю славу у webo.in — скорее, показываю на частном случае (блог на движке wordpress), как применить то, о чем пишет sunnybear
UFO landed and left these words here
Хотелось бы увидеть ссылку на указанные тесты, и если это действительно так (т. е. какая именно верстка, не влияет на скорость загрузки), то я изменю этот пункт. В любом случае, в пользу верстки дивами немало аргументов, так что я пункт оставлю, изменю только содержание.
Ускорить Wordpress? Отличная идея.

Наверное, мало кого сейчас надо убеждать в выигрышности div'овой верстки по сравнению с табличной, но если уж у Вас поднята тема «таблицы vs дивы»… ИМХО, полезно добавить, что верстка div-ами вместе с разбиением странички на файлы типа left-sidebar, right-sidebar, header, footer etc. позволит быстрее и проще поменять какой-нибудь небольшой кусочек кода прямо из панели управления движком (Дизайн -> Редактор тем), чем попытки из этой же панели управления поменять кусочек своей табличной верстки, в которой можно потеряться за забором из tr и td.
Разумно, стоит добавить.
Думаю, эта статья подойдет для многих сайтов, не только wordpress.
несколько сумбурно получилось. Я бы закончил статью выкладкой всех полезных конфигов/скриптов и цифрами: время загрузки было таким-то, стало таким-то. Иначе разговор немного в пустоту получается. Прямо как у Пелевина :)
Да, думаю, скрипты/htaccess и цифры стоит выложить.
Думаю, еще добавлю, что именно править в этих долбанных плагинах, чтобы предметно получалось и совсем неплохо выйдет.
По поводу переноса 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.
ну уж таблицы отрисоввывались после полной загрузки только в Netscape 4 и более старых. Все современные броузеры рендерят таблицы по мере загрузки
Увы, слитие всех JS и CSS в WP — не идеальный вариант. Многие плагины, как автор справедливо заметил, имеют гадскую привычку подключать свои файлы в хидер, и их можно собрать в один. Но. Делать это придётся КАЖДЫЙ раз, когда какой-нибудь плагин надумает обновиться (а происходит это не реже, чем раз в неделю при небольшом числе плагинов). То есть придётся каждую неделю проводить ряд мероприятий, а с автообновлением придётся попрощаться.
Я от такого решения из-за природной лени отказался, ограничившись WP-Cache и отдачей статики Nginx.
Вот-вот! Есть у моего дневника плагин wp-page-navi, который подключает свой CSS в хеадер.
Так вот, в этом CSS всего несколько строк, и конечно же я изменил стили для своей темы.
Плагин чувствую придется вручную обновлять (ведь я внес в него изменения получается), и в хеадере наравне с моим основным CSS подключаются отдельным файлом еще эти несколько строк((

Таким образом, чтобы HTML-разметка была красивой (CSS и яваскрипта по минимуму, а не этот бардак), надо вручную править под себя плагины, и потом вручную же их обновлять. Брррр!!!
просто отключите header.php и лишь выберите из него нужные инклюды и добавьте их вручную, таким образом даже в плагины лезть не придётся. странно что автор не упомянул об этом.
Было бы интересно прочитать про ускорение непосредственно PHP в WordPress, т.е. серверную, а не клиентскую оптимизацию.
Монстры типа mashable и Дж.Чау используют для кеширования плагин W3 Total Cache. Вот только… насколько хорошо он работает? Кто-нибудь пробовал?
Only those users with full accounts are able to leave comments. Log in, please.