Від автора: недавно працював над Google AMP (Accelerated Mobile Pages) проектом, з допомогою якого можна спустити роздуті сайти з верхніх результатів в google в мобільному індексі. Особисто я вважаю, що AMP нічого доброго не несе, але це вже не відноситься до статті. Суть статті у тому, що ви можете поліпшити UX, просто створивши швидкий сайт, і вам для цього не потрібно вдаватися до AMP. Але якщо ви все ж хочете, то методи в цьому пості допоможуть потрапити вашим сторінок у AMP з мінімальними зусиллями.
Front end сайту, який ви зараз читаєте, я створив в генераторі статичних сайтів Middleman, і зараз він зберігається на Digital Ocean Droplet на сервер Nginx. Я покажу декілька прикладів того, як зробити сайт найшвидше, і як особисто я досяг ідеальних показників у цьому блозі і з цим стеком технологій.
Google Insights PageSpeed
Google PageSpeed Insights – інструмент google для оцінки швидкості сайту за метричними даними:
Відсутність редиректів на лендінгем пейдж
Відсутність блокуючого рендер JS і CSS у видимій області вмісту
Активація стиснення
Використання кешу в браузері
Минификация CSS
Минификация HTML
Минификация JS
Оптимізація зображень
Пріоритет мабуть контенту
Зниження часу відповіді від сервера
Мені потрібен швидкий сайт, і я люблю вичавлювати 100%, тому я вирішив отримати 100/100 для сайту elliotec.com. І я отримав. Зараз я розповім вам, як я це зробив.
Розмір сторінки
Перш ніж розбирати правила, давайте поговоримо про розмір сторінки в цілому. Зменшіть код. Якщо вам не потрібен весь код Bootstrap, загружающийся на всіх сторінках, використовуйте щось легше. Якщо вам не потрібна купа JS на сторінці, як в блозі, тоді не вставляйте його. Пара дрібних забавних анімацій на шкоду сотням мілісекунд найчастіше не варто того. Якщо ж бренд або вимоги ставлять вас в положення, коли важкий JS необхідний, існують стратегії, за допомогою яких можна підтримувати маленька вага і швидкість.
Контроль клієнта і сервера
Щоб вибити 100/100 вам потрібен прямий контроль елементів front end і інструментів, які збирають сторінки. Щоб максимально підвищити продуктивність, цей сайт я створив за допомогою генератора статичних сайтів Middleman зі своїми настройками. На цьому сайті практично немає JS (крім плагіна Squaresend для email), але якщо б мені він був необхідний, я б обробив його, як і інші файли. За посиланням ви знайдете повний конфіг Middleman config.rb.
Крім цього вам необхідний повний контроль над хостингом файлів. Для повного контролю своїх серверів я використовую Nginx на Digital Ocean. Так як мої файли статичні, мені не потрібно налаштовувати базу даних або backend, за винятком Nginx, де проходить більша частина роботи.
Розбір метрик
Давайте розберемо все по поличках.
Відсутність редиректів на лендінгем пейдж
Перший пункт говорить сам за себе. Ви не хочете потрапити на сторінку і постійно редиректиться. Найчастіше десктоп сайти перенаправляють користувачів на мобільну версію сайту, і це вкрай витратним з точки зору продуктивності. Якщо є можливість, робіть сайт підходу mobile-first і адаптивним, щоб запобігти необхідність редиректів на мобільні версії.
Активація стиснення
Тут вже потрібен контроль сервера. Http підтримує відправку стислих файлів по мережі для прискорення передачі, тому варто стискати все, що можна перед відправкою в браузер. З Nginx і Middleman активувати стиснення дуже просто. Глобальний файл nginx2.conf:
#nginx2.conf
http {
sendfile on;
types_hash_max_size 2048;
server_names_hash_bucket_size 128;
include /etc/nginx/mime.types;
default_type application/octet-stream;
gzip on;
gzip_disable “msie6”;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_min_length 256;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript application/x-font-ttf font/opentype image/svg+xml image/x-icon;
}
І конфіг Middleman:
# config.rb
configure :build do
activate :gzip
end
Використання кешу в браузері
Кешування дозволяє браузерам зберігати завантажені файли деякий час, щоб не завантажувати їх знову і знову. В Nginx це зробити легко. Для цього необхідно встановити час старіння типів файлів, як у мене в локальному файлі nginx2.conf:
#expiry map
map $sent_http_content_type $expires {
default off;
text/html epoch;
text/css max;
application/javascript max;
application/x-font-ttf max;
application/x-font-otf max;
application/font-woff max;
application/font-woff2 max;
~image/ max;
}
server {
listen 80;
listen [::]:80;
server_name elliotec.com www.elliotec.com;
expires $expires;
return 301 https://$server_name$request_uri;
}
Також можна кешувати тільки ті файли, які не змінилися. Для цього необхідно встановити унікальні хеши для файлів, що можна зробити в Middleman:
# config.rb
configure :build do
activate :asset_hash
end
Минификация файлів
Минификация файлів – одна з добре відомих стратегій по простому прискоренню сторінок. У сучасній веб-розробки дуже важливий етап минификации HTML, CSS і JavaScript, але цей крок часто пропускають. Минификация може значно знизити розмір пакету. У Middleman вам необхідно лише вставити кілька рядків у config.rb:
# config.rb
configure :build do
activate :minify_css
activate :minify_javascript
activate :minify_html
end
CSS і JS минификация в Middleman безкоштовна, але для HTML необхідно додати gem middleman-minify-html, і ви його точно захочете отримати, хоч він і не дає такого приросту, як інші файли.
Оптимізація зображень
Найчастіше зображення найважчі файли для браузера з точки зору розміру і швидкості завантаження. У цій області можна отримати найбільший приріст продуктивності. Для початку вам необхідно привести зображення до мінімально можливих розмірів з гарною якістю. В інструментах типу Photoshop є необхідні можливості, але зображення можна ще більше оптимізувати за допомогою інструментів типу imageoptim. Звичайно, зробити це в Middleman досить легко. Спершу необхідно додати ‘middleman-imageoptim’, git: ‘https://github.com/plasticine/middleman-imageoptim’, branch: ‘master’:
# config.rb
configure :build do
activate :imageoptim
end
Відмінно, ви тільки що зрізали більшу частину ваги тих величезних зображень.
Зменшення часу відповіді від сервера
У google досить строгий поріг прийнятного часу відповіді від сервера – він повинен бути менше 200ms. Для статичних сайтів цього типу це взагалі не проблема. Якщо б я хостил десяток серверних блоків на одному Digital Ocean Води, вони боролися б за ресурси і сповільнювали спільну роботу, тому не рекомендую так робити. Якщо на вашому backend варто база даних, надсилаються запити і т. д., існує маса причин, чому сервер може виходити за межі 200ms, і ви, звичайно ж, витратите час, з’ясовуючи це.
Пріоритет мабуть контенту
Пріоритет мабуть контенту означає, що контент видимій частині сторінки повинен бути досить малий за розмірами, щоб не вимагати додаткових запитів на сервер для рендера. Зробити це можна затримкою завантаження сторонніх скриптів, а також підтриманням загального маленького ваги першої видимої частини контенту. З цим завданням можуть допомогти інші пункти, але іноді реально складно довести це до ідеалу, особливо якщо зображення є первинним видимим контентом.
Відсутність блокуючого рендер JS і CSS у видимій області вмісту
Найскладніший пункт списку, і він пов’язаний з попереднім. Цей пункт я реалізовував за кілька стратегій. Якщо ви підключаєте сторонній JS або додаєте атрибут async до всіх тегам script, то зовнішні JS файли не будуть блокувати завантаження і рендер іншого контенту, вони будуть завантажуватися асинхронно.
Перенесіть CSS і JS в інлайн, щоб не робити запит на зовнішні ресурси. Робити це вручну буде незручно і негарно, для цього є спеціальні інструменти. Для перенесення файлів в інлайн необхідно виконати кілька кроків.
Спершу необхідно додати зірочки (gem ‘middleman-sprockets’) в додаток, так як ми будемо красти пайплайн файлів Middleman
Потім у config.rb додайте inline: true кожен крок минификации:
# config.rb
configure :build do
activate :minify_css, inline: true
activate :minify_javascript, inline: true
end
Шаблон макета, там де ви підключаєте CSS (де тег head):
І аналогічно для скриптів для тегів script.
Складності у мене викликав скрипт Google Analytics, я довго бився з ним, щоб він не блокував рендер. Це був останній пункт зі списку, який я тоді ще не зробив, і мене дратувало, що у мене не 100/100. Моя мета була саме в цифрах, хоча мій сайт вже був дуже швидким, і я знайшов hack online, за допомогою якого обдурив Page Speed Insights і змусив його ігнорувати скрипт Google Analytics. Якщо вони можуть суперечити собі, я думаю, я маю право так чинити, і ви теж!
if(navigator.userAgent.indexOf(“Speed Insights”) == -1) {
// Your Google Analytics Code Here
}
Готово!
От і все. Якщо ви слідували інструкціям з цього поста для свого статичного сайту, то ви отримаєте 100/100 на Google Page Speed. Важлива лише швидкість, і це плюс для всіх, хто користується сайтом. А ще це добре для SEO, так адже?
