1. 1. HTTP-запити - зло
2. 2. Про плюси і мінуси кешування
3. 3. Фокуси з GZip
4. 4. JPEG, PNG, MP3 та інші абревіатури
5. 5. Подивіться на код
6. 6. О боже, дивіться, шапка!
7. 7. Перенаправлення і як його готувати
8. 8. Просто змініть сервер
9. 9. HTTP / 2 і епоха нового інтернету
10. Це скоріше рекомендації ...

Уявіть, що у вас є найкрасивіший сайт в світі - ну, не рахуючи галереї Мікіяко Кобаяші. Але тепер, коли ваш сайт нарешті тішить око, він завантажується повільніше, ніж YouTube по GPRS-з'єднання! І незважаючи на крутий дизайн, їм відверто неприємно користуватися.

Якщо це сталося - потрібно щось з цим робити. Тому що згідно з дослідженнями Amazon, Wallmart, Amakai і Aberdeen Group, чим швидше завантажується сайт - тим більше на ньому конверсій.

1. HTTP-запити - зло

Схема HTTP-запиту. Браузер запитує дані, сервер обробляє запит і відправляє потрібні дані.

Кожен раз, коли користувач завантажує ваш сайт, крім самої сторінки він завантажує і все медіафайли на ній (картинки, анімацію, аудіо і т.д.). Навіть якщо ці файли маленькі, для кожного з них на сервер відправляється запит, який потім потрібно ще обробити і відправити результат назад. Частина цієї проблеми можна вирішити використовуючи GZip-компресію і кешування файлів - і ми обговоримо ці рішення трохи нижче. Але спочатку, дайте відповідь на питання - навіщо вам взагалі всі ці файли?

І якщо у вас немає відповіді - тут і варто почати оптимізацію.

1. Приберіть непотрібні картинки. Навіть якщо ви - власник галереї, кількість повнорозмірних HD-зображень на сторінці повинно прагнути до одного. Використовуйте мініатюри всюди, де тільки можна. і використовуйте повнорозмірну картинку тільки коли вона домінує над іншим контентом.
2. Перенесіть всю просту графіку в CSS. Навіть якщо це збільшить обсяг файлу, який користувач завантажує при першому заході на сайт. CSS з вбудованою графікою знижує число запитів в майбутньому і в результаті прискорює завантаження в рази. Також, намагайтеся об'єднувати CSS, коли це можливо - за одним винятком, про який ми поговоримо пізніше.
3. Знизьте кількість скриптів. А якщо це неможливо - пересуньте їх вниз сторінки, щоб користувач міг спочатку завантажити хоча б все візуальні елементи і побачити, що на сторінці хоча б щось відбувається.

І якщо ви збираєтеся робити для вашого сайту нові сторінки в майбутньому - запам'ятайте ці правила. Краще відразу все зробити добре, ніж намагатися потім оптимізувати вже опубліковану сторінку.

2. Про плюси і мінуси кешування

Схема роботи HTTP-запиту з системою ETag. Браузер відправляє серверу останній відомий йому ETag зображення і завантажує його тільки якщо ETag сервера не збігається з ним.

Кеш - чудова штука. Він дозволяє браузерам завантажувати тільки ті частини сайту, які змінилися з останнього візиту. Ну, в ідеалі. На ділі, тільки ви вирішуєте, які частини сторінки повинні кешуватися і як довго буде зберігатися кеш. Надмірне кешування може навіть нашкодити роботі сайту, але в той же час, грамотне використання кеш-файлів допоможе знизити час завантаження сторінки на пару секунд.

Є кілька способів перевірки актуальності кеш-файлів. Кращий - ETag, який перевіряє наявність у користувача останньої версії файлу. Але це не оптимальний метод - він все одно включає в себе HTML-запит.

Схема роботи HTTP-запиту з параметром max-age. Браузер запитує дані тільки якщо вони старше, ніж дозволено сервером. В інших випадках, запит не надсилається взагалі.

Краще використовувати параметр max-age - він визначає як довго буде зберігатися кеш на комп'ютері користувача і не створює зайвих запитів. Тільки не варто ставити занадто високі значення - кеш займає місце на жорсткому диску ваших користувачів. Але і занадто низькі ставити не варто - втрачається сенс всієї цієї затії. Оптимальне рішення - 1 тиждень для повнорозмірних зображень і 1 рік для CSS, маленьких картинок і іншого. Але якщо ви плануєте змінювати ці елементи - тут вже варто використовувати eTags.

3. Фокуси з GZip

Схема роботи HTTP-запиту з включеним GZip. Кожен раз, коли браузер запитує нову сторінку, сервер стискає її перед відправкою, використовуючи GZIP.

Сучасний HTML - неоптимальний. Кожен тег має закриває аргумент, який виглядає майже точно так же. Тому, однакові комбінації символів повторюються по всьому HTML-документу. І до контенту це теж відноситься - найчастіше словник тексту набагато менше, ніж загальне число слів в ньому.

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

Всі комп'ютери, випущені в останні 15 років, можуть стискати в GZip на льоту - навіть якщо апаратної підтримки цього стандарту в них немає. Так що включити цю функцію на своєму сервері або хостингу потрібно обов'язково. Ви можете зробити це в cPanel або будь-який інший панелі управління.

А якщо у вас такої немає - вирушайте на wiki тієї серверної системи, яку ви використовуєте, і пошукайте GZip або HTTP Compression. Цю функцію точно підтримують IIS, Apache і NGINX. В Apache навіть є можливість попереднього стиснення, яка дозволяє знизити навантаження на сервер.

4. JPEG, PNG, MP3 та інші абревіатури

Порівняння між JPG і WEBM. Зауважте менший розмір файлу на правій картинці.

GZip - чудова штука для стиснення HTML, але, як ми вже говорили, вона не працює з медіа. Взагалі, вибір форматів для медіа - це дуже спірний момент. Тому що замість одного чарівного рішення, тут пропонується широкий набір компромісів.

Для зображень, дуже довгий час стандартом був JPEG. Не дуже гарне рішення, так як після стиснення на зображенні залишалися артефакти (спотворення). У той же час розмір файлів JPEG вкрай малий.

PNG - інший цікавий формат. Він залишає набагато менше артефактів і має кілька переваг перед JPEG - наприклад, підтримку прозорості. Але розмір файлів PNG дещо більше, ніж файлів JPEG - якраз за рахунок додаткових функцій.

Нарешті, в 2010 Google представив свій власний формат - WebP. Він покликаний замінити як PNG, так і JPEG. Результати у нього відмінні - як в плані розміру, так і в плані якості - але використовувати його на сайтах поки зарано. Хоча настільні комп'ютери в основному справляються з WebP навіть якщо у них немає його апаратної підтримки, неновим мобільних пристроїв може припасти туго. Хоча якщо у вас є окрема версія сайту для настільних ПК - WebP стане відмінним рішенням.

Відносно дозволу, то чим воно вище - тим краще результат. У той же час, розмір зображення зростає з ростом дозволу. Кращим вибором буде використання стандарту Retina - завантажуйте зображення в дозволі, яке в два рази вище, ніж те дозвіл, в якому їх будуть переглядати. Максимальний розмір - ~ 4000 точок в ширину, але тільки якщо це зображення - єдине повнорозмірне на цій сторінці. Також можна спробувати знизити глибину кольору зображень, особливо якщо вони прості. Але це не завжди себе виправдовує.

Нарешті, вивчіть HTML. Більш детально ми поговоримо про це в наступному розділі, але поки що переконайтеся, що ви заповнюєте теги img src. Якщо ви цього не робите - сторінка буде гальмувати або взагалі перестане завантажуватися.

5. Подивіться на код

HTML-код цієї сторінки, показаний в редакторі Sublime Text 3.

WYSIWYG-редактори - відмінний засіб розробки HTML. Серйозно, я навіть редагував цю статтю в одному з них, під назвою Remarkable. Але я буду першим, хто скаже - вони не ідеальні. Так, вони значно спрощують життя веб-дизайнера і навіть дозволяють тому, хто не знайомий з HTML, домагатися хороших результатів. Але той код, що вони видають, далекий від ідеалу. Або навіть від просто стандартів доброго коду.

Існують програми, які допоможуть вам оптимізувати такий код - PageSpeed ​​Insights for Chrome допоможе з HTML, CSS Compressor стане в нагоді при роботі з CSS, а Closure Compiler обов'язковий для JavaScript - але навіть їх результати далекі від коду хорошого програміста. Тому, хоча ви і повинні ними користуватися, варто також вкласти час і гроші в отримання хоч якогось досвіду веб-програмування. Повірте, це вам стане в нагоді.

ВАЖЛИВО: Навіть досвідчені веб-дизайнери часто забувають про вбудоване CSS. Точніше про те, що його взагалі не повинно бути. На то є причина - ця техніка повільніше, ніж зберігання всього CSS в одному зовнішньому файлі і запит потрібних частин при відображенні сторінки. До того ж, HTML-код без вбудованого CSS набагато простіше читати.

6. О боже, дивіться, шапка!

Ви не побачите нічого подібного на Unihost, але якби ми зіткнулися з подібною ситуацією, ми б вирішили її приблизно так.

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

Використовуючи другий (хоча, технічно, він буде першим) зовнішній CSS лист, який містить тільки шапку сторінки, ви зможете показати користувачеві, що принаймні на сторінці щось відбувається і потрібно просто трохи почекати, поки їх браузер обробить залишилася інформацію. Навіть якщо проблема зовсім не в браузері і це ваша сторінка, яка все ще передає мультимедійні дані.

Власне тут використовується той же принцип, що і завантаженням скриптів в останню чергу - нехай сторінкою ще й не можна користуватися, він виглядає завантаженою. І це вже краще, ніж зовсім нічого.

7. Перенаправлення і як його готувати

Приклад перенаправлення на мобільну версію сайту, налаштованого в панелі управління.

Як саме працює мобільна версія вашого сайту? Якщо ви використовуєте адаптивний CSS або динамічну систему, яка передає мобільним користувачам спеціальну версію сторінки - ви все правильно зробили. А ось якщо у вас є повністю окрема мобільна версія сайту, з іншими URL, на які налаштований перенаправлення з настільної версії - ви зробили велику помилку.

Кожне перенаправлення - це серія HTTP-запитів, які сильно уповільнюють завантаження сайту. На щастя, якщо ви вже використовуєте таке рішення, вам не доведеться переробляти весь сайт - хоча може і варто цим зайнятися, адже чуйний дизайн набагато краще. У будь-якому випадку, ви можете виправити ситуацію, що склалася з використанням Googlebot, який може налаштувати на вашому сайті куди більш ефективне HTTP-перенаправлення. Доведеться внести деякі зміни в код сторінки, але нічого особливо складного.

8. Просто змініть сервер

«Немає нічого неможливого», свідчить слоган Adidas. Але іноді це - не правда. Буває так, що ви вже використовуєте всі ресурси, а результат все одно не відповідає очікуванням. Я це зрозумів, коли незважаючи на всі зусилля, я так і не зміг оптимізувати сторінку під термін завантаження в три секунди. Тому апгрейд сервера, або навіть зміна хостингової компанії - це цілком адекватне рішення.

На щастя, в цій сфері до монополії далеко - існує безліч різних провайдерів, як старих і шанованих, так і молодих і готових йти на компроміс. З іншого боку, це означає, що підбір хорошого хостингу може зайняти час. Я врешті-решт зупинився на Unihost, але тут вже кожен вибирає по собі.

9. HTTP / 2 і епоха нового інтернету

Не так давно, публіці був представлений новий стандарт HTTP 2.0 (також відомий як HTTP / 2). І він вже краще попередника - навіть незважаючи на обов'язкове шифрування. HTTP-запити в новому протоколі були оптимізовані - так що велика частина світової вище в ньому просто не потрібна.

На жаль, багато хостинг-компанії і навіть деякі браузери ще не підтримують HTTP / 2. І до тих пір, поки ви не отримаєте можливість перейти на новий стандарт, вам доведеться оптимізувати ваш сайт для HTTP 1.1. Але для везунчиков, які мають як бажання, так і можливість перейти на новий стандарт - ми зробимо огляд HTTP / 2 на наступному тижні, а також опублікуємо список того, що варто змінити на своєму сайті під час переходу на цей протокол.

Це скоріше рекомендації ...

Чи не вважайте все вищеописане якимись одкровеннями веб-оптимізації. Це не було завданням статті і, якщо чесно, мені не вистачить знань і досвіду для того, щоб написати щось подібне. Наприклад, я сам бачив рішення, які йдуть всупереч моїм радам і при цьому цілком собі працюють.

Але якщо ви взагалі не знайомі з веб-оптимізацією - сподіваюся, я хоча б трохи вам допоміг.