Здрастуйте, шановні читачі блогу . Напевно, вам вже набридла тема збільшення швидкості завантаження сайту (виміряти швидкість інтернету), якій я присвятив левову частку статей що вийшли в січні. Але що поробиш, хочеться викласти все те, що було зрозуміле і зроблено для прискорення цього блогу, поки підступна пам’ять не затерла нюанси і важливі моменти.
Сьогодні я хочу спробувати систематизувати все те, про що вже було мною написано з приводу оптимізації швидкості, а також додати суттєві моменти, що дозволяють трохи знизити навантаження на сервер хостингу за рахунок використання не динамічного, а статичного Gzip стиснення.
Як можна швидко збільшити швидкість завантаження сайту
Отже, весь процес оптимізації швидкості, на мій погляд, слід починати з установки Page Speed. C допомогою цього доповнення для Фаерфокса або Хрому ви можете всебічно оцінити швидкість завантаження сторінок свого сайту і отримати цінні рекомендації щодо її збільшення (можете також ознайомитися і з іншими корисними доповненнями для браузера Мазило).
При першому запуску Page Speed для головної сторінки мого блогу я побачив ось таку сумну картину:
Всього 72 бала зі 100 можливих і купа зауважень зазначених червоних кольором. Правда виконавши практично всі рекомендації, які мені давав цей плагін, головна сторінка отримала від нього вже більш високу оцінку в 94 бала.
Але крім Page Speed дуже наочно оцінити швидкість завантаження сайту і подивитися всі завантажувані об’єкти можна в онлайн-сервісах з вимірювання швидкості завантаження — Pingdom і йому подібних.
З початку відбувалася підвантаження майже 90 об’єктів (ccs, js, зображення) і на кожен з них потрібен окремий http запит. Але, проаналізувавши за допомогою зазначених вище онлайн сервісів, всі завантажені об’єкти, а також дотримуючись порад Page Speed, мені вдалося скоротити їх кількість до трьох десятків, що не могло не позначитися на загальній швидкості:
Ну, а тепер згадаємо про всіх методах по порядку. І починати оптимізацію слід, напевно, у порядку відображення проблемних місць у вікні Page Speed, бо це будуть найбільш ефективні і самі не складні в реалізації кроки — що називається «дешево і сердито».
Тому я і зайнявся першим ділом налаштування кешування статичних об’єктів (ccs, js, зображення) в браузерах відвідувачів (тобто вас, мої шановні читачі).
Так, так, з допомогою налаштувань web сервера можна управляти поведінкою браузера відвідувачів. У цьому випадку перший повідомляє другого час, протягом якого слід зберігати в кеші статичні об’єкти для того, щоб не запитувати їх повторно з сервера.
Ця, на перший погляд незначна налаштування, однак вона здатна творити чудеса в збільшення швидкості завантаження сторінок вашого ресурсу для тих відвідувачів, які вже одного разу на ньому побували, т. к. в кеші їх браузерів вже знаходяться файли стилів і скриптів, а також зображення зі складу вашого шаблону, які будуть одними і тими ж для всіх сторінок.
На жаль, описані мною способи управління через .htaccess не завжди спрацьовують, в силу різних причин (відсутність необхідного модуля тощо), тому можна спробувати з цього питання звернутися до свого хостера, бо він теж буде зацікавлений в цьому, т. к. оптимальні налаштування кешування в браузерах користувачів призведуть до зниження навантаження вашого ресурсу на його хостинг.
Наступним ефективним кроком по збільшенню швидкості завантаження може бути об’єднання зовнішніх файлів стилів CSS або скриптів JS. Читайте про те, як об’єднати зовнішні CSS в один загальний файл і відключення зовнішніх CSS, з якими я розібрався.
Але от об’єднати зовнішні скрипти мені не вдалося, напевно, в силу нерозуміння навіть основ JavaScript. Правда у мене було всього два зовнішніх файлу зі скриптами, тому втрата швидкості завантаження сайту буде не велика.
Але крім об’єднання зовнішніх стилів CSS і скриптів (це робиться для зменшення загальної кількості завантажуваних об’єктів, що дозволить зменшити число http запитів до сервера), ці самі файли стилів і скриптів можна буде дуже ефективно стиснути за допомогою Gzip (фактично це той же самий Zip, який ви активно використовуєте на комп’ютері).
Стиснути CSS і Js файли за допомогою Gzip можна в кілька разів, але ще більше зменшити розмір цих файлів можна за рахунок попередньої оптимізації їх коду.
Я писав вже про оптимізацію і стиснення CSS за допомогою Page Speed. Правда для цього ви можете скористатися спеціальними програмами, які не тільки прибирають зайві прогалини і коментарі, але і намагаються коригувати самі CSS властивості.
Але мені все ж більше по душі просте стиснення, яке здійснює Пейдж Снід — код залишається абсолютно нечитабельним і навіть більш зручним у використанні.
За аналогією з Css у вас буде можливість отримати стислі версії своїх зовнішніх скриптів, з яких будуть видалені зайві прогалини і коментарі.
Після цього, застосування Gzip архівації файлів стилів і скриптів вашого ресурсу призведе до ще більшого зменшення їх розміру, а отже і швидкості завантаження. Але от саме по стисненню Html, Css і Js у мене виникло цілий ряд запитань, які я з відносним успіхом спробував вирішити.
Статичний Gzip стиснення для зниження навантаження на сервер
По-перше, Gzip на сервері при його традиційному способі активації (описано в цій статті — Як включити Gzip стиск через .htaccess) буде виконуватися в реальному часі, тобто таким чином ми реалізували динамічне архівування. Що це означає?
Справа в тому, що для кожного нового користувача, відкриває сторінки вашого сайту, буде повторно в реальному часі здійснюватися архівація на льоту файлів Html, Css і Js. Як ви розумієте, по-перше, це буде займати якийсь час, а по-друге, стиснення на льоту буде споживати додатковий ресурс процесора сервера.
У мене ситуація з навантаженням блогу досить-таки жалюгідна — балансую на грані фолу. Тому будь-яка можливість зниження її, не призводить до зменшення швидкості завантаження сайту, буде дуже навіть до речі.
Такою соломинкою, за яку я вирішив вхопитися, стало статичне Gzip стиснення Html, Css і Js, яке здійснюється попередньо, а користувачам віддаються вже готові архіви, не сповільнюючи швидкість і не створюючи зайву навантаження на процесор хостингу.
Особливо актуальна ця проблема для зовнішніх скриптів і стилів (Css і Js), бо вони взагалі практично ніколи не змінюються, але при цьому здійснюється їх повторне і безцільне архівування на льоту при кожному відкритті сторінки вашого ресурсу. Було б набагато логічніше завчасно закатати їх в Gzi, а web серверу вказати потрібний порядок дій.
З урахуванням різного сприйняття деякими браузерами файлів з розширенням .gz (архіви Gzip) зазвичай використовують досить хитрий спосіб перейменування архівів у звичайні файли стилів з розширенням .CSS і скриптів.
А .htaccess будуть додані рядки, що пояснюють web сервера, як подавати ці файли різних браузерам. В общем-то, така досить заплутана схема працює і тому я опишу детальніше всі кроки підготовки Gzip архівів і наведу код .htaccess.
Отже, такі дії повинні будуть вами виконані для всіх зовнішніх стилів і скриптів, які завантажуються разом зі сторінками вашого сайту. У уникнення втрати даних при помилці обов’язково скопіюйте на комп’ютер всі дані (докладніше читайте в цій статті про бекап і резервне копіювання бази даних і файлів).
Отже, вам потрібно буде завантажити на свій комп’ютер всі зовнішні Css і Js файли, які беруть участь у завантаженні сторінок (після того, як ви здійснили їх об’єднання це буде не складно) і створити з кожного з них його резервну копію з розширенням .gz. Зробити це можна за допомогою безкоштовної програми 7zip. Далі давайте покажу на прикладі, бо тут теоретизувати марно.
Візьмемо для прикладу основний файл стилів мого блогу style.css. Після того, як я його упакую у Gzip з допомогою програми 7zip, у мене з’явиться архів style.css.gz.
Але оскільки деякі браузери не захочуть підключати стильовий файл з розширенням .gz, то ми видаляємо у нього закінчення .gz і знову отримуємо в підсумку style.css, але який вже фактично являє з себе архів (поки ще не заплуталися?).
Але просто замінити оригінальний файл style.css на сервері (ще не стиснутий у Gzip) тільки що створеним нами архівом, але мають, як і раніше, назва style.css, буде не достатньо.
Адже деякі браузери як і раніше не підтримують стиснення (зазвичай це старі версії, які тим не менш ще використовуються користувачами), тому поруч із style.css, який вже фактично буде архівом (пам’ятаєте ми у нього видалили розширення .gz), нам потрібно буде покласти оригінальний не стиснутий файл стилів.
Але назвати ми його повинні будемо вже інакше, ніж style.css. Для цього можна його перейменувати, наприклад, таким чином: style.nogzip.css. Тепер на сервері в папці з темою оформлення WordPress у мене буде лежати два файлу стильового оформлення:
Дану операцію вам потрібно буде виконати для всіх зовнішніх стилів і скриптів (Css і Js), які завантажуються разом зі сторінками вашого ресурсу. У мене їх було всього лише чотири: основний стильовий, в якому у мене також додані властивості деяких плагінів WordPress, а ще файл скрипта з папки з темою оформлення та два зовнішніх скрипта від плагіна SyntaxHighlighter.
Тепер, щоб статичний стиск для зовнішніх стилів і скриптів запрацювало, вам потрібно відкрити на редагування .htaccess з кореневої папки вашого ресурсу і замінити код, що відповідає за Gzip наступним модифікованим кодом:
RewriteEngine On
RewriteCond %{HTTP:Accept-encoding} !gzip [OR]
RewriteCond %{HTTP_USER_AGENT} Konqueror
RewriteRule ^(.*)\.(css|js)$ $1.nogzip.$2 [QSA,L]
Header append Vary User-Agent
Header set Content-Encoding: gzip
Header set Cache-control: private
Header unset Content-Encoding
Якщо ви перейменування оригінальних файлів стилів і скриптів використовували їх назви, відмінні від style.nogzip.css, то і у відповідному рядку коду вам потрібно буде замінити маску $1.nogzip.$2 на свою. Загалом-то, ось і все.
Тепер сервер буде кожен раз на льоту стиснення Css і Js, а буде відразу ж відправляти браузерам заздалегідь стислу вами копію, а у разі браузера, який не розуміє Gzip — оригінальну версію файлу виду подібного style.nogzip.css.
На обличчя буде невелике збільшення швидкості завантаження сайту і зниження навантаження вашого ресурсу на хостинг. От тільки у мене через пару днів стався конфуз. Мабуть очистився кеш мого браузера і вид адмінки WordPress різко змінився — відвалилося стильове оформлення.
Але проблема досить швидко вирішилася проведенням описаних вище маніпуляцій з використовуваним в адмінці файлом стилів. У моєму випадку це був colors-classic.css з папки:
/wp-admin/css
Далі мені захотілося застосувати статичне Gzip стиснення для Html-файлів, які теж стискуються сервером нальоту, створюючи додаткове навантаження. Тут я знайшов рішення досить просте, стосовно до WordPress. Справа в тому, що в мене вже дуже давно використовується плагін для кешування Hyper Cache.
В його налаштуваннях є область «Compression», яка, як я спочатку думав, відповідає за компактне розміщення кешованих сторінок на жорсткому диску хостингу. Мені здалося, що архівування кешованих сторінок буде від’їдати непотрібне час у процесора і благополучно його відключив.
Але от трохи пошукавши інформацію на тему Gzip стиснення Html сторінок, я змінив свою думку про ці налаштуваннях компресії в плагіні Hyper Cache.
Схоже, що поставивши галочку у полі «Enable compression», ми тим самим активуємо попереднє стиснення кешованих сторінок блогу за алгоритмом Gzip.
Стверджувати це на сто відсотків не беруся, але після активації компресії у налаштуваннях Hyper Cache я спостерігаю вже на протязі тривалого часу зниження навантаження на сервер. Загалом схоже, що як і завжди — скринька просто відкривався.
До речі, якщо ваш проект побудований на базі Joomla, то для неї є кілька дуже непоганих (за відгуками користувачів) компонентів, які дозволяють максимально задіяти описані мною способи підвищення швидкості завантаження сайту, але при цьому все буде значно простіше, тому що багато чого зроблено автоматично з мінімальними вашими витратами по налаштуванню.
Сам я ці компоненти ще не тестував, але як тільки зберуся, то обов’язково про них напишу. Поки ж лише наведу посилання на ці компоненти для Джумлы: jFinalizer і WEBO Site SpeedUp.
Оптимізація графіки та зменшення кількості запитів
Також дуже істотний вплив на швидкість завантаження може надати оптимізація графіки. Як я вже писав раніше, оптимізувати зображення можна Page Speed. Але це буде зручно тільки у разі невеликої їх кількості.
Особисто я для пакетної оптимізації використовував онлайн сервіс PunyPNG, про який вже досить докладно писав. Можна також скористатися і іншим дуже популярним онлайн сервісом для стиснення фото без втрати якості від Yahoo.com — Smush.it. Але ступінь стиснення фото в PunyPNG мені здалася вище, можливо за рахунок використання більш вдалих скриптів.
Я скопіював папку з зображеннями свого блогу на комп’ютер і завантажив їх усі (пачками по 15 штук, бо існує в PunyPNG таке обмеження) на цей онлайн сервіс, а потім скачав загальний архів, що містить вже оптимізовані картинки з мого блогу.
Загалом, витративши півгодини мені вдалося стиснути PNG зображення приблизно на 7 відсотків у середньому, а Gif і Jpg відсотків на 5.
В результаті, загальний розмір всіх картинок використовуються на моєму блозі зменшився на кілька мегабайт, що, без сумніву, позначиться на збільшенні швидкості завантаження сайту, так і дозволить трохи знизити навантаження на сервер хостингу.
Ну і останнім, а також одним з найбільш дієвих способів прискорення, може бути зменшення кількості http запитів, що буде формуватися при завантаженні сторінки вашого ресурсу. Зменшити їх можна, знизивши число об’єктів, що завантажуються разом з веб-сторінкою. Ми вже говорили на початку статті про об’єднання зовнішніх Css і Js файлів якраз для цієї мети.
Але левова частка запитів завжди йде на підвантаження графіки. Це можуть бути фонові зображення, які були згадані у файлі стильового оформлення, або ж картинки, безпосередньо задаються в Html-коді сторінки.
Для зменшення їх кількості потрібно проаналізувати, необхідно довантажувати те або інше зображення разом зі сторінкою. Я таким чином позбувся від пари десятків зайвих http запитів. Ті ж фонові картинки з складу шаблону, які все ж виявляться необхідними для функціонування вашого ресурсу, можна об’єднати в так звані CSS спрайт. В результаті, замість десятка запитів знадобиться зробити тільки один.
Взагалі, збільшення швидкості завантаження сайту неминуче призведе хоча б до невеликого, але зростання навантаження на хостинг, що при високій відвідуваності може стати останньою краплею. У мене зараз, при 5000 тисяч відвідувачів на добу, навантаження на процесор сервера наближається до гранично допустимої.
Я вже почав замислюватися про такий радикальний крок, як зробити свій блог практично статичним, в кореневій папці якого будуть лежати звичайні файли Html, а весь движок WordPress буде працювати в окремій папці. Таким чином навантаження буде зведена до мінімуму.
Реалізувати це в WordPress можна за допомогою чудо плагіна Really Static. Щоправда його версія ще не доросла до одинички, але відгуки про його роботи зустрічаються виключно позитивні. Фактично він є повним аналогом відомого скрипта Maxsite Cache, який, наприклад, використовує Михайло Шакін на своєму блозі.
Ціною за зниження навантаження стане втрата деякого функціоналу, але думаю, що правильними налаштуваннями оновлення кешу (в даному випадку він буде з себе представляти звичайні Html сторінки, як на сайтах початку цього тисячоліття) можна буде звести всі ці недоліки до мінімуму. У всякому разі у Шакіна я ніякого криміналу не помічаю, коли читаю його блог.
Якщо хтось вже має досвід роботи з WordPress плагіном Really Static, то буду дуже вдячний, якщо ви залишите свій відгук про нього в коментарях. Дякую за увагу. Стаття непомітно підійшла до кінця. Пора наводити на неї лиск і готувати до публікації.
Удачі вам! До зустрічей на сторінках блогу
