15
PHP Speedy гонить і не сигналить :)
Давненько я нічого нового не публікував, все займаюсь іншими речами: роблю свою першу тему для вордпресу, вивчаю css та jquery, взявся за сайт присвячего доктору Хаусу, найняв туди контент-менеджера, тепер всі прибутки з того сайту йдуть їй на зарплату, але впевнений, що це швидко окупиться.
А ще давно я собі намітив в todo'шках, аби оптимізувати код сторінок сайту, бо вони занадто багато займають. Загалом проблема великого розміру коду сторінок властива всім вордпресовським блогам, на які поначіплювано багато плагінів, чи використовують преміум-теми. Колись провіряв по сервісу webo.in свій блог, так він знайшов багато слабких місць і дав довжелезний список рекомендацій, як покращити код сайту і зробити його швидшим та легшим для завантаження.
Коли я то все почав вручну робити, то вже на перших пунктах затикався, бо не знав як додавати ETag / Last-Modified для файлів, зменшувати кількість css та javascript'ів теж непросто, бо не знаєш, чи надовго в тебе той чи інший плагін, який їх використовує. Короче, я забив на то всьо і зрозумів, що ще не доріс до такої оптимізації.
І тут, буквально позавчора натикаюсь на один скрипт, що оптимізує сайти якраз по цим параметрам. А як я втішився, коли побачив, що для wordpress'у вони випустили плагін, що робить всю ручну оптимізацію автоматичною, по натисканню однієї кнопки. Ляпота!
Загалом суть цього плагіну така: він об’єднує всі css-файли в один, всі js скрипти теж в один файл, потім його стискає gzip'ом, додає ETag / Last-Modified для усіх файлів, мініфікує сторінки (minify), додає кешуючі заголовки до всіх файлів, а в наступних версіях навіть обіцяють автоматом збирати CSS-спрайти (CSS Sprites).
І все що треба, так це скачати плагін PHP Speedy, активувати, та перейти на сторінку його налаштувань, де за допомогою підказок ви дізнаєтесь, що треба зробити. На правильних хостингах (яким я вважаю TOPUA.net) нічого не треба змінювати, а ось на більшості прийдеться змінити права доступу на файл конфігу плагіну, та дати права 777 на папку cache цього плагіну, в якій і будуть зберігатись наші оптимізовані css та js файли.
Я коли провірив, то очам своїм не міг повірити. Ось характеристика моєї головної сторінки блогу до оптимізації (дані взяті з плагіну Yslow):
А ось після того, як я натиснув кнопочку 'Activate' в плагіні PHP Speedy:
Вражає, правда? (тут А це найвища оцінка а F це найгірша, така американська система оцінок)
І маленька ложечка дьогтю: все кльово, але плагін ще не є релізом і тому трапляютсья деякі недоліки, ось наприклад він не може аналізувати css що включені через @import, але обіцяють і це виправити в наступних версіях.
Пробуйте і ви. Провірити можна на око, а можна отримати і точні дані завдяки аддонам Firebug (вкладка NET) та Yslow.
![[Post to Twitter]](http://lilumi.org.ua/wp-content/plugins/tweet-this/icons/tt-twitter-micro4.png "Давай Wordpress, хутчіш Wordpress"){kind=icon}
Дійсно вражає! Побіг ставити)
Я теж хворів оптимізацією блогу але блогам з невеликим навантаженням(це чи не 100% українських блогів) не варто особливо перейматися та обмежувати функціоналість
якщо вже починати оптимізацію то найперше треба злізти з Apache на LightTPD/FastCGI
А чому тобі Апач не подобається? Він же набагато поширеніший ніж FastCGI.
По суті, просто так замінити апач на FastCGI не вдасться, якщо ти не власник серверу хостингу, а провести ось таку клієнтську оптимізацію досить вигідно
категорично згоден, підтримую!
підтримуєш перехід на FastCGI ? покажеш як це зробити ;)
Вдома встановлю і протестую.
LaSet, а в чому полягаэ обмеження функціональності?
Здається мені, що такий плагін, оптимізуючи трафік, даватиме відчутно більше навантаження на сервер, особливо при великівй кількості запитів
беззаперечно підтримую -'
А чого ти так вирішив? От коли б попробував то таких підозр не виникало б. Ну чого я маю кожному пояснювати. Плагін один раз при авктивізації формує css один загальний з, наприклад, чотирьох, що в тебе є в темі, та один js файл з усіх скриптів, що підключається до сайту. Один раз! Звідки навантаження? Якби так було як ти собі надумав, то навіщо було б його робити. Аж смішно.
«Один раз» — цікаво... А якщо ти щось поміняєш в оригінальних файлах, то це тепер не відобразиться на сайті? Чим тоді ця метода краща від кешування?
Гррррр. Краще один раз спробувати чим отак випитувати. При зміні css' ів чи js’ів файл автоматично перегенерується.
При кешуванні кешуються всі файли, але щоразу при завантажені броузер опитує сервак чи не змінився файл, а оскільки плагіни кешування не проставляють ETag / Last-Modified теги для файлів стилів та скриптів, то броузер звіряється з тим що в нього вже закешовано. (Плагіни кешування не кешують стилі чи скрипти,вони кешуються лише броузером)
А цей плагін робить один файл, тобто броузер посилає лише один запит і проставляє ETag / Last-Modified тег і броузер бачить чи змінився файл скрипту чи ні.
цікавий плаґін, дуже кортить спробувати!
один раз? тоді який сенс у плагіні, яки й остійно працює у тебе у WP, і взагалі інтеграції із WP? А як бути із динамічним контентом (у мене не у на усіх сторінках однаковий набір css та скриптів)
він не постійно працює. там все хитро зроблено. Той цсс, чи скрипт, що не винесений в файл стилів звісно що не закешується
Ага, я вкурив чому такы рышення то не завжди добре. От один склэний джаваскриптовий файл... Але ж зараз э можливысть керуванти завантаженням скриптів. Наприклад, плагін cforms дозволяє вказати сторінки, на яких слід вантажити його скрипти та стилі, що дуже прикольно. І таких плагінів стає дедалі більше. А якщо ми матимемо один джаваскриптовий файл, то відповідно, при всіх розкладах вантажитиметься код який не завжди потрібен...
тут ти правий, тому в наступних версіях розробники вже дороблять сторінку вибору яких скриптів та цсс-ів потрібно кешувати.
Огромное спасибо за — треба будь вивчити, що вони насоветовалі.
Попробуем. спасибо!