sitemap archive

Давай WordPress, хутчіш WordPress

в категорії wordpress фішки

теґи :

PHP Speedy гонить і не сигналить :)

php speedy logoДавненько я нічого нового не публікував, все займаюсь іншими речами: роблю свою першу тему для вордпресу, вивчаю 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):
до оптимізації wordpress'у

А ось після того, як я натиснув кнопочку 'Activate' в плагіні PHP Speedy:

після оптимізації WordPress'y завдяки PHP Speedy

Вражає, правда? (тут А це найвища оцінка а F це найгірша, така американська система оцінок)

І маленька ложечка дьогтю: все кльово, але плагін ще не є релізом і тому трапляютсья деякі недоліки, ось наприклад він не може аналізувати css що включені через @import, але обіцяють і це виправити в наступних версіях.

Пробуйте і ви. Провірити можна на око, а можна отримати і точні дані завдяки аддонам Firebug (вкладка NET) та Yslow.

Post to Twitter

24 коментаріrss-comments

[@] ]]>Arys]]> 16 Березня 2009 00:30

Дійсно вражає! Побіг ставити)

 
]]>LaSet]]> 16 Березня 2009 08:49

Я теж хворів оптимізацією блогу але блогам з невеликим навантаженням(це чи не 100% українських блогів) не варто особливо перейматися та обмежувати функціоналість

якщо вже починати оптимізацію то найперше треба злізти з Apache на LightTPD/FastCGI

]]>lilumi]]> 16 Березня 2009 09:18

А чому тобі Апач не подобається? Він же набагато поширеніший ніж FastCGI.
По суті, просто так замінити апач на FastCGI не вдасться, якщо ти не власник серверу хостингу, а провести ось таку клієнтську оптимізацію досить вигідно

 
]]>kernpro]]> 16 Березня 2009 15:10

категорично згоден, підтримую!

]]>lilumi]]> 16 Березня 2009 15:16

підтримуєш перехід на FastCGI ? покажеш як це зробити ;)

 
 
 
]]>Юрко Червоний]]> 16 Березня 2009 09:31

Вдома встановлю і протестую.

 
[@] ]]>Mixa]]> 16 Березня 2009 12:49

LaSet, а в чому полягаэ обмеження функціональності?

 
[@] ]]>jin]]> 16 Березня 2009 16:04

Здається мені, що такий плагін, оптимізуючи трафік, даватиме відчутно більше навантаження на сервер, особливо при великівй кількості запитів

]]>kernpro]]> 16 Березня 2009 16:08

беззаперечно підтримую -‘

 
]]>lilumi]]> 16 Березня 2009 16:12

А чого ти так вирішив? От коли б попробував то таких підозр не виникало б. Ну чого я маю кожному пояснювати. Плагін один раз при авктивізації формує css один загальний з, наприклад, чотирьох, що в тебе є в темі, та один js файл з усіх скриптів, що підключається до сайту. Один раз! Звідки навантаження? Якби так було як ти собі надумав, то навіщо було б його робити. Аж смішно.

]]>kernpro]]> 16 Березня 2009 16:16

“Один раз” – цікаво… А якщо ти щось поміняєш в оригінальних файлах, то це тепер не відобразиться на сайті? Чим тоді ця метода краща від кешування?

]]>lilumi]]> 16 Березня 2009 16:27

Гррррр. Краще один раз спробувати чим отак випитувати. При зміні css’ ів чи js’ів файл автоматично перегенерується.
При кешуванні кешуються всі файли, але щоразу при завантажені броузер опитує сервак чи не змінився файл, а оскільки плагіни кешування не проставляють ETag / Last-Modified теги для файлів стилів та скриптів, то броузер звіряється з тим що в нього вже закешовано. (Плагіни кешування не кешують стилі чи скрипти,вони кешуються лише броузером)
А цей плагін робить один файл, тобто броузер посилає лише один запит і проставляє ETag / Last-Modified тег і броузер бачить чи змінився файл скрипту чи ні.

(нижче коментарі будуть на тому ж рівні)
 
 
]]>Юрко Червоний]]> 16 Березня 2009 16:17

цікавий плаґін, дуже кортить спробувати!

 
 
 
[@] ]]>jin]]> 16 Березня 2009 16:17

один раз? тоді який сенс у плагіні, яки й остійно працює у тебе у WP, і взагалі інтеграції із WP? А як бути із динамічним контентом (у мене не у на усіх сторінках однаковий набір css та скриптів)

]]>lilumi]]> 16 Березня 2009 16:29

він не постійно працює. там все хитро зроблено. Той цсс, чи скрипт, що не винесений в файл стилів звісно що не закешується

 
 
[@] ]]>Mixa]]> 16 Березня 2009 16:34

Ага, я вкурив чому такы рышення то не завжди добре. От один склэний джаваскриптовий файл… Але ж зараз э можливысть керуванти завантаженням скриптів. Наприклад, плагін cforms дозволяє вказати сторінки, на яких слід вантажити його скрипти та стилі, що дуже прикольно. І таких плагінів стає дедалі більше. А якщо ми матимемо один джаваскриптовий файл, то відповідно, при всіх розкладах вантажитиметься код який не завжди потрібен…

]]>lilumi]]> 16 Березня 2009 16:41

тут ти правий, тому в наступних версіях розробники вже дороблять сторінку вибору яких скриптів та цсс-ів потрібно кешувати.

 
 
[@] ]]>Dandr]]> 18 Березня 2009 23:06

Огромное спасибо за http://webo.in/ – треба будь вивчити, що вони насоветовалі.

 
]]>Legion12]]> 30 Квітня 2009 14:59

Попробуем. спасибо!

 
]]>Hyena]]> 21 листопадаа 2010 14:10

Пошел штудировать homepage…

 
[@] ]]>Тусько]]> 18 Грудня 2012 14:35

нічого, в принципі, мені не дало
мабуть, тому, що всі скрипти та стилі розміщені на субдомені

[@] ]]>Тусько]]> 18 Грудня 2012 14:35

скріншоти
test.cs.lviv.pro/php-speedy.jpg

 
]]>lilumi]]> 27 Січня 2013 23:21

ну ти сам написав причину. :)
Зараз основна причина тормознутого завантаження сторінок це кнопки лайків від соц.мереж. Щоб нівелювати цей вплив дехто робить їх завантаження по кліку, або по ховеру.

[@] ]]>Тусько]]> 28 Січня 2013 08:49

я зробив їх асинхронним завантаженням) не повинні б викликати “тормоза”

 
 
 

Ваш коментар

LilumiМене звати LiluMi, а це мій блоґ. Тут про веб-розробку та лайфхаки. Рекомендую підписатись на RSS Інформацію про мене читайте на сторінці me LiluMi
UA TOP Bloggers
Рейтинг блогов Рейтинг блога lilumi.org.ua Рейтинг блогов



Тобі передають привіт 69 медвежаток. Це підняло тобі настрій на 2,060 а в Австралії живе колібрі у якої дзьобик довжиною на 29.17см.