Pull to refresh

Comments 45

Я так понимаю проект опенсоурс? молодцы :)
Замечательный скрипт, обязательно буду использовать его в своих проектах. Отдельное спасибо вам за статьи на webo.in. Могу помочь в разработке интерфейса для будущего скрипта :)
Вы очень кстати со своим топиком, спасибо! Только сегодня задавался вопросом, как бы всё это автоматизировать. Через пару дней потестируем.
UFO landed and left these words here
Скажите а под wordpress Вы так и не выпустились? а то я смотрел в репозитории чё то нету там вас.
Вот что написано в ридми:

«It's a standard Wordpress plugin install — just copy the entire php_speedy_wp folder into your Wordpress plugins folder. Activate the plugin via the „Plugins“ menu, then go to Options -> PHP Speedy.»
Как я понимаю, под IIS должным образом работать не будет? Ведь он не поддерживает .htaccess
под IIS вообще отдельная история, как и для любых других серверов. Нужно разбирать каждый случай индивидуально. Но особой проблемы нет: важны только конечные алгоритмы — остальное дело техники
+1, хотелось бы под икс такую штуку заполучить. Не критично конечно, но хотелось бы :) Кстати, если в .htaccess что-то прописывается, то можно посидеть и переписать под nginx те же правила.
а кеширование на что? один раз загрузил и забыл.
было бы хорошо если бы скрипт не зависел от вордпресса (ну или классы пускай будут более автономны).
чем отличается от code.google.com/p/minify/?
на данный момент в общих чертах, скорее всего, ничем. Просто есть пара дополнительных возможностей, типа data:URI и того же .htaccess

Да и функциональные требования пониже, чем у minify. И потом хочется все-таки уйти от жесткой привязки к PHP и Apache и сделать более кросплатформенный проект.
Объясните в общих чертах принцип работы скрипта. У меня есть форум, который поддерживает плагины. Каждый из этих плагинов подключает свой CSS и JS файлы, которые находятся в разных директориях. Может ли ваш скрипт в автоматическом режиме или в режиме с напильником, собрать все JS-скрипты в 1 файл?
в режиме с напильником — 100% :)
в полуавтоматическом режиме — если на всех страницах форума подключается один и тот же набор скриптов, то они обработаются и запишутся в один итоговый файл.

Для этого нужно загрузить PHP Speedy и сделать:

# Open the php file that controls the output of HTML that you will be compressing. This might be something like index.php. Include the php_speedy.php file at the very top, i.e like this:
require(’/home/my_site/public_html/aciddrop/php_speedy/php_speedy.php’);
# Add this code at the very bottom $compressor->finish();


Естественно, что хорошо бы сначала настроить директории для кэширования и опции сжатия через установщик (просто открыть саму директорию с PHP Speedy и выбрать опции, либо подправить config.php).
Нет, набор скриптов разный. Просто ваш скрипт использует ob_handlerы, который также использует и форум, думаю напильник пригодится именно тут. На днях попробую прикрутить к форуму и посмотреть на результат.
там самое главное — не выставлять автоматическую очистку папки кэширования: PHP Speedy не умеет все варианты использования отслеживать
Уря!
Вопрос: будет ли плагин нормально работать с другими плагинами, кеширующими и жмущими страницы, как например HyperCache?
по всей видимости, если оставить PHP Speedy только CSS/JS, то проблем быть не должно
Ты смотри, что творит чертяка :)
До:
Yslow F35 lilumi.org.ua
После:
Yslow A lilumi.org.ua

Только у меня есть такая бага, что при включенном этом плагине на вордпресе, перестают работать заголовки от плагина All In Seo Pack. Есть какой-то способ это устранить?
Хорошая иллюстрация: с 35 баллов до 97 :)

Подозреваю, что конфликт между плагинами идет. Попробуем выяснить, в чем проблема. Если есть более детальная информация — большая просьба скинут ьв приват
уже сам разобрался. Оказалось я слишком перемудрил над оптимизацией темы и вырезал все что было в тайтле странице, зная что All in SEO pack в этот тег сам проставляет данные, но при включенном PHP Speedy страница оптимизировалась и пустой тег title удаляла просто-напросто.

Но обнаружил еще один баг, перестали работать табы сделанные на jquery ui.tabs, джаваскрипт обрабатывается, а вот css нет, вместо табов данные идут вниз друг за другом. Я пока еще поковыряюсь, вдруг опять моя ошибка :)
у меня на WP он конфликтует с сSprites, как я понимаю и Sharethis
Ммм… А если файлы подключаются с другого домена, то в репортах все эти файлы отмечаются «Cannot compress external files».
да, надо будет добавить выкачку внешних скриптов через curl + опцию «Не выкачивать внешние скрипты» — чтобы GA не трогался :)
тогда уж, наверное предоставить список с чекбоксами для пользователя, чтобы он сам определял какой скрипт выкачивать и сливать вместе с другими, а какой нет.
Хорошая штука и почти всё в одном. А имеет ли смысл использовать одновременно WP Super Cache и ваш PHP Speedy для WP? Или достаточно только PHP Speedy?
вообще говоря, имеет, но только в том случае, если критична нагрузка на сервер — Super Cache вообще заточен под серверную составляющую
Спасибо, давно искал подобное решение, но… поставил себе на ВП, верстка разьезжается при включеном сжатии css, ощенка в webo.in упала на 3 пункта ( посмотрел, оказывается мои пнгшки сжаты лучше, если с моими пнгшками, то оценка увеличуется на 1 пункт (юзаю PNG Monster — www.vbgore.com/PNG_Monster). С нетерпением жду развития проэкта.
видимо, часть CSS-инструкций «помялась». Можно как-то скинуть / дать ссылку на исходный и «помятый» вариант?
Не отрабатуют свойства присвоенные первому селектору, скорее всего это из-за того, что в начале сжатого цсс-а:

@media screen { body { background: #333;…

не совсем понимаю, откуда и зачем появляется тот иероглиф )
Из ваших же примеров:
aciddrop.com/aciddrop/php_speedy/test_page/compress_me.php?no_images=true&compress=no
aciddrop.com/aciddrop/php_speedy/test_page/compress_me.php?no_images=true.

По второму адресу страница первый раз и правда грузится быстрее (4,01с), по первому — 10,09с.
НО
Есть одно «но» — кэширование. нажимаем F5 и все кардинально меняется. Закешированные файлы из первой ссылки грузятся ГОРАЗДО быстрее, чем новые файлы со второй ссылки.

Итого: если сайт рассчитан на повторное посещение пользователями — то лучше этот скрипт не использовать.
да, это основная проблема — отдача статических файлов. Предполагается ее решить либо за счет жесткого кэширования шаблонов, либо изменения самих шаблонов (чтобы они дергали статические CSS/JS-файлы, а не автособираемые «на лету»).
только ж надо проверять изменился ли файл, если да — то лить новый
оно так и проверяет. Только сама проверка очень ресурсоемкая :) Писали же на Хабре про сложности кэширования
теперь в Web Optimizer 0.4.5 проверка гораздо «умнее» — файл создается только раз, затем просто проверяется на существование на основе исходного HTML. В общем, должно просто летать.
у меня при включении сжатия css постоянно слетает… javascript нормально.
жду развития проекта.
Скрипт действительно хороший, только смутил один момент — о нем ниже. При тестировании на локальной машине и на сервере время загрузки сайта сократилось почти в 2 раза (правда процесс разработки не закончен, поэтому там для оптимизации поле непаханное :))

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

<script type=«text/javascript» src=«scripts/jquery-1.3.2.js»></script>
<script type=«text/javascript» src=«scripts/class.Logger.js»></script>

<?php
$compressor->finish();
?>

Вот так не работает:

Прощу прощения за несколько постов, с непривычки :(
Вообщем проблема вот в чем:
Если разместить подключения скриптов в теле (body) документа
<body

<script src=""
<script src=""
<script src=""
</body
</html

кэширование не заработало и файлы скриптом все равно загружались

Переместил подключение скриптов в секцию head
<head
<script src=""
<script src=""
<script src=""
</head
<body

</body
</html

Все заработало
ага, наконец, понял проблема. PHP Speedy анализирует скрипты только из head. Вообще говоря, нужно скрипты не только объединять, но и вешать на пост-загрузку — но эта вообще отдельная ветка оптимизации.

Я посмотрю, почему там так сделано — вероятно, сложно определить все зависимости скриптов, но тогда можно просто все в конец /body пихать…

В общем, спасибо за замечание
Only those users with full accounts are able to leave comments. Log in, please.