- Przyspiesz generowanie strony serwera
- Popraw wszystkie błędy w „System Checker”
- Optymalizacja ustawień serwera WWW (apache, nginx, php-fpm)
- Optymalizacja ustawień MySQL (lub innych DBMS)
- Słaby serwer / hosting
- Odwołuje się do API innych firm (usługi / zasoby) w kodzie php
- Suboptymalne (ciężkie) zapytania do bazy danych
- Nieoptymalna logika kodu php
- Rozszerzone tabele w bazie danych
- Zamknij lub nieprawidłowo działa system buforowania
- Witryna kompozytowa
- Przyspiesz ładowanie stron w przeglądarce
- Optymalizacja obrazu
- Buforowanie plików statycznych po stronie serwera (obrazy, css, js)
- Usuń wszystkie przekierowania i nieistniejące zasoby.
- Wyłącz niepotrzebne skrypty i widżety
- Łączenie css i js
- Kompresja (minifikacja) js i css
- Zmniejszenie liczby zasobów stron trzecich
- Tłumaczymy stronę na protokół HTTP / 2
Często klienci przychodzą do nas z tym samym problemem - Bitrix zwalnia.
W rzeczywistości sam rdzeń (silnik) w nowoczesnych wersjach Bitrix nie zwalnia.
Hamulce zaczynają się, gdy w witrynie używana jest złożona lub nieoptymalna logika, gdy witryna jest duża i złożona, gdy na stronach witryny jest używana dużo nieoptymalnej logiki javascript itp.
Zazwyczaj utrudniają to raczej stare witryny, które są rozwijane / rozwijane od lat, komplikując i komplikując ich logikę i zwiększając zakres produktów.
A kiedy stajemy przed zadaniem przyspieszenia działania takich witryn, przede wszystkim analizujemy serwer i kod strony, aby znaleźć wąskie gardła wydajności. A jeśli jest to prostsze, to problemy, które uniemożliwiają szybkie działanie witryny.
Prędkość ładowania strony składa się z dwóch głównych części:
Szybkość generowania strony html na serwerze.
Szybkość pobierania wszystkich zasobów w przeglądarce (strona html, wszystkie css, javascript, obrazy, wideo itp.).
Dlatego praca nad przyspieszeniem witryny (lub poszczególnych stron) musi być wykonywana w obu kierunkach - przyspieszenie zaplecza (szybkość generowania strony na serwerze) i przyspieszenie frontendu (prędkość pobierania w przeglądarce).
Poniżej znajdują się główne zalecenia dotyczące zwiększenia szybkości Bitrix, a także typowe problemy, które spowalniają witrynę.
Przyspiesz generowanie strony serwera
Największym problemem jest powolne generowanie stron html na serwerze. Powolny - zwykle jest dłuższy niż 0,3 sekundy.
Z tym problemem wynika, że szybkość Bitrixa (samego silnika) jest bardzo niska - nawet strony administracyjne mogą zwolnić.
Aby przyspieszyć generowanie określonej strony na serwerze, należy przeanalizować logikę jej generowania i znaleźć nieoptymalną logikę (wąskie gardła) lub błędy programisty. Może to pomóc narzędziom takim jak xdebug lub narzędzia wbudowane w CMS / framework, na którym działa Twoja witryna. Na przykład w Bitrix znajduje się narzędzie „Debugowanie” w panelu administracyjnym w publicznej części witryny.
Ponadto wszystkie przykłady zostaną podane na stronie na Bitrix.
Typowe problemy, które mogą utrudniać generowanie stron po stronie serwera, są wymienione poniżej.
Popraw wszystkie błędy w „System Checker”
Przede wszystkim należy uruchomić „System Check” w panelu administracyjnym Bitrix i naprawić wszystkie wykryte problemy.
Są to najważniejsze błędy, które zasadniczo wpływają na działanie witryny.
Zazwyczaj są one związane z nieprawidłowymi ustawieniami serwera / hostingu.
Jeśli przynajmniej jeden problem występuje przy sprawdzaniu systemu, strona może działać niestabilnie - nawet w najbardziej nieprzewidzianych i nieoczywistych miejscach.
Ustawienia> Narzędzia> Kontrola systemu
Optymalizacja ustawień serwera WWW (apache, nginx, php-fpm)
Często standardowa konfiguracja zespołu serwera WWW jest nieoptymalna.
Dlatego zaleca się analizę stanu i konfiguracji serwera WWW oraz optymalizację ustawień serwera na podstawie przeprowadzonego audytu.
Nasi eksperci są gotowi w tym pomóc.
Oprócz tego konieczne jest zapoznanie się z zaleceniami Bitrix w panelu administracyjnym w celu optymalizacji ustawień PHP.
Ustawienia> Wydajność> PHP
Optymalizacja ustawień MySQL (lub innych DBMS)
Podobnie jak w przypadku optymalizacji serwera WWW, zaleca się optymalizację ustawień bazy danych.
A także porównaj bieżące ustawienia z zaleceniami w admin Bitrix.
Ustawienia> Wydajność> Serwer bazy danych
Słaby serwer / hosting
Jak zrozumieć, że potrzebujesz mocniejszego serwera / hostingu?
Monitor wydajności serwera w panelu administracyjnym Bitrix daje wartość mniejszą niż 30, mimo że administratorzy (lub obsługa hostów) twierdzą, że serwer jest optymalnie skonfigurowany (a dane z panelu administracyjnego Bitrix nie powodują problemów z nieoptymalnymi ustawieniami php lub mysql).
Uwaga! Szkoda, że „średni czas odpowiedzi” może znacząco obniżyć ogólną liczbę konfiguracji. Jeśli ten element daje zbyt dużą figurę, musisz przeanalizować logikę generowania strony głównej i zapewnić jej szybki powrót przez serwer.
Jeśli więc pomimo wszystkich optymalizacji serwerów wskaźnik monitora wydajności jest mały, zalecamy przejście na bardziej wydajny i zoptymalizowany hosting / serwer.
Możesz wybrać wydajny serwer w przystępnej cenie. z nami .
Odwołuje się do API innych firm (usługi / zasoby) w kodzie php
Często proces generowania stron uniemożliwia dostęp do usług stron trzecich w kodzie php.
Na przykład mogą to być usługi określania miasta, obliczania kosztów dostawy itp.
Aby zrozumieć, jak naprawić - musisz dowiedzieć się, dlaczego zwalnia.
Możliwe, że nieoptymalny (niepoprawnie) interfejs API korzysta z interfejsu API usług innej firmy i istnieją bardziej optymalne sposoby korzystania z niego. Być może sam interfejs API usług jest bardzo wolny.
W takich przypadkach logiczne jest komunikowanie się ze wsparciem usługi, poproszenie ich o przyspieszenie pracy API i udzielenie zaleceń dotyczących bardziej optymalnego wykorzystania Twojej sprawy.
Jeśli nie można zoptymalizować korzystania z bieżącej usługi, należy pomyśleć o przełączeniu na alternatywne usługi i interfejsy API (lub o buforowaniu pracy bieżącego interfejsu API).
Suboptymalne (ciężkie) zapytania do bazy danych
Często powodem długiego generowania stron na serwerze są ciężkie zapytania SQL.
W takim przypadku istnieją co najmniej 2 opcje przyspieszenia:
Zoptymalizuj samo zapytanie. Utwórz brakujące indeksy, wyklucz niepotrzebne pola z zaznaczenia, podzapytania, obliczenia.
Żądaj buforowania Aby upewnić się, że to samo ciężkie zapytanie nie ma dostępu do bazy danych przy każdym obciążeniu, wyniki próbki mogą zostać zapisane (w pamięci, w pliku lub nawet w samej bazie danych). Dowiedz się więcej o buforowaniu w Bitrix .
Nieoptymalna logika kodu php
Nawet jeśli kod php nie ma dostępu do bazy danych lub zasobów innych firm, kod taki może zwolnić.
Przyczyną tego może być nieoptymalna logika kodu - próbka z dużych tablic, nieskończone (lub prawie nieskończone) pętle, praca z dużymi plikami danych itp.
W takim przypadku należy zidentyfikować takie problematyczne bloki kodu i przepisać ten kod na bardziej optymalny (szybki) lub można buforować wyniki ciężkiej logiki (podobnie jak w przypadku zapytań do bazy danych).
Rozszerzone tabele w bazie danych
Jeśli tabele w bazie danych są zapchane niepotrzebnymi (przestarzałymi) danymi, to nie tylko blokuje dysk na serwerze, ale także spowalnia całą pracę z bazą danych - wszystkie zapytania do bazy danych zaczynają zwalniać.
Często są to różne dzienniki, dzienniki, duplikaty produktów i inne tabele systemowe.
Aby wyświetlić wszystkie arkusze kalkulacyjne, przejdź do panelu administracyjnego w sekcji:
Ustawienia> Wydajność> Tabele
I posortuj wszystkie tabele w kolejności malejącej wielkości.
Jeśli rozmiar tabeli jest większy niż 500 MB, możesz najprawdopodobniej powiedzieć, że w tej tabeli są niepotrzebne (przestarzałe) dane, które można usunąć.
W niektórych przypadkach krytyczny jest znacznie mniejszy rozmiar stołu.
W rezultacie oczyszczenie tak rozłożonych tabel przyspieszy bazę danych.
Zamknij lub nieprawidłowo działa system buforowania
Bitrix ma dość dobry system buforowania.
Ale podczas tworzenia strony początkowo można pominąć kwestię korzystania z typowego buforowania.
Dlatego analizując powolne generowanie stron na serwerze, należy zwrócić szczególną uwagę na identyfikację tych bloków kodu (komponentów), w których typowe buforowanie Bitrix nie jest używane. Debugowanie w górnym panelu Administratora w publicznej części witryny pomoże zidentyfikować takie problemy.
W niektórych przypadkach typowy mechanizm automatycznego buforowania Bitrix zaczyna działać nieoptymalnie. Na przykład, jeśli pełne rozładowanie towarów jest często wykonywane z 1C, to automatyczne buforowanie zaczyna stale generować pamięć podręczną. Z każdą wymianą stara pamięć podręczna całego katalogu staje się przestarzała. Dlatego strony katalogu produktów zaczynają działać bardzo powoli (w 90% przypadków pamięć podręczna produktu jest przestarzała). W takim przypadku musisz albo odejść od częstego całkowitego rozładunku towarów z 1C, albo zmodyfikować logikę buforowania Bitrixa.
Witryna kompozytowa
Po usunięciu wszystkich oczywistych problemów (opisanych powyżej) sensowne jest połączenie technologii witryny złożonej (lub równoważnej).
Przyspiesz ładowanie stron w przeglądarce
Wiele ważnych kryteriów wpływających na szybkość ładowania stron w przeglądarce jest gromadzonych w narzędziu Google PageSpeed Insights. Ale są też inne problemy / pomysły, które wpływają na czas ładowania w przeglądarce.
Optymalizacja obrazu
Dobre przyspieszenie uzyskuje się przez kompresowanie (optymalizację) obrazów. Rzecz w tym, że bardzo duża część wszystkich danych pobieranych na stronie witryny to obrazy.
Istotą algorytmów kompresji jest połączenie podobnych kolorów i usunięcie różnych informacji o usłudze z pliku (komentarze, współrzędne GPS, model kamery itp.).
OptiPic - Najłatwiejsze i najbardziej skuteczne narzędzie do optymalizacji obrazów. Pozwala automatycznie znaleźć i zoptymalizować wszystkie obrazy na stronie.
Buforowanie plików statycznych po stronie serwera (obrazy, css, js)
Po stronie serwera należy skonfigurować zwracanie plików statycznych z buforowaniem. Nie spowoduje to ponownego załadowania wszystkich zasobów statycznych podczas ponownego ładowania strony lub otwarcia innej strony witryny, która używa tych samych zasobów (jpeg, png, css, js itp.).
Jeśli korzystasz z wirtualnego hostingu, poproś obsługę hostingu o skonfigurowanie buforowania statycznych zasobów w witrynie (obrazy, wideo, css, js). Można to zinterpretować jako pominięcie wirtualnego hostingu, jeśli początkowo nie wdrożyli takiego buforowania. Dlatego w większości przypadków wsparcie techniczne spełnia wymagania i wykonuje niezbędną konfigurację za darmo.
Jeśli masz problem z tym ustawieniem, korzystasz z wirtualnego lub dedykowanego serwera - nasi eksperci są gotowi Ci pomóc.
Usuń wszystkie przekierowania i nieistniejące zasoby.
Często, podczas życia witryny, coraz więcej nowych zasobów jest podłączanych do stron (obrazów, plików javascript, plików css). Niektóre z nich są następnie usuwane jako niepotrzebne - ale zapomnij usunąć ich połączenie ze strony. Niektóre z nich są przenoszone - dla uproszczenia przekierowanie jest konfigurowane od starego adresu do nowego (aby nie nadpisywać adresu URL do nowych adresów na wszystkich stronach).
W wyniku tego na stronach pojawiają się zasoby, które podczas próby ich załadowania dają 404 odpowiedzi (zasób nie istnieje), a także 301 lub 302 odpowiedzi (zasób jest przenoszony tymczasowo lub na stałe).
Wszystkie te sytuacje, przeglądarki muszą sobie poradzić, wydając na ten cenny czas ładowania strony.
Poprawienie wszystkich odpowiedzi 4xx, 3xx daje dodatkową zaletę w szybkości ładowania i renderowania stron przez przeglądarkę.
Wyłącz niepotrzebne skrypty i widżety
Konieczne jest dokładne określenie potrzeby korzystania z określonych widżetów, usług i bibliotek opartych na javascript.
Przede wszystkim musisz pozbyć się połączenia tych zasobów, które nie są w ogóle używane w witrynie.
Następnie musisz przeanalizować potrzebę połączenia tego samego i tych zasobów na wszystkich stronach witryny. Na przykład, jeśli widżet witryny lubi w sieciach społecznościowych, jest wyświetlany tylko na szczegółowych stronach produktu (a na innych stronach jest ukryty), nie ma sensu łączyć tego widgetu na wszystkich stronach - łączenie dodatkowych zasobów na stronie spowalnia ładowanie strony. Dlatego lepiej jest połączyć ten widget tylko ze szczegółowymi stronami produktów. W pozostałej części strony wykluczyć połączenie widgetu.
Ponadto zdarzają się przypadki, że ten sam zasób łączy się kilka razy ze stroną. Na przykład ta sama biblioteka jest używana w różnych częściach strony. Bloki te zostały opracowane w różnym czasie przez różnych programistów. W rezultacie ta sama biblioteka jest połączona (prawdopodobnie różne wersje tej samej biblioteki).
Te przypadki również muszą zostać wykluczone - pozostawiając tylko jedną wersję biblioteki podłączonej.
Łączenie css i js
Wszystkie używane pliki css można połączyć w jeden plik. Podobnie z javascript. Pobieranie scalonych wersji jest znacznie szybsze niż ładowanie wszystkich zasobów bez scalania. I często działa dobrze podczas korzystania z HTTP / 2.
W tym celu w jądrze Bitrix są specjalne ustawienia. To jest w ustawieniach modułu głównego.
Ustawienia> Ustawienia produktu> Ustawienia modułu> Moduł główny
I wszystko wydaje się bardzo proste. Ale faktem jest, że tylko te js i css, które są połączone z witryną za pomocą API Bitrix, są połączone.
Dla js, metodą CMain :: AddHeadScript () . Dla css - CMain :: SetAdditionalCSS () .
W jądrze D7 używane są Asset :: getInstance () -> addCss () i Asset :: getInstance () -> addJs ().
Musisz więc upewnić się, że wszystkie zasoby są połączone za pośrednictwem interfejsu API.
Aby to zrobić, musisz włączyć opcje w ustawieniach i zobaczyć, które css / js nie zostały jeszcze scalone na kluczowych stronach. Połączenie tych css / js musi być przełączone na połączenie za pomocą API Bitrix.
Kolejny problem! Po scaleniu kolejność połączenia plików javascript może zostać zerwana. Z tego powodu logika javascript opracowana w przeglądarce może być uszkodzona. Podobnie w przypadku css - ze względu na zmienioną kolejność łączenia stylów niektóre style mogą być niepoprawnie przedefiniowane i powodować konflikty.
Dlatego pozornie prosty proces łączenia css i js w rzeczywistości często staje się dość czasochłonny i ryzykowny. Takie procedury są najpierw zalecane na kopiach testowych.
Kompresja (minifikacja) js i css
Innym sposobem przyspieszenia ładowania js / css jest kompresja ich zawartości.
Istotą tej kompresji jest usunięcie wszystkich komentarzy, całego skomentowanego kodu, wszystkich spacji, podziałów linii itp.
W Bitrix istnieje standardowa opcja „Uwzględnij zminimalizowane wersje plików CSS i JS” w ustawieniach modułu głównego.
Ale ta opcja powinna być również używana ostrożnie, ponieważ automatycznie zmienia css / js, aw niektórych przypadkach może powodować problemy.
Zmniejszenie liczby zasobów stron trzecich
Jeśli możliwe jest pobranie podłączonego zasobu do swojej witryny i połączenie go jako lokalnego zasobu, lepiej to zrobić.
Po pierwsze, nie możesz zagwarantować nieprzerwanego działania zasobów innych firm. Przykładami tego są masowe blokowanie przez RosKomNadzor, ataki DDoS oraz po prostu upadek lub zamrożenie witryn i serwerów innych firm (nawet dla bardzo znanych i szanowanych firm). Wszystko, na co możesz wpływać, to nieprzerwane działanie serwera i witryny. Systemy innych producentów są poza twoją kontrolą.
Po drugie, jeśli weźmiemy pod uwagę zasoby css i js, wtedy wszystkie lokalne js / css mogą zostać połączone i skompresowane. W ten sposób możesz załadować je szybciej. Nie możesz tego zrobić za pomocą zewnętrznych zasobów.
Tłumaczymy stronę na protokół HTTP / 2
HTTP / 2 to protokół przesyłania danych oparty na protokole SPDY firmy Google. Obecnie HTTP / 2 jest najbardziej aktualnym i zaawansowanym standardem.
Wprowadzenie protokołu HTTP / 2 do Twojej witryny znacznie przyspieszy ładowanie witryny za pomocą nowoczesnych przeglądarek!
Przyspieszenie ładowania osiągane jest dzięki technologii multipleksowania.
Jego istotą jest to, że wszystkie zasoby, które powinny być załadowane na stronie, są ładowane równolegle do siebie (wszystkie obrazy, wszystkie pliki css, wszystkie skrypty js, filmy, czcionki i inne pliki).
Jeśli porównamy go z przestarzałym protokołem HTTP / 1.1, wówczas istniało ograniczenie dla jednej domeny, co nie pozwalało na równoległe pobieranie dużej liczby załadowanych zasobów.
HTTP / 2 jest obsługiwany przez wszystkie nowoczesne wersje przeglądarek : Chrome, Firefox, Safari, Opera i inne. I co bardzo ważne - HTTP / 2 jest obsługiwany w mobilnych wersjach przeglądarek (iOS, Android).
A stare wersje przeglądarek po prostu nadal ładują witrynę w stary sposób, jakby strona nadal działała na HTTP / 1.1.
Przełączenie na HTTP / 2 będzie całkowicie bezbolesne.
Aby przenieść, wystarczy ponownie skonfigurować serwer WWW.
Jeśli korzystasz z wirtualnego hostingu (a nie serwera dedykowanego lub wirtualnego), możesz spróbować skontaktować się z obsługą hostingu. W skrajnych przypadkach będziesz musiał udać się do oddzielnego dzierżawionego serwera.
Ta sekcja zostanie uzupełniona. Następnym krokiem jest opisanie następujących technik przyspieszania witryny:
- Przenieś css i js na dół stron kodu HTML.
- Nieoptymalne połączenie widżetów / usług innych firm opartych na javascript.
- Przelew agenta na CZK
