Co powoduje czas oczekiwania na załadowanie mojego HTMLa?

Mam witrynę, która wydaje się ładować bardzo powoli. Kiedy uruchamiam na nim test prędkości, widzę, że przed załadowaniem HTML wydaje się istnieć 6-sekundowa przerwa. Obrazy i skrypty JS ładują się bardzo szybko po tym punkcie.

Na zdjęciu poniżej żółte słupki „czasu oczekiwania”:

Wydaje się, że jest to spójne bez względu na treść HTML na stronie.

Ta strona korzysta z CMS (ModX Revo), więc HTML jest faktycznie przechowywany w bazie danych SQL i wywoływany przez PHP, ale nigdy wcześniej nie spotkałem się z tym problemem.

Czy ktoś wiedziałby, co to powoduje i jak mogę to przyspieszyć?

Termin techniczny oczekiwania jest określany jako czas do pierwszego bajtu i określa czas reakcji serwera WWW lub innych zasobów sieciowych.

Niektóre typowe powody, dla których warto zobaczyć pierwszy bajt:

• Przeciążona sieć (zwykle dzielony hosting)
• Błędna konfiguracja serwerów
• Odległość od ciebie i serwera (lokalizacja geograficzna odgrywa niewielką rolę)
• Błędy serwera (chmiel)

Zasadniczo ten problem jest często spotykany w hostingu współdzielonym z powodu dużej liczby stron internetowych i osób odwiedzających je, co oczywiście wydłuża czas bajtów sieci. Inną możliwą przyczyną jest błąd gdzieś w sieci, na przykład przeskok lub ponieważ twój serwer nie znajduje się w miejscu docelowej grupy odbiorców, na przykład serwer „DOBRY” w Wielkiej Brytanii będzie miał mniej bajtów niż serwer w USA kierujący reklamy do użytkowników w Wielka Brytania, ze względu na odległość, jaką dane muszą zostać wysłane i odebrane (zwykle wzrost o około 100-200 ms).

Może czas na nowego gospodarza

W przeszłości musiałem przenosić się z serwera na serwer ze względu na opóźnienie do pierwszego bajtu, możesz być w sytuacji, gdy będziesz musiał wybrać nowego hosta internetowego lub zaktualizować obecny pakiet.

Wiarygodne testowanie

Testowanie szybkości witryny z domowego łącza szerokopasmowego jest bardzo stronnicze, ponieważ może to być problem z brakiem odpowiedzi łącza internetowego na stronę internetową. Powinieneś przetestować swoją witrynę przy użyciu wielu połączeń z wielu serwerów ... Polecam test strony internetowej i przeprowadzenie wielu testów jednocześnie z różnych lokalizacji i wielu na docelowych odbiorcach geograficznych. Zapewni to lepszy przegląd tego, co się dzieje, jeśli to pierwszy bajt, zalecamy skontaktowanie się z hostem internetowym przed czymkolwiek innym.

Pingowanie i śledzenie trasy do serwera

Jeśli spróbujesz uruchomić polecenie ping na serwerze, wyniki mogą zostać wyświetlone lub nie, ping używa ICMP zamiast UDP lub TCP, co oznacza, że ​​nie przypomina odpytywania serwera na porcie 80, na którym będzie uruchomiony Twój httpd. Możesz użyć trasy śledzenia, aby zidentyfikować dowolne serwery na trasie, które mogą powodować wzrost pierwszego bajtu, ponownie ... to nie wysyła zapytania do serwera httpd na porcie 80, a jeśli traceroute używa systemu Windows, użyje ICMP i Mac / Linux maszyny będą korzystały z UDP. Warto przetestować, ponieważ jest to tak szybkie i łatwe do zrobienia, ale jeśli wyniki wrócą dobrze, nie musi to oznaczać, że gdzieś nie ma problemu.

1) Masz Adobe TypeKit, który nie ładuje się asynchronicznie z bieżącym kodem. Spróbuj zastąpić go zaawansowanym kodem asynchronicznym: http://help.typekit.com/customer/portal/articles/649336-embed-code

Ten standardowy kod osadzania wykorzystuje fakt, że tagi blokują dalsze renderowanie strony, aby zapobiec FOUT [Flashowi niestylonego tekstu]. Podczas ładowania skryptu Typekit renderowanie strony jest blokowane, więc tekst nie zacznie się renderować przy użyciu czcionek zastępczych.

2) Przetestuj z nowym TypeKit. Jaki jest teraz czas ładowania? Lepszy? Przejdź do kroku 3.

3) Zamień Google Analytics na zaktualizowany JavaScript, który zapewnia najnowszą składnię asynchroniczną: https://developers.google.com/analytics/devguides/collection/gajs/

4) Test. Czy ładowanie strony jest jeszcze lepsze?

5) Wreszcie rozważ optymalizację obrazów, takich jak pattern.jpg. Przekształciłem go do formatu PNG i mogłem zmniejszyć rozmiar pliku z 199 kB do 56 kB. Skraca to czas otrzymania pliku: https://www.dropbox.com/s/i06jx509bmprhhh/pattern.png?dl=0

Mam nadzieję, że to pomoże.

Elementy PHP a elementy inne niż PHP

Jeśli porównasz czasy ładowania zasobów innych niż PHP z czasami ładowania opartymi na PHP, zobaczysz, że serwer szybko reaguje, jeśli PHP nie jest zaangażowany.

Zazwyczaj oznacza to problemy wewnętrzne w skrypcie PHP.

Problem może dotyczyć warstwy PHP lub bazy danych. Korzystanie z zaawansowanych narzędzi do debugowania, takich jak XDebug lub NewRelic, może pomóc w szybkim wykryciu wąskiego gardła.

Problemy z czasem do pierwszego bajtu mogą wynikać z ograniczeń sprzętowych, złej konfiguracji lub nieefektywnego kodu. W przypadku hostingu współdzielonego najprawdopodobniej występują ograniczenia sprzętowe i zła konfiguracja.

W każdym razie rozwiązanie problemu oznacza zwykle jeden lub wszystkie z następujących elementów:

• Więcej sprzętu
• Lepsze programowanie
• Dodaj buforowanie

Szybszy sprzęt to oczywiste, ale często kosztowne rozwiązanie, jeśli masz już dedykowane zasoby.

Lepsze programowanie może nie być możliwe, jeśli problem dotyczy wewnętrznego kodu, którego nie utrzymujesz lub którego brakuje zasobów dla programistów.

Buforowanie pomaga, zmniejszając liczbę żądań, które muszą trafić do podstawowych, słabo działających zasobów.

Testowanie

Podczas korzystania z narzędzi testowych pamiętaj, aby wykonać wiele uruchomień. Skoki sieciowe i tymczasowe serwerów mogą łatwo poprowadzić cię złą ścieżką, więc chcesz spróbować je uśrednić.

Hosting

Jeśli korzystasz z wspólnego konta hostingowego, rozważ przejście na usługi w chmurze lub usługi VPS, aby mieć lepszy wgląd w problemy z wydajnością. O ile nie zastosujesz techniki buforowania (CDN lub usługa typu Cloudflare), poprawianie problemów z wydajnością w masowych współdzielonych systemach hostingowych może być bardzo trudne, ponieważ brakuje wystarczającej kontroli nad serwerem.

Spróbuj ustawić pliki cookie innych firm na tylko odwiedzane.