- аналіз TTFB
- оптимізація Nginx
- з'єднання
- запити
- буфери
- Таймаут і keepalive
- кешування
- Логування
- стиснення Gzip
- Оптимізація PHP: FastCGI в Nginx
- Найважливіше
У широкому сенсі, TTFB - це метрика, яка показує час до отримання першого байта (мережевого пакету) веб-сторінки після відправлення запиту з боку клієнта. 
Вимірювання включає запит DNS, час з'єднатися з сервером та час очікування обробленого запиту (обробка, перепакування, відправка сторінки). Цікаво, що термін часто плутають c часом відгуку сервера - цей показник дає можливість оцінити швидкість реакції на HTTP-запит за відсутності мережевої затримки. На TTFB впливає майже все: мережеві проблеми і затримки, обсяг вхідного трафіку, налаштування веб-сервера, обсяг і оптимизирования контенту ( якість графіки , розмір css / js / html ).
Очевидно, що не на всі перераховані вище моменти легко вплинути. У вас навряд чи буде можливість самостійно поліпшити якість мережі, а високий трафік на веб-сайт може бути чимось поганим тільки в разі DDoS-атак. Єдине, на що реально вплинути - бекенд, так що займемося тюнінгом Nginx.
аналіз TTFB
На просторах Всесвітньої павутини розміщено велику кількість ресурсів, присвячених перевірці швидкості завантаження веб-сторінок. Один з найпопулярніших і шанованих - WebPageTest.org .
Він надає більш, ніж вичерпну інформацію про час підключення, TTFB, часу ініціалізації TLS / SSL (Якщо використовується), а також про завантаження окремих елементів веб-сторінки.
Для перевірки швидкості завантаження і цілої стопки додаткових параметрів можна використовувати браузер. І в Chrome, і в FireFox, і навіть в Safari присутні відповідні утиліти розробника.
оптимізація Nginx
Оптимальні настройки Nginx представлені в цієї статті. Ще раз коротко пройдемося по вже відомим параметрам і додамо кілька нових, які безпосередньо впливають на TTFB.
з'єднання
Для початку необхідно визначити, скільки "працівників" Nginx. 
Кожен робочий процес здатний обробляти безліч з'єднань і прив'язується до фізичних ядер процесора. Якщо ви точно знаєте, скільки ядер в вашому сервері, то можна задати їх кількість самостійно, або довіритися Nginx:
worker_processes auto;
Крім цього необхідно задати кількість з'єднань:
worker_connections 1024;
запити
Щоб веб-сервер міг обробляти максимальну кількість запитів, необхідно задіяти вимкненому за замовчуванням директиву multi_accept:
multi_accept on;
Примітно, що функція буде корисна тільки за умови великої кількості запитів одночасно. Якщо ж запитів не так багато, має сенс оптимізувати робочі процеси, щоб вони не працювали вхолосту:
accept_mutex on;
Поліпшення TTFB і часу відгуку сервера безпосередньо залежить від директив tcp_nodelay і tcp_nopush:
tcp_nodelay on; tcp_nopush on;
Якщо не надто вдаватися в подробиці, то обидві функції дозволяють відключити деякі особливості TCP, які були актуальні в 90х, коли Інтернет тільки набирав обертів, але не мають сенсу в сучасних умовах. Перша директива відправляє дані, як тільки вони будуть доступні (обходить алгоритм Нейгла). А друга дає можливість відправляти заголовок відповіді (веб-сторінки) і початок файлу, чекаючи заповнення пакета (тобто, включає tcp_cork). Так що браузер зможе почати відображення веб-сторінки раніше.
На перший погляд, функції суперечать один одному. Тому директива tcp_nopush повинна використовуватися разом з sendfile. В цьому випадку пакети будуть заповнені до відправки, тому що директива працює набагато швидше і оптимальніше, ніж метод read + write. Після того, як пакет заповнений, Nginx автоматично відключає tcp_nopush, а tcp_nodelay змушує сокет відправити дані. Включити sendfile дуже просто:
sendfile on;
Так що комбінація всіх трьох директив знижує навантаження на мережу і прискорює передачу файлів.
буфери
Ще одна важлива оптимізація зачіпає розмір буферів - якщо вони занадто маленькі, Nginx буде часто звертатися до дисків, занадто великі - швидко заповниться оперативна пам'ять. 
Для цього буде потрібно налаштувати чотири директиви. client_body_buffer_size і client_header_buffer_size задають розмір буфера для читання тіла і заголовка запиту клієнта відповідно. client_max_body_size задає максимальний розмір запиту клієнта, а large_client_header_buffers задає максимальне число і розмір буферів для читання великих заголовків запитів.
Оптимальні параметри буферів будуть виглядати так:
client_body_buffer_size 10K; client_header_buffer_size 1k; client_max_body_size 8m; large_client_header_buffers 2 1k;
Таймаут і keepalive
Правильна настройка часу очікування та keepalive також може істотно підвищити чуйність сервера.
Директиви client_body_timeout і client_header_timeout задають час очікування на читання тіла і заголовка запиту:
client_body_timeout 10; client_header_timeout 10;
При цьому в разі відсутності відповіді від клієнта за допомогою reset_timedout_connection можна вказати Nginx відключати такі сполуки:
reset_timedout_connection on;
Директива keepalive_timeout задає час очікування, перш ніж припинити з'єднання, а keepalive_requests обмежує кількість keepalive-запитів від одного клієнта:
keepalive_timeout 30; keepalive_requests 100;
Ну а send_timeout задає час очікування при передачі відповіді між двома операціями запису:
send_timeout 2;
кешування
Включення кешування істотно поліпшить час відгуку сервера. 
Методи більш детально викладені в матеріалі про кешуванні з Nginx, але в даному випадку актуально включення cache-control . Nginx здатний відправляти запит на кешування редкоізменяемих даних, які часто використовуються, на стороні клієнта. Для цього в секцію server потрібно додати рядок:
location ~ *. (jpg | jpeg | png | gif | ico | css | js) $ {expires 365d;}
Також не завадить закешовану інформацію про часто використовуваних файлах:
open_file_cache max = 10000 inactive = 20s; open_file_cache_valid 30s; open_file_cache_min_uses 2; open_file_cache_errors on;
open_file_cache задає максимальну кількість файлів, інформація про яких буде зберігатися, і час зберігання. open_file_cache_valid задає час, після якого потрібно перевірити актуальність інформації, open_file_cache_min_uses визначає мінімальну кількість звернень до файлу з боку клієнтів, а open_file_cache_errors включає кешування помилок пошуку файлів.
Логування
Це ще одна функція, яка може незначно знизити продуктивність всього сервера і, відповідно, час відгуку і TTFB. Так що кращим рішенням буде відключити основний лог, а зберігати інформацію тільки про критичні помилки:
access_log off; error_log /var/log/nginx/error.log crit;
стиснення Gzip
корисність Gzip складно перебільшити. Стиснення дозволяє значно зменшити трафік і розвантажити канал. Але у нього є і зворотна сторона - для компресії потрібен час. Так що для поліпшення TTFB і часу відгуку сервера його доведеться відключити. 
На даному етапі ми не можемо рекомендувати відключення Gzip, так як стиснення покращує Time To Last Byte, тобто, час, необхідний для повного завантаження сторінки. А це в більшості випадків більш важливий параметр. На поліпшення TTFB і часу відгуку сервера істотно вплине масштабне впровадження HTTP / 2 , Який містить вбудовані методи компресії заголовків і мультиплексування. Так що в майбутньому, можливо, відключення Gzip буде не таким помітним, як зараз.
Оптимізація PHP: FastCGI в Nginx
Всі сучасні сайти використовують серверні технології. PHP, наприклад, який також важливо оптимізувати . Зазвичай PHP відкриває файл, перевіряє і компілює код, потім виконує. Таких файлів і процесів може бути безліч, тому PHP вміє кешувати результат для редкоізменяемих файлів за допомогою модуля OPcache. А Nginx, підключений до PHP за допомогою модуля FastCGI, може зберігати результат виконання скрипта PHP для моментальної написати листа користувачу.
Найважливіше
Оптимізація ресурсів і правильні настройки веб-сервера - основні впливають на TTFB і час відгуку сервера чинники. Також не варто забувати про регулярні оновлення ПЗ до стабільних версій, які несуть оптимізації та підвищення продуктивності.
