- Паскорыць генерацыю старонак на сэрвэры
- Выправіць усе памылкі з "Праверкі сістэмы"
- Аптымізацыя налад вэб-сервера (apache, nginx, php-fpm)
- Аптымізацыя налад MySQL (ці іншай СКБД)
- Слабы сервер / хостынг
- Звароты да іншым API (сэрвісаў / рэсурсаў) у php-кодзе
- Неаптымальныя (цяжкія) запыты да базы дадзеных
- Неаптымальнай логіка php-кода
- Разрослыя табліцы ў базе дадзеных
- Выключэнне ці няправільна працуе сістэма кэшавання
- кампазітны сайт
- Паскорыць прагляд у браўзэры
- аптымізацыя малюнкаў
- Кэшаванне статычных файлаў на боку сервера (малюнкі, css, js)
- Прыбярыце усе рэдырэкты і неіснуючыя рэсурсы
- Адключэнне непатрэбных скрыптоў і віджэтаў
- Аб'яднанне css і js
- Сціск (минификация) js і css
- Памяншаем колькасць іншых рэсурсаў
- Перакладаем сайт на пратакол HTTP / 2
Часта да нас звяртаюцца кліенты з адной і той жа праблемай - тармозіць Битрикс.
На самай жа справе само ядро (рухавічок) у сучасных версіях Битрикс не тармозіць.
Тормазы пачынаюцца тады, калі на сайце выкарыстоўваюцца складаная ці неаптымальнай логіка, калі сайт вялікі і складаны, калі на старонках сайта выкарыстоўваецца шмат неаптымальнай javascript-логікі і г.д.
Звычайна тармозяць досыць старыя сайты, якія гадамі дапрацоўваюцца / развіваюцца, усё ускладняючы і ўскладняючы сваю логіку і нарошчваючы таварны асартымент.
І калі перад намі паўстае задача паскорыць працу такіх сайтаў, у першую чаргу мы праводзім аналіз сервера і кода сайта для таго, каб знайсці самыя вузкія месцы прадукцыйнасці. А калі прасцей - то праблемы, якія перашкаджаюць сайту працаваць хутка.
Хуткасць загрузкі старонкі складаецца з двух асноўных частак:
Хуткасць генерацыі html-старонкі на сэрвэры.
Хуткасць загрузкі ўсіх рэсурсаў у браўзэры (html-старонка, усе css, javascript, малюнкі, відэа і г.д.).
Таму работы па паскарэнню сайта (або асобных старонак) трэба весці ў абодвух напрамках - паскараць бекенд (хуткасць генерацыі старонак на сэрвэры), і паскараць фронтенд (хуткасць загрузкі ў браўзэры).
Ніжэй дадзены асноўныя рэкамендацыі павелічэнню хуткасці Битрикс, а таксама тыпавыя праблемы, якія запавольваюць працу сайта.
Паскорыць генерацыю старонак на сэрвэры
Самая вялікая праблема - гэта калі html-старонкі на сэрвэры генеруюцца павольна. Павольна - звычайна гэта даўжэй 0.3 секунд.
Менавіта пры гэтай праблеме і складаецца адчуванне, што хуткасць Битрикс (самага рухавічка) вельмі нізкая - могуць тармазіць нават старонкі "адмінку".
Каб паскорыць генерацыю той ці іншай старонкі на сэрвэры, трэба прааналізаваць логіку яе генерацыі і знайсці неаптымальнай логіку (вузкія месцы) або памылкі распрацоўнікаў. У гэтым могуць дапамагчы такія інструменты як xdebug або інструменты, убудаваныя ў CMS / фреймворка, на якім працуе ваш сайт. Да прыкладу, у Битрикс ёсць інструмент "Адладка" у панэлі адміністратара ў публічнай часткі сайта.
Далей усе прыклады будуць давацца для сайта на Битрикс.
Тыпавыя праблемы, з-за якіх можа тармазіць генерацыя старонак на боку сервера сабраны ніжэй.
Выправіць усе памылкі з "Праверкі сістэмы"
У першую чаргу неабходна запусціць "Праверку сістэмы" ў панэлі адміністравання Битрикс і выправіць усе выяўленыя праблемы.
Гэта самыя ключавыя памылкі, якія карэнным чынам уплываюць на працу сайта.
Звычайна яны злучаны з няправільнымі наладамі сервера / хостынгу.
Калі ў праверцы сістэмы ёсць хоць адна праблема, сайт можа працаваць нестабільна - нават у самых непрадбачаных і невідавочных месцах.
Налады> Інструменты> Праверка сістэмы
Аптымізацыя налад вэб-сервера (apache, nginx, php-fpm)
Часцяком налады стандартнай зборкі вэб-сервера з'яўляюцца неаптымальнай.
Таму рэкамендуецца прааналізаваць стан і наладу вэб-сервера і на базе праведзенага аўдыту аптымізаваць налады сервера.
Нашы спецыялісты гатовы вам у гэтым дапамагчы.
Дадаткова да гэтага неабходна паглядзець рэкамендацыі Битрикс ў адмінку па аптымізацыі налад PHP.
Налады> Прадукцыйнасць> PHP
Аптымізацыя налад MySQL (ці іншай СКБД)
Аналагічна аптымізацыі вэб-сервера, рэкамендуецца аптымізаваць налады базы дадзеных.
А таксама зверыць бягучыя налады з рэкамендацыя ў адмінку Битрикс.
Налады> Прадукцыйнасць> Сервер БД
Слабы сервер / хостынг
Як зразумець, што вам патрэбен больш магутны сервер / хостынг?
Манітор прадукцыйнасці сервера ў адмінку Битрикс выдае значэнне менш 30, нягледзячы на тое што вашы сісадміны (або тэхпадтрымка хостынгу) сцвярджае, што сервер настроены аптымальна (а дадзеныя з адмінку Битрикс не выдаюць праблем з неаптымальнай наладамі php або mysql).
Заўвага! Занадта дрэнны паказчык "сярэдняе час водгуку" можа значна пагаршаць агульны паказчык Канфігурацыі. Калі гэты пункт выдае занадта вялікую лічбу, трэба прааналізаваць логіку генерацыі галоўнай старонкі і забяспечыць яе хуткую аддачу серверам.
Такім чынам, калі нягледзячы на ўсе аптымізацыі сервера, паказчык манітора прадукцыйнасці маленькі, рэкамендуецца пераезд на больш магутны і аптымізаваны хостынг / сервер.
Падабраць магутны сервер па даступнай цане можна у нас .
Звароты да іншым API (сэрвісаў / рэсурсаў) у php-кодзе
Часцяком працэс генерацыі старонак тармозяць звароту да іншым сэрвісам ў php-кодзе.
Да прыкладу, гэта можа быць сэрвісы вызначэння горада, разліку кошту дастаўкі і да т.п ..
Каб зразумець, як выправіць - трэба разабрацца, чаму тармозіць.
Магчыма, у кодзе неаптымальна (няправільна) выкарыстоўваецца API іншага сэрвісу і ёсць больш аптымальныя варыянты яго выкарыстання. Магчыма, само па сабе API сэрвісу вельмі павольны.
У гэтых выпадках лагічна пагутарыць з падтрымкай сэрвісу, папрасіць іх паскорыць працу API і даць рэкамендацыі па больш аптымальным выкарыстанні для вашага выпадку.
Калі аптымізаваць выкарыстанне бягучага сэрвісу немагчыма, то трэба задумацца над пераходам на альтэрнатыўныя сэрвісы і API (альбо аб кэшавання працу бягучага API).
Неаптымальныя (цяжкія) запыты да базы дадзеных
Часцяком прычына доўгай генерацыі старонак на сэрвэры - цяжкія SQL-запыты.
У гэтым выпадку ёсць як мінімум 2 варыянты іх паскарэння:
Аптымізацыя самага запыту. Стварыць адсутнічаюць індэксы, выключыць з выбаркі непатрэбныя поля, подзапросов, вылічэнні.
Кэшаванне запыту. Каб адзін і той жа цяжкі запыт не звяртаўся да базы дадзеных пры кожнай загрузцы, вынікі выбаркі можна захаваць (у памяці, у файле або нават у самой базе дадзеных). Больш падрабязна пра кэшавання ў Битрикс .
Неаптымальнай логіка php-кода
Нават калі ў php-кодзе няма зваротаў ні да базы дадзеных, ні да іншым рэсурсаў, такі код можа тармазіць.
Віной таму можа стаць неаптымальнай логіка кода - выбарка з вялікіх масіваў, бясконцыя (ці амаль бясконцыя) цыклы, праца з вялікімі файламі дадзеных і да т.п.
У гэтым выпадку трэба выявіць такія праблемныя блокі кода і перапісаць гэты код на больш аптымальны (хуткі), альбо можна закешировать вынікі цяжкай логікі (аналагічна запытам да базы дадзеных).
Разрослыя табліцы ў базе дадзеных
Калі табліцы ў базе дадзеных забіваюцца непатрэбнымі (састарэлымі) дадзенымі, то гэта не толькі забівае дыск на сэрвэры, але і запавольвае усю працу з базай дадзеных - усе запыты да базы дадзеных пачынаюць тармазіць.
Часцяком гэта розныя логі, часопісы, дублі тавараў і іншыя сістэмныя табліцы.
Каб паглядзець усё разрослыя табліцы, зайдзіце ў адмінку ў профіль:
Налады> Прадукцыйнасць> Табліцы
І адсартуйце ўсе табліцы ў парадку змяншэння памеру.
Калі памер табліцы больш 500 МБ, то з вялікай верагоднасцю можна казаць пра тое, што ў гэтай табліцы ёсць непатрэбныя (састарэлыя) дадзеныя, якія можна выдаліць.
У некаторых выпадках крытычным з'яўляецца і значна меншы памер табліц.
У выніку ачыстка такіх разрослых табліц дазволіць паскорыць працу базы дадзеных.
Выключэнне ці няправільна працуе сістэма кэшавання
У Битрикс ёсць дастаткова добрая сістэма кэшавання.
Але пры распрацоўцы сайта пытанне выкарыстання тыпавога кэшавання першапачаткова могуць выпусціць.
Таму пры аналізе павольнай генерацыі старонак на сэрвэры асаблівую ўвагу варта надаць выяўленню тых блокаў кода (кампанентаў), дзе не выкарыстоўваецца тыпавое кэшаванне Битрикс. Выявіць такія праблемы дапаможа інструмент адладкі ў верхняй панэлі Адміністратара ў публічнай часткі сайта.
У некаторых выпадках, тыпавы механізм Автокеширования Битрикс пачынае працаваць неаптымальна. Да прыкладу, калі з 1С вельмі часта праводзяцца поўныя выгрузкі тавараў, то автокеширование пачынае пастаянна генерыраваць кэш. Пры кожным абмене ранейшы кэш ўсяго каталога састарваецца. Таму старонкі каталога тавараў пачынаюць працаваць вельмі павольна (у 90% выпадкаў кэш тавараў аказваецца састарэлым). У гэтым выпадку трэба альбо сыходзіць ад частай поўнай выгрузкі тавараў з 1С, альбо дапрацоўваць логіку кэшавання Битрикс.
кампазітны сайт
Пасля таго як усе відавочныя праблемы (апісаныя вышэй) выпраўленыя, мае сэнс падключыць тэхналогію Кампазітны сайт (або аналаг).
Паскорыць прагляд у браўзэры
Шматлікія важныя крытэрыі, якія ўплываюць на хуткасць загрузкі старонак у браўзэры сабраны ў інструменце Google PageSpeed Insights. Але ёсць і іншыя праблемы / ідэі, якія ўплываюць на час загрузкі ў браўзэры.
аптымізацыя малюнкаў
Добрае паскарэнне дасягаецца за кошт сціску (аптымізацыі) малюнкаў. Уся справа ў тым, што вельмі вялікая частка ўсіх дадзеных, загружаных на старонцы сайта - гэта выявы.
Сутнасць алгарытмаў сціску - аб'яднаць падобныя колеру і выдаліць з файла розную службовую інфармацыю (каментары, gps-каардынаты, мадэль фотаапарата і да т.п.).
OptiPic - самы просты і эфектыўны інструмент для аптымізацыі малюнкаў. Ён дазваляе ў аўтаматычным рэжыме знайсці і аптымізаваць ўсе выявы на сайце.
Кэшаванне статычных файлаў на боку сервера (малюнкі, css, js)
На баку сервера неабходна наладзіць аддачу статычных файлаў з кэшаваннем. Гэта дазволіць не загружаць паўторна ўсё статычныя рэсурсы пры перазагрузцы старонкі або адкрыцці іншай старонкі сайта, на якой выкарыстоўваюцца аднолькавыя рэсурсы (jpeg, png, css, js і да т.п.).
Калі вы выкарыстоўваеце віртуальны хостынг, то папытаеце тэхпадтрымку хостынгу наладзіць кэшаванне статычных рэсурсаў на сайце (малюнкі, відэа, css, js). Гэта можна трактаваць як недагляд віртуальнага хостынгу, калі ў іх такое кэшаванне не рэалізавана першапачаткова. Таму ў большасці выпадкаў тэхпадтрымка ідзе насустрач і бясплатна праводзіць неабходную наладу.
Калі ў вас паўстала праблема з дадзенай наладай, вы карыстаецеся віртуальны або выдзелены сервер - нашы спецыялісты гатовы вам дапамагчы.
Прыбярыце усе рэдырэкты і неіснуючыя рэсурсы
Часцяком у працэсе жыццядзейнасці сайта на старонкі падключаюцца ўсё новыя і новыя рэсурсы (малюначкі, javascript-файлы, css-файлы). Некаторыя з іх потым выдаляюцца за непатрэбнасцю - але іх падлучэнне забываюць прыбраць са старонкі. Некаторыя з іх перамяшчаюцца - і для прастаты наладжваецца рэдырэкт са старога адрасы на новы (каб на ўсіх старонках перепрописывать url да новых адрасах).
У выніку гэтага, на старонках з'яўляюцца рэсурсы, якія пры спробе іх загрузіць, аддаюць 404 адказ (рэсурс не існуе), а таксама 301 або 302 адказы (рэсурс перамешчаны часова або пастаянна).
Усе гэтыя сітуацыі браўзэрам даводзіцца апрацоўваць, марнуючы на гэта каштоўны час загрузкі старонкі.
Выпраўленне ўсіх 4xx, 3xx адказаў дае дадатковае перавага ў хуткасці загрузкі і рэндэрынгу старонак браўзэрам.
Адключэнне непатрэбных скрыптоў і віджэтаў
Неабходна дакладна вызначыць неабходнасць выкарыстання тых ці іншых віджэтаў, сэрвісаў і бібліятэк на базе javascript.
У першую чаргу трэба пазбавіць ад падключэння тых рэсурсаў, якія зусім ужо не выкарыстоўваюцца на сайце.
Далей неабходна прааналізаваць неабходнасць падлучэння адных і тых рэ рэсурсаў на ўсіх старонках сайта. Да прыкладу, калі на сайце віджэт лайкаў у соцсетях адлюстроўваецца толькі на дэталёвых старонках тавараў (а на астатніх старонках ён не паказаны), то няма сэнсу падключаць гэты віджэт на ўсіх старонках - падлучэнне любога дадатковага рэсурсу на старонцы запавольвае загрузку старонкі. Таму разумней падключаць гэты віджэт толькі на дэталёвых старонках тавараў. А на астатніх старонка выключыць падлучэнне фішкі.
Таксама бываюць выпадкі, што адзін і той жа рэсурс далучаецца на старонцы некалькі разоў. Да прыкладу, адна і тая ж бібліятэка выкарыстоўваецца ў розных частках старонкі. Гэтыя блокі былі распрацаваны ў розны час рознымі распрацоўшчыкамі. У выніку падключаецца адна і тая ж бібліятэка (магчыма, розныя версіі адной бібліятэкі).
Гэтыя выпадкі таксама трэба выключаць - пакідаючы падлучэнне толькі адной версіі бібліятэкі.
Аб'яднанне css і js
Усе выкарыстоўваюцца css -файлы можна аб'яднаць у адзін файл. Аналагічна - з javascript. Загрузка аб'яднаных версій адбываецца значна хутчэй, чым загрузка ўсіх рэсурсаў без аб'яднання. Прычым часцяком гэта добра працуе і пры выкарыстанні HTTP / 2.
У Битрикс для гэтага ёсць спецыяльныя налады ў ядры. Гэта ёсць у наладах Галоўнага модуля.
Налады> налады прадукту> налады модуляў> Галоўны модуль
І быццам бы ўсё вельмі проста. Але справа ў тым, што аб'ядноўваюцца толькі тыя js і css, якія падключаюцца на сайце праз API Битрикс.
Для js - праз метад CMain :: AddHeadScript () . Для css - CMain :: SetAdditionalCSS () .
У ядры D7 для гэтага выкарыстоўваюцца Asset :: getInstance () -> addCss () і Asset :: getInstance () -> addJs ().
А значыць, трэба пераканацца, каб усе рэсурсы падлучаліся менавіта праз API.
Для гэтага трэба ўключыць опцыі ў наладах, і паглядзець - якія css / js яшчэ не аб'ядналіся на ключавых старонках. Падключэнне гэтых css / js трэба пераключыць на падключэнне праз API Битрикс.
Яшчэ адна праблема! Пасля аб'яднання можа парушыцца чарговасць падлучэння javascript-файлаў. А з-за гэтага можа парушыцца javascript-логіка, адпрацоўваць у браўзэры. Аналагічна з css - з-за змененай чарговасці падлучэння стыляў, могуць некаторыя стылі могуць няправільна перавызначыць і канфліктаваць.
Таму быццам бы просты працэс аб'яднання css і js на самай справе часцяком становіцца досыць працаёмкім і рызыкоўным. Такія працэдуры спачатку рэкамендуецца праводзіць на тэставых копіях.
Сціск (минификация) js і css
Яшчэ адзін спосаб паскорыць загрузку js / css - гэта сціснуць іх змесціва.
Сутнасць такога сціску - выдаліць усе каментары, увесь закаментаваўшы код, усе прабелы, пераносы радкоў і да т.п.
У Битрикс для гэтага ёсць стандартная опцыя "Падлучаць минифицированные версіі CSS і JS файлаў" у наладах Галоўнага модуля.
Але гэтую опцыю таксама варта выкарыстоўваць з асцярожнасцю, бо яна аўтаматам змяняе css / js і ў некаторых выпадках гэта можа прывесці да праблем.
Памяншаем колькасць іншых рэсурсаў
Калі ёсць магчымасць спампаваць падключаецца рэсурс да сабе на сайт і падключаць яго як лакальны рэсурс, лепш менавіта так і паступіць.
Па-першае, вы не можаце гарантаваць бесперабойную працу іншых рэсурсаў. Прыклады таму - масавыя блакавання Роскомнадзора, DDoS атакі і проста падзення або завісання іншых сайтаў і сервераў (нават у вельмі вядомых і паважаных кампаній). Усё, на што вы можаце ўплываць, - гэта на бесперабойнасць працы свайго сервера і сайта. Іншыя сістэмы вам ніяк не падуладныя.
Па-другое, калі разглядаць css і js рэсурсы, то ўсё лакальны js / css можна аб'яднаць і сціснуць. Такім чынам вы забяспечыце больш хуткую іх загрузку. З знешнімі рэсурсамі вы так паступіць не можаце.
Перакладаем сайт на пратакол HTTP / 2
HTTP / 2 - гэта пратакол перадачы дадзеных, заснаваны на пратаколе SPDY ад кампаніі Google. На дадзены момант HTTP / 2 - самае актуальнае і перадавой стандарт.
Ўкараненне пратаколу HTTP / 2 на ваш сайт дазволіць значна паскорыць загрузку сайта сучаснымі браўзэрамі!
Паскарэнне загрузкі дасягаецца за кошт тэхналогіі мультыплексавання.
Сутнасць яго ў тым, што ўсе рэсурсы, якія павінны загрузіцца на старонку, загружаюцца паралельна адзін аднаму (усе малюнкі, усё css-файлы, усе js-скрыпты, відэа, шрыфты і іншыя файлы).
Калі параўнаць з састарэлым пратаколам HTTP / 1.1, то там для аднаго дамена існаваў ліміт, які не дазваляў распараллелить загрузку вялікага колличесво загружаных рэсурсаў.
HTTP / 2 падтрымліваецца ўсімі сучаснымі версіямі браўзэраў: Chrome, Firefox, Safari, Opera і іншымі. І што вельмі важна - HTTP / 2 падтрымліваецца ў мабільных версіях браўзэраў (iOS, Android).
А старыя версіі браўзэраў проста працягнуць загружаць ваш сайт па-старым прынцыпе як быццам сайт да гэтага часу працуе на HTTP / 1.1.
Пераход на HTTP / 2 будзе абсалютна бязбольным.
Для пераходу трэба толькі пераналадзіць вэб-сервер.
Калі ў вас выкарыстоўваецца віртуальны хостынг (а не вылучаны або віртуальны сервер), то можна паспрабаваць звярнуцца ў падтрымку хостынгу. У крайнім выпадку - прыйдзецца перайсці на асобны арандаваны сервер.
Дадзены падзел будзе яшчэ дапаўняцца. На чарзе апісанне наступных тэхнік паскарэння сайта:
- Перанос css і js ў ніжнюю частку html-кода старонак.
- Неаптымальнай падлучэнне іншых віджэтаў / сэрвісаў на базе javascript.
- Пераклад агентаў на крон
