Що зумовлює час "очікування" до завантаження мого HTML?

У мене веб-сайт, здається, завантажується дуже повільно. Коли я запускаю тест на швидкість на ньому, я бачу, що перед завантаженням HTML, здається, існує 6-секундний розрив. Зображення та сценарії JS завантажуються дуже швидко після цієї точки.

Ви можете побачити на знімку під жовтими смужками "час очікування":

Це здається незмінним, незалежно від вмісту HTML-сторінки на сторінці.

Цей сайт використовує CMS (ModX Revo), тому HTML насправді зберігається в базі даних SQL і виводиться PHP, але я раніше цього не відчував.

Хто-небудь знав би, що це спричиняє, і як я міг би це прискорити?

Технічний термін очікування визначається як час першого байту і визначає чутливість веб-сервера або інших мережевих ресурсів.

Деякі найпоширеніші причини, по яких ви можете побачити час для першого байту:

• Перевантажена мережа (звичайно спільний хостинг)
• Помилкові сервери
• Відстань від вас і сервера (геолокація відіграє незначну роль)
• Помилки сервера (стрибки)

Як правило, ця проблема часто зустрічається в спільному хостингу через велику кількість веб-сайтів та відвідувачів, що, звичайно, збільшує час роботи в мережі. Іншою можливою причиною є помилка в мережі десь, як скачок, або через те, що ваш сервер знаходиться не в межах вашої цільової аудиторії, наприклад, "ДОБРИЙ" сервер у Великобританії матиме менший час байтів, ніж сервер США, орієнтований на користувачів у Великобританія, через відстань, яку потрібно надсилати та отримувати дані (як правило, збільшення становить близько 100-200 мс).

Можливо, час отримати нового господаря

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

Надійне тестування

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

Pinging і простежити маршрут на сервері

Якщо ви намагаєтеся запустити ping на сервері, результати можуть відображатись, а можуть і ні, ping використовує ICMP, а не UDP або TCP, тобто його не схоже на запит сервера на порт 80, на якому буде працювати ваш httpd. Ви можете використати маршрут трассирування для виявлення будь-яких серверів маршруту, що може спричинити збільшення першого байта, знову ж таки ... він не запитує сервер httpd на порту 80, а якщо traceroute за допомогою Windows він буде використовувати ICMP та Mac / Linux машини використовуватимуть UDP. Це варто тестувати, оскільки його така швидка і проста річ зробити, але якщо результати повертаються добре, це не означає, що десь немає проблем.

1) У вас є Adobe TypeKit, який не завантажується асинхронно з поточним кодом. Спробуйте замінити його на розширений асинхронний код: http://help.typekit.com/customer/portal/articles/649336-embed-code

Цей стандартний код вбудовування використовує той факт, що теги блокують подальше відображення сторінки, щоб запобігти FOUT [Flash of Unstyled Text]. Поки скрипт Typekit завантажується, візуалізація сторінки заблокована, тому текст не почне відображатися за допомогою резервних шрифтів.

2) Тест з новим TypeKit. Який зараз час завантаження? Краще? Перейдіть до кроку 3.

3) Замініть Google Analytics оновленим JavaScript, який містить найновіший асинхронний синтаксис: https://developers.google.com/analytics/devguides/collection/gajs/

4) Тест. Чи завантаження сторінки все ж краще?

5) Нарешті, розгляньте оптимізацію зображень, таких як pattern.jpg. Я перетворив його в PNG і зміг зменшити розмір файлу з 199 КБ до 56 КБ. Це скорочує час отримання файлу: https://www.dropbox.com/s/i06jx509bmprhhh/pattern.png?dl=0

Я сподіваюся, що це допомагає.

PHP проти елементів, які не є PHP

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

Зазвичай це вказує на внутрішні проблеми вашого сценарію PHP.

Проблема може бути в шарі PHP або в базі даних. Використання розширених інструментів налагодження, таких як XDebug або NewRelic, може допомогти вам швидко виявити вузьке місце.

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

У будь-якому випадку вирішення питання зазвичай означає одне або всі:

• Більше обладнання
• Краще програмування
• Додати кешування

Швидше обладнання - це очевидне, але часто дороге рішення, якщо ви вже використовуєте спеціальні ресурси.

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

Кешування допомагає зменшити кількість запитів, які повинні вражати основні, неякісні ресурси.

Тестування

При використанні інструментів тестування обов'язково виконайте кілька запусків. Мережеві та тимчасові шипи сервера можуть легко призвести вас до неправильного шляху, тому ви хочете спробувати оцінити їх середнє значення.

Хостинг

Якщо ви перебуваєте у спільному хостинговому обліковому записі, тоді варто розглянути можливість переходу до хмарних служб або VPS-сервісів, щоб мати кращу інформацію про продуктивність. Якщо ви не використовуєте техніку кешування (послуга типу CDN або Cloudflare), виправити проблеми продуктивності в системах масового спільного хостингу може бути дуже складно, оскільки вам не вистачає достатнього контролю над сервером.

Спробуйте встановити файли cookie третьої сторони лише для відвідуваних.