Ці Google PageSpeed ​​Insights дае вам непрыемнасці? Даведайцеся, як выдаліць іх

1. Арганічнае пазіцыянаванне мае толькі вочы для PageSpeed ​​Insights
2. Як працуе Аналіз прадукцыйнасці PageSpeed ​​Insights?
3. 10 правілаў аналізу прадукцыйнасці на першы погляд
4. Google PageSpeed ​​Insights: дазвол правілаў прадукцыйнасці
5. Выдаліце ​​рэндэрынг блокаторы JavaScript і CSS
6. Пакажыце кэш браўзэра
7. Пазбягайце мэтавай старонкі перанакіраваньні
8. ўключыць сціск
9. Мінімізаваць HTML, CSS і JavaScript
10. аптымізаваць выявы
11. Прыярытэтнасць бачнага ўтрымання
12. Скарачэнне часу водгуку сервера
13. высновы

Сярэдні час чытання: 15 мін (4700 слоў).
Калі ў вас няма часу, вы можаце перайсці непасрэдна да Артыкул высновы ,

Лепшы Wordpress хостынг з 20% OFF!

Арганічнае пазіцыянаванне мае толькі вочы для PageSpeed ​​Insights

Вочы адкрываюцца PageSpeed, каб палепшыць свой SEO

Адна з самых сумных абласцей тэхнічнай SEO пакутуюць разам зь Справаздачы Google PageSpeed ​​Insights , Па двух прычынах: (1) з аднаго боку, мы толькі вызначае праблемы, якія былі знойдзеныя, але часта без рашэння, рэкамендацыі або выразнага арыентыру пра тое, як знайсці і вырашыць; і (2) , так як яна аказвае вырашальны ўплыў на арганічным пазіцыянаванні кожнай канкрэтнай вэб - старонкі і вэб - сайта ў цэлым.

PageSpeed ​​Insights не з'яўляецца унікальным. Мы маем шмат іншых дыягнастычных інструментаў (напрыклад, Pingdom , GTmetrix або WebPagetest ) Нават яны прапануюць лепшыя і больш поўныя метрыкі для ацэнкі прадукцыйнасці нашых вэб-сайтаў. Аднак, іх ацэнкі не гэтак актуальныя: момант ісціны, наш сайт можа мець дасканалы кошт на ўсе гэтыя інструменты , але Google толькі звярнуць увагу на на аналіз вашага інструмента.

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

Акрамя таго, па параўнанні з справаздачамі гэтых іншых інструментаў, Google PageSpeed Insights справаздачу не выкарыстоўвае занадта шмат тэхнікі «жаргону» і не патрабуе высокіх тэхнічных навыкаў , каб зразумець , і ў многіх выпадках вырашыць іх . Па гэтай прычыне, ён ідэальна падыходзіць для любога ўладальніка блога або вэб - сайт сярэдняга памеру, не занадта высока наведванняў, вам проста трэба быць экспертам у сваёй вобласці і не можа мець тэхнічны інструмент нумар каманды.

З Вядома, як вэб - сайт або візітаў павелічэнне, ацэнка PageSpeed Insights будзе пакутаваць , калі мы будзем прытрымлівацца рэкамендацый у гэтым артыкуле, таму што яна ўключае ў сябе іншыя , больш тонкія фактары , якія ідэнтыфікуюць PageSpeed. У гэтым выпадку няма больш ці няма выбару, акрамя як выкарыстоўваць больш спецыялізаваныя інструменты і больш кваліфікаваных спецыялістаў, каб ідэнтыфікаваць і вырашаць іх, так як гэта можа паўплываць на вобласці распрацоўкі, вэб-дызайн, базы дадзеных кіравання або кіравання серверам, сярод іншых.

Як працуе Аналіз прадукцыйнасці PageSpeed ​​Insights?

PageSpeed ​​Insights тэхніка ў поўным разгары

У гэтым артыкуле мы засяродзімся на аналізе вырабляецца PageSpeed Insights для вымярэння прадукцыйнасці вэб - сайта, агульнай для мабільных асяроддзяў і працоўных сталоў.

Інструмент таксама выконвае для мабільных асяроддзяў, аналізу працы карыстальнікаў, арыентаваных на графічным дысплеі сайта ў невялікіх экранах мабільных прылад, але мы не будзем вырашаць яго тут. Калі вы зацікаўлены ў атрыманні дадатковай інфармацыі аб вопыце карыстальнікаў на мабільным, вы можаце праверыць гэта артыкул ,

Аналіз PageSpeed Insights заснаваны на праверцы і захаванню ў агульнай складанасці дзесяць правілаў. Для таго, каб вымераць ступень задавальнення гэтых правілаў, справаздачу PageSpeed выкарыстоўвае каляровай код , падобны на святлафор:

• Зялёны колер, паказваючы , што гэта правіла поўнасцю задаволены.
• Аранжавы, калі правіла не цалкам задаволены , але не мае вялікага ўплыву на канчатковы лік.
• Чырвоны, за выключэннем тых правілаў , якія, не задаволеных, мае вялікі ўплыў на канчатковы лік.

Такім чынам, наш прыярытэт заўсёды будзе вырашана як мага хутчэй правілы, налiчаных на чырвоным колеры, нават аранжавы, якія ўжо атрымлівае істотнае паляпшэнне выніковай ацэнкі. Толькі тады мы павінны звярнуць увагу на апавяшчэння аб аранжавым, але, ведаючы, што яны не з'яўляюцца крытычнымі.

Нарэшце, адзначым вельмі важны аспект ў ацэнцы эфектыўнасці нашага сайта: розныя выкананняў інструмент аналізу можа (на самай справе, як правіла) даюць розныя вынікі, у дыяпазоне да 6-8 пунктаў.

Гэта цалкам нармальна, так як існуе мноства фактараў , якія могуць быць ўцягнутыя ў працэсе аналізу прадукцыйнасці і ніяк не звязана з з самага сайта, так як аб'ём інтэрнэт - трафіку ў той момант, стан і мае магутнасці злучальных ліній , якія выкарыстоўваюцца, цяжар хостынг-сервера (асабліва, калі выкарыстоўваецца сумесна) і г.д.

10 правілаў аналізу прадукцыйнасці на першы погляд

Вобраз, які заўсёды хацеў, каб атрымаць з PageSpeed ​​Insights будзе:

Зараз давайце паглядзім, што гэтыя Справаздача Дзесяць правілаў аналізу З кароткім тлумачэннем яго сэнсу, перш чым рухацца далей, каб убачыць, як вырашыць іх у наступным раздзеле:

• Ліквідацыю блакавання JavaScript і CSS. Найбольш важная часткай сайта з'яўляецца яго вяршыняй ( «над-кратным»), які адлюстроўваецца вакол загрузкі старонкі і першае, што вы бачыце. Таму вельмі важна, што браўзэр адлюстроўвае яго як мага хутчэй і не звяртацца да затрымкі прагляду.
• Пакажыце кэш браўзэра. Як правіла, вэб-старонка не мяняецца вельмі часта, так што паўторны доступ карыстальніка да старонцы будзе зноў і зноў загружаць адны і тыя ж рэсурсы. З кэшаваннем, браўзэр захоўвае копію гэтых рэсурсаў, таму ім не трэба пастаянна разряжается.
• Пазбягайце мэтавай старонкі пераадрасацыі. Рэдырэкт пераўтворыць вэб-адрас у іншы, які можа датачыць злучэнне часу сервера і пачаць загрузку старонкі.
• Ўключыць сціск. Сучасныя серверы і браўзэры падтрымліваюць GZIP і пацвердзіць разуменне, што можа значна паменшыць памер рэсурсаў і, такім чынам, час загрузкі вэб-старонкі.
• Мінімізаваць CSS. Як правіла, CSS арганізаваны для лёгкага чытання людзьмі крывацёкам, пустыя радкі, каментары і г.д. Тым не менш, усё гэта дадатковая інфармацыя і структура нічога не прыўносяць стылі сайта, хоць гэта павялічвае памер файла і час загрузкі і апрацоўку з дапамогай браўзэра.
• Мінімізаваць HTML. Па той жа прычыне, што лісты CSS, HTML файлы, як правіла, ўключаюць у сябе дадатковую інфармацыю, каб палегчыць чытанне для людзей, але і для іх непатрэбнага быць інтэрпрэтаваныя і якія аказваюцца браўзэрамі.
• Мінімізаваць JavaScript. Па-відаць, такі ж, як для CSS і HTML коды лісця, але спасылаючыся на файлы JavaScript, якія выкарыстоўваюцца на вэб-сайце.
• Аптымізацыя выяваў. Безумоўна, гэтыя выявы з'яўляюцца рэсурсам, які спажывае вялікую прапускную здольнасць і час загрузкі трэба. Мы павінны забяспечыць, каб памеры і памер малюнкаў з'яўляюцца мінімальна магчымым без страты якасці канчатковага дысплея.
• Па прыярытэтам бачнага змесціва. Гэта ўсё або большая частка інфармацыі, якая ўказваецца ў бачных верхняй частцы старонкі ( «над-кратным») даступна як мага хутчэй, так што ён можа быць адлюстраваны ў браўзэры у той час як астатняя частка старонкі працягваць зарадку.
• Скарачэнне часу водгуку сервера. Фактар, над якім мы маем меншы кантроль, вымярае, колькі часу спатрэбіцца хостынг-сервер адказвае на запыты вэб-старонкі або іншага рэсурсу з дапамогай браўзэра.

З 20% зніжку на!

Google PageSpeed ​​Insights: дазвол правілаў прадукцыйнасці

Большасць рэкамендацый, мы ўбачым з гэтага моманту, каб вырашыць парушэння гэтых правілаў справядлівыя і дастасавальныя да любой платформе з серверамі Apache і любы кантэнт-мэнэджэра, хоць, улічваючы распаўсюджанасць WordPress для стварэння вэб-сайтаў і блогаў, калі ёсць якой-небудзь інструмент або ўбудова, які можа вырашыць, часткова ці цалкам, падзення, і я буду ўключаць.

Майце на ўвазе, што не заўсёды ёсць прамыя рашэнні, але залежыць ад таго, як вы стварылі вэб-сайт; напрыклад, у выпадку WordPress, тэма для выкарыстання або убудоў вы ўстанавілі. На самай справе, гэты аспект з'яўляецца настолькі важным, што можа быць тым ці убудовы, якія перашкаджаюць рэалізацыі некаторых рашэнняў, якія я прапаную тут, асабліва калі яны звязаны з ўбудовамі.

Выдаліце ​​рэндэрынг блокаторы JavaScript і CSS

Як правіла, вэб-сайт займае значна больш, чым экран, на якім адлюстроўваецца. Пры загрузцы старонкі, першае, што адлюстроўваецца з'яўляецца верхнім ( «вышэй у раз»), хоць астатняя частка старонкі, каб працягнуць загрузку з сервера:

У ідэале , браўзэр можа зрабіць бачную частку старонкі без неабходнасці чакаць да канца загрузкі старонкі. Для гэтага патрэбныя дзве рэчы:

• Як толькі ў якасці магчымага ўсяго змесціва гэтай частцы даступна (гэтая кропка будзе быць падрабязна абмеркаваны ў адпаведным правіле).
• Гэта значыць няма JavaScript або CSS , каб адкласці (пахмелля) рэндэрынг не адлюструецца да амаль на ўсёй старонцы.

Стылі CSS вызначаюць як элементы старонкі (напрыклад, колеру, шрыфтоў, структура старонкі, сартавальныя пункты і г.д.), будуць адлюстроўвацца у той час як код JavaScript можа ўплываць, як і тое, што адлюстроўваецца.

Таму, калі альбо недаступныя для пачатку загрузкі старонкі, браўзэр павінен чакаць, пакуль яны не будуць аказваць яго і паказаць яго. Калі б яны былі на ў канцы старонкі або на знешніх серверах, карыстачу прыйдзецца чакаць усё , каб пачаць бачыць descargasen старонкі.

Калі ў вас ёсць вельмі прасунутыя веды праграмавання і CSS стыляў JavaScript, пры нармальных абставінах, незалежны блогер або ўладальнік сайта не можа дазволіць парушэнне гэтага правіла самога па сабе, гэта залежыць амаль выключна ад двух фактараў:

• Як вэб-сайт прызначаны для пры выкарыстанні кода JavaScript і CSS стыляў (гэта значыць, у залежнасці ад тэмы, што выкарыстоўваецца).
• Убудовы і дапаўненні вы ўсталявалі, так як яны могуць дадаць код або CSS JavaScript стылі для дызайну вэб-старонак.

Але не губляйце надзеі, таму што нават мы можам прыняць меры , каб звесці да мінімуму ўздзеянне парушэнні гэтага правіла, лічачы , што гэта не заўсёды магчыма , каб выдаліць яго цалкам:

• Калі мы будзем выкарыстоўваць карыстацкі вэб-дызайн, пытаючыся дызайнера, што сайт не ўтрымлівае JavaScript або CSS-блокаторы.
• Калі мы выкарыстоўваем тэму, выбраўшы адну, чые дызайнеры забяспечваюць мінімальны ўплыў у гэтых адносінах (практычна любая сучасная тэма ўжо адпавядае гэтаму патрабаванню).
• Калі вы выкарыстоўваеце плягін або дапаўненні, вырашаючы, ці з'яўляюцца яны сапраўды неабходныя, і, калі так, то шукайце менш агрэсіўны альтэрнатыўны убудова з гэтым правілам.
• Калі вы выкарыстоўваеце плягін або дапаўненні, а не выкарыстоўваць іх у верхняй частцы вэб-старонак, так што яна можа быць аказана без выкарыстання рэсурсаў убудова.
• Калі мы выкарыстоўваем тэму або ўбудова, наймаючы вэб-дызайнер перагледзець і перапісаць, каб ліквідаваць або паменшыць блакавальныя элементы.

WordPress вэб-сайты, магчымае рашэнне было б выкарыстоўваць убудова для канкатэнацыі JavaScript файлаў і CSS лістоў (напрыклад, Autoptimize ), Так што мы патрацілі б некалькі блокаторов файлаў у адзін.

Аднак гэтае аб'яднаньне ня захоўвае залежнасцяў паміж ўбудовамі (наколькі я ведаю, ні адзін убудова не можа і можа быць зроблена толькі ўручную), таму ён не можа працаваць, мы першапачаткова, але, магчыма, выдаленне нейкі убудова, працуе выдатна: больш падстаў усё магчымае, каб паменшыць колькасць убудоў.

З іншага боку, мы павінны прывыкнуць да думкі, што рэдка можа задаволіць гэтае правіла да 100%, і мы павінны быць змест, каб гарантаваць, што ўздзеянне як мага; галоўным чынам робячы інтэлектуальнае і крытычнае выкарыстанне убудоў.

Пакажыце кэш браўзэра

Кэш для захоўвання вэб-рэсурсаў

У адрозненне ад прыведзенага вышэй правілы, рэдка ўдаецца поўнасцю вырашыць, гэтае правіла амаль заўсёды можна выправіць ... калі мы не будзем выкарыстоўваць знешнія рэсурсы (напрыклад, размешчаных на іншых серверах). І нават у гэтым выпадку ёсць рашэнні, але яны ўжо пэўны рэсурс і знешні сервер, які выкарыстоўваецца.

Google рэкамендуе Мінімальны кэш браўзэра альбо адзін тыдзень, пашыраючы год для статычных рэсурсаў (напрыклад, выявы) або рэдка змяняюцца.

Гэты час можа быць ўстаноўлена на серверы хостынгу, зьмяняяючы сістэмны файл з імем «.htaccess». хостынг-правайдэры, як правіла, дазваляць доступ і змяняць гэты файл, такім чынам, мы можам зрабіць гэта самі (і калі не дазволена, Прыходзь на вашу падтрымку).

¡¡¡Асцярожнымі !!! Памылка ў гэтым файле можа блакаваць або збіць вэб-сайт, так што вы заўсёды мець рэзервовую копію на рукі, калі мы не маюць рацыю, і мы можам хутка аднавіць.

Каб наладзіць кэш браўзэра мінімум раз на тыдзень, проста дадайце наступныя радкі ў «.htaccess» ( быць упэўненыя , каб скапіяваць яго ў дакладнасці як ёсць):

<IfModule mod_expires.c> ExpiresActive На ExpiresDefault "доступ плюс 1 тыдзень" </ IfModule>

Калі вы хочаце , каб паказаць розныя часы кэша ў адпаведнасці з тыпам рэсурсу, магчымым рашэннем будзе:

<IfModule mod_expires.c> ExpiresActive На ExpiresByType малюнка / JPG "доступ 1 год" ExpiresByType малюнка / JPEG "доступ 1 год" ExpiresByType малюнак / GIF "доступ 1 год" ExpiresByType малюнка / PNG "доступ 1 год" ExpiresByType малюнка / х-значок "доступ 1 год" ExpiresByType тэкст / CSS "доступ 1 месяц" ExpiresByType тэкст / х-JavaScript "доступ 1 месяц" ExpiresDefault "доступ плюс 1 тыдзень" </ IfModule>

З дапамогай гэтага кода, кэш год для графічных рэсурсаў, месяц JavaScript і CSS файлы, і праз тыдзень на ўсё астатняе наладжваецца.

У дадатак да кэш часу, сервер можа таксама інфармаваць браўзэр апошні раз рэсурс мадыфікаваны. Такім чынам, хоць заклік скончыўся ў кэшы, браўзэр можа праверыць, калі ён быў зменены на сэрвэры, і, калі няма, то няма неабходнасці, каб загрузіць яго зноў. Каб зрабіць гэта, проста дадайце наступны радок у «.htaccess»:

FileETag Памер час змянення

Ня варта забываць , што гэтыя рашэнні могуць быць ужытыя толькі ў нашых уласных серверах хостынгу. Калі наш сайт таксама выкарыстоўвае знешнія рэсурсы, якія захоўваюцца на іншых серверах, мы не маем магчымасці змяняць файлы «.htaccess», таму мы з улікам іх адпаведных уладальнікаў, што яны хочуць. Нават у гэтых выпадках вы можаце зрабіць рашэнне, але было б індывідуальныя рашэнні для гэтага рэсурсу і гэтага сервера.

Гэта адбываецца, напрыклад, з файлам «analytics.js» неабходна выкарыстоўваць статыстычныя справаздачы Google Analytics, які мае зыходны сервер часу кэш ўсяго за дзве гадзіны. Праз невялікі «трук» тут вы можаце ўбачыць, як я мог бы пераадолець абмежаванні часу Сцэнар кэш браўзэра analytics.js ,

Пазбягайце мэтавай старонкі перанакіраваньні

З пераадрасаванне, загружае іншую старонку

Я не магу ўспомніць апошні раз, калі я бачыў злачынствы такога роду. Пад гэтым я маю на ўвазе, што незвычайныя і, як правіла, калі ў нас ёсць, таму што мы самі дадалі рэдырэкт, нібыта па ўважлівай прычыне; напрыклад, рэструктурызацыя вэб-сайта і не жадае страціць рэйтынг старых сувязяў.

Калі гэта толькі прычына, мы не павінны выдаляць перапрызначэння, так як яны гарантуюць , што карыстальнік дасягае сайт , які ўяўляе цікавасць , а, магчыма, на старонцы 404 памылак, з павышаным рызыкай для карыстальніка , каб сысці. Такая сітуацыя можа паўстаць, напрыклад, калі карыстальнік прыходзіць праз знешнюю спасылку, якая паказвае на папярэднюю старонку рэструктурызацыі сайта.

Але тое , што мы павінны гарантаваць, што рух у нашым сайце не маюць варанок; г.зн. усе ўнутраныя сувязі паміж нашымі вэб-сайты з'яўляюцца прамымі. Калі мы зменім структуру нашага сайта, гэта можа быць няпростай задачай (праверыць кожную спасылку на кожнай старонцы і замяніць яго правільным, дзе гэта дарэчы), але мы пераканаліся, што рух хутчэй і гладчэй.

ўключыць сціск

Большасць сучасных сервераў і браўзэры падтрымліваюць адзін тып сціску даных "GZIP» або фармат не ўдаецца, «здзімаць», так што ўсе сувязі паміж імі (HTML, JavaScript, CSS, малюнка, файлы і г.д. .) вырабляюцца з сціснутымі дадзенымі ў адным з гэтых фарматаў.

Такім чынам , памяншаючы памер дадзеных , якія перадаюцца паміж серверам і браўзэрам, ваш час загрузкі таксама памяншаецца, так што ўся старонка будзе таксама загружацца хутчэй і будзе адлюстроўвацца да браўзэра.

Apache сервер, канфігурацыя сервера, каб зрабіць гэта так жа проста, як капіраванне наступнага фрагмента кода ў фармат GZIP:

<IfModule mod_gzip.c> mod_gzip_on mod_gzip_dechunk Ды mod_gzip_item_include файл (HTML |? Txt | CSS | JS | PHP | мн.л.). $ Mod_gzip_item_include CGI-скрыпт апрацоўшчык ^ $ ^ mod_gzip_item_include мім мім ^ mod_gzip_item_include /.* тэкст дадатку / х-Javascript . * mod_gzip_item_exclude мім ^ ^ rspheader малюнак /.* mod_gzip_item_exclude Content-Encoding: .. * * GZIP </ IfModule>

Або наступны фрагмент кода для фармату DEFLATE:

<IfModule mod_deflate.c> AddOutputFilterByType DEFLATE тэкст / тэкст тэкст / html тэкст / звычайны тэкст / XML тэкст / CSS тэкст / JavaScript прыкладання / JavaScript ужыванне / х-JavaScript Application / XML дадатак / XHTML + прыкладанне XML / RSS + прыкладанне XML / х -httpd-PHP ужыванне / х-HTTPD-fastphp малюнак / SVG + XML </ IfModule>

Звярніце ўвагу на тое, што ў абодвух выпадках вы павінны паказаць, якія рэсурсы сціскаюцца, намэнклятура " MIME ». Я стаўлю самую агульную канфігурацыю, але калі вы хочаце, каб уключыць іншыя рэсурсы, вы можаце праверыць яго MIME тып у сервер Apache ўручную ,

Калі вы не ведаеце, што ваш фармат сціску слуга, звярніцеся да пастаўшчыка паслуг тэхнічнай падтрымкі або паспрабаваць сябе адзін з адным, правяраючы з PageSpeed ​​Insights, калі я ўсталяваў сціск. У тым выпадку, калі абодва даступныя, GZIP звычайна працуе лепш, чым DEFLATE.

Мінімізаваць HTML, CSS і JavaScript

Файлаў канфігурацыі мы можам Мінімізаваць

Хоць тры розных правілы настолькі звязаныя паміж сабой і дазвол настолькі падобныя, што мы будзем бачыць разам.

Вэб-старонкі генеруюцца з кода трох тыпаў файлаў: файлы з HTML код, файлы з кодам JavaScript і CSS. Гэтыя тры файла вызначаюць , які кантэнт адлюстроўваецца і якім чынам , ці ўключаны тэкставыя ці графічныя выявы.

Звычайна, калі дызайнеры і вэб - распрацоўшчыкі пішуць гэтыя файлы, яны выкарыстоўваюць лёгка чытаны фармат для людзей, таму што яны павінны ўвесь час рэдагаваць і павінны мець магчымасць хутка і лёгка знайсці любую кропку коды , каб змяніць або выправіць. Гэта азначае, што файл кода:

• Яна ўключае ў сябе каментары, каб растлумачыць, вылучыць або асобныя часткі кода.
• Ён водступ з прабеламі і укладкамі, каб структураваць яе ў адпаведнасці з іх функцыянальным прызначэннем.
• Яна ўключае ў сябе адзін або некалькі парываў радкоў, каб аддзяліць інструкцыі адзін ад аднаго.

Уся гэтая інфармацыя, хоць і карысна для чалавека тэхніка, нічога не прыўносіць канчатковую прадукцыйнасць вэб - сайта. Тым не менш, яны займаюць месца ў файле, павялічваючы яго памер і, такім чынам, трэба больш часу, каб загрузіць і час апрацоўкі браўзэра для адлюстравання старонкі.

З гэтым правілам, PageSpeed Insights правярае , што гэтыя файлы рэсурсаў не ўтрымліваюць гэтую інфармацыю, але толькі апрацоўваны кодам браўзэра, тым самым падвышаючы хуткасць.

У нас ёсць тры спосабы Мінімізаваць гэтыя файлы:

1. Minificados файлы , выкарыстоўваючы матэрыялы PageSpeed, скапіраваўшы іх на нашым серверы , каб замяніць наш. Гэты варыянт, як правіла, сапраўдныя для JavaScript і CSS-файлаў, але не для HTML-код, згенераваны кантэнт-мэнэджэра.
2. Выкарыстоўваючы сябе над минификация інструмент з кожным і кожны з файлаў, паўтараючы пры пераходзе аднаго з іх.
3. Выкарыстоўваючы убудова або дадаць -ён , што зрабіць гэта аўтаматычна , калі адзін з зыходных файлаў загружаюцца. Асабіста я аддаю перавагу гэты варыянт.

У WordPress, у нас ёсць два плагіна, вышэйзгаданыя Autoptimize і Лепш WordPress Мінімізаваць Які аўтаматычна выканае минификацию. Акрамя таго, абодва яны ўключаюць кэш ня Мінімізаваць новы файл рэсурсаў , які раней быў мінімізаваныя, з наступнай выгадай для часу апрацоўкі сервера, які не павінен паўтараць , што минификация.

аптымізаваць выявы

Вынік Дзіўна, наколькі парушаецца гэтае правіла. Не толькі для лёгкасці і хуткасці, з якой яна можа быць вырашана, але таму, што нават уласны PageSpeed ​​Insights прадастаўляе файл з выявамі ўжо аптымізаваны, так што ў канчатковым выніку ўсё, што мы павінны зрабіць, гэта загрузіць яго і змясціць гэтыя выявы на нашым серверы (хоць гэта не было б ідэальным рашэннем).

Ідэальным рашэннем было б ўключаць у сябе наступныя крокі:

1. Адрэгулюйце памеры малюнкаў з памерамі месца , дзе яны адлюстроўваюцца. Гэта значыць, што малюнак і месца маюць аднолькавую шырыню і вышыню. Кожны малюнак, якое больш, чым дысплейных месца будзе трата трафіку для яго загрузкі.
2. Сціск малюнкаў з стратай нізкай якасці ( «сціск з стратамі») , а не без страты якасці ( "сціск без страт»). Большасць карыстальнікаў проста ацаніць розніцу паміж імі, але памерам файла істотна памяншаецца.
3. Калі вам трэба , каб забяспечыць высокую - якасць малюнка (напрыклад , прафесійныя фатаграфіі сайты) выкарыстоўвае сціснутыя малюнка на каруселі або паказу фатаграфій з спасылкай для загрузкі фота ў высокай якасці.

Хоць WordPress мае убудовы, якія сціскаюць малюнка У тым ліку і тыя, якія валодаюць кантэнт-менеджэр стварае адаптыўныя канструкцыі, застаецца наша адказнасць, каб правільна наладзіць яго памеры (напрыклад, інструмент PicResize ). Калі вы хочаце, каб сціснуць малюнка сябе, замест таго, каб з дапамогай убудоў, лепшы онлайн інструмент, я знайшоў Кракаў ,

Нарэшце, я пакідаю спасылку для тых, хто зацікаўлены ў аптымізаваць загрузку малюнкаў у WordPress У той час як у гэтым артыкуле вы можаце ўбачыць, як сціску выяваў без выкарыстання убудоў WordPress ,

Прыярытэтнасць бачнага ўтрымання

У верхняй частцы старонкі з'яўляецца найбольш важным, паколькі ён з'яўляецца першым, каб быць

Мэта гэтага правіла складаецца ў тым , што ўтрыманне ў верхняй частцы старонкі ( «над-кратным») даступна як мага хутчэй, так што браўзэр можа зрабіць гэта без неабходнасці падключаць некалькі разоў да сервера і хоць астатняму сайт яшчэ не былі ўкладзены.

Мы казалі ў першым правіле ( «Выдаліць JavaScript і CSS блокаторы») важнасці ў верхняй частцы старонкі і як дызайн і распрацоўка вэб-сайце павінен аблегчыць прадастаўленне без загрузкі ўсёй старонкі і ўсёй звязаныя з ім рэсурсы (уключаючы JavaScript і CSS файлы лісця).

Але акрамя ліквідацыі JavaScript і CSS-блокаторы, мы павінны арганізаваць ўтрыманне вэб-сайта на:

1. Спампаваць у самыя кароткія тэрміны на ўсё змесціва верхняй часткі. Гэта азначае, што мы павінны гарантаваць, што ўсе элементы, якія адлюстроўваюцца ў ім займаюць найменшы магчымы памер (асабліва выявы).
2. Трымаеце на вяршыні дынамічнага змесціва адлюстроўваецца, то ці прадастаўляюцца трэцімі асобамі (напрыклад , паведамленні ў сацыяльнай сетцы) або ў уласнасці фішкі (напрыклад , нядаўнія паведамленні нашага блога), так як яны патрабуюць дадатковых злучэнняў для выпуску, з наступнай затрымкай.

Такая рэарганізацыя можа таксама ўключаць у сябе CSS. Файл стылю павінен быць загружаны цалкам, перш чым пачаць апрацоўку старонкі. Калі гэты файл быў занадта вялікім, затрымка рэндэрынгу зверху, але выкарыстаць толькі невялікая колькасць стыляў.

У гэтым выпадку рашэнне будзе выдаліць код CSS, які выкарыстоўваецца для ўтрымання ў верхнім і ўставіць яго непасрэдна ў ( «инлайн CSS») старонкі. Ёсць дапаўненні ( Autoptimize які пракаментаваў) і інструменты якія могуць дапамагчы ідэнтыфікаваць і выдаліць CSS з верхняй частцы старонкі, але толькі рэкамендаваць яго для тых, хто мае дастатковыя веды CSS, таму што канфлікты і залежнасці, каб вырашыць адзін да аднаго можа адбыцца.

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

Скарачэнне часу водгуку сервера

Хостынг хуткага сервера для вашага сайта

Гэтая лінейка вымярае, як доўга ён прымае наш хостынг сервера для адказу на запыт. Google усталяваны як з ідэальным значэннем часу менш чым 200 мілісекунд адказ (2 дзесятых ў секундзе, час Усэйн Болт праходзіць два метры 😉).

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

Калі мы выкарыстоўваем WordPress (ці іншы кантэнт менеджэр), мы павінны выбраць тэму (ці эквівалент), падмацаваная добрай камандай дызайнераў і распрацоўнікаў. Гэта адзіны спосаб гарантаваць, што не бярэ на сябе дрэнныя практыкі, нявыгаднае час водгуку сервера. Роўнае ўвага павінна быць, калі мы набіраем каманду, каб праектаваць і развіваць наш сайт як.

З іншага боку, не варта чакаць, каб атрымаць добрыя вынікі ў гэтым правіле, калі хостынг-правайдэры належаць на «нізкай кошту» або бясплатна: яны танныя (або бясплатна) для чагосьці. Акрамя таго, у выпадку якіх-небудзь праблем, тэхнічная падтрымка часта павольна і неэфектыўна (ці проста не існуе або павінен быць заключаны асобна).

Наём добры хостынг - правайдэра , гэта не выдаткі , а інвестыцыі і гарантыя. У сувязі з гэтым, я меў досвед працы з некалькімі пастаўшчыкамі, і для маіх вэб-сайтаў, іншых спецыялістаў, а таксама лепшы вынік я атрымаў Webempresa і Raiola сеткі У абедзвюх выпадках з хуткай і эфектыўнай падтрымкай, якую я наведваў і вырашаныя любыя пытанні ці праблемы , у працягу некалькіх хвілін, і я рэкамендую без ваганняў. У наступных спасылках вы можаце праверыць свае паслугі прапануюць спецыяльныя зніжкі 20%:

Для Webempresa, неабходна ўвесці код «cupon20» для таго, каб скарыстацца вашай зніжкай:

высновы

Хоць ёсць шмат дыягнастычных інструментаў для ацэнкі прадукцыйнасці вэб - сайта , каб зрабіць якое - небудзь паляпшэнне або аптымізацыю даклад павінен засяродзіцца на справаздачы аб ацэнцы PageSpeed Insights ад Google.

Далёка не самы поўны і падрабязны дыягнастычны інструмент Google выкарыстоўвае яго ў якасці на фактар арганічнага пазіцыянавання вэб - сайтаў. Такім чынам, наш прыярытэт ідзе вырашыць хоць бы негатыўны ўплыў гэтай справаздачы (у чырвоным) і, наколькі гэта магчыма, большасць папярэджанняў (аранжавага колеру).

Справаздача складаецца загрузкі старонак з дзесяці правілаў, але можа быць размеркаваны на тры групы, у залежнасці ад ступені складанасці яе дазволу і тэхнічнай падрыхтоўкі, неабходнай для іх рашэнняў:

• Абавязкова патрабуе вонкавага абслугоўвання: сервер часу водгуку (адно з правілаў , якія могуць больш негатыўна штрафаванне нашай пазіцыі).
• Гэта патрабуе адносна перадавой (або наймаць паслугі) досвед: Выдаліце JavaScript і CSS рэндэрынгу адреноблокаторов, прыярытэт бачнага змесціва.
• Яна патрабуе базавых тэхнічных ведаў: Пакажыце кэш браўзэра, пазбегнуць перанакіравання на мэтавыя старонкі, Уключыць разуменне, Мінімізаваць HTML, CSS і JavaScript ( з дапамогай убудоў), аптымізацыя выявы.

З улікам гэтых меркаванняў, наша стратэгія аптымізацыі прадукцыйнасці вэб - сайта будзе ўключаць у сябе наступныя крокі:

1. Наём надзейнага хостынгу сервера, якасці і хуткая і эфектыўная падтрымка. Гэта значыць, не бясплатнае жыллё або смяхотна нізкія цэны.
2. Стварэнне вэб - сайта, або выбраць WordPress тэму, адэкватна прыярэтызацыі бачнае ўтрыманне і выдаліць JavaScript і CSS - блокаторы. Бо выправіць постфактум, з ужо ўбудаваным вэб-сайта, гэта можа быць вельмі цяжка ці немагчыма.
3. Памяншэнне колькасці убудоў або дадаць кантэнт - мэнэджэра, так як яны , як правіла, ўключаюць у сябе JavaScript і CSS файлы , якія могуць выклікаць праблемы для правілаў relalacionadas.
4. Вядома, заўсёды, выконваць па правілах , якія не патрабуюць перадавых тэхнічных навыкаў, і ўключаюць іх у нашых лепшых практыках для абслугоўвання сайта.

Паведаміць аб памылцы ў Google PageSpeed Insights часам патрабуецца , каб аналізаваць і вырашаць мноства выпрабаванняў , каб атрымаць. Якая стратэгія ў вас прытрымлівацца , каб вырашыць іх ? Карыстаецеся Ці вы які - небудзь іншы дыягнастычны інструмент для выяўлення прычын ўзнікнення праблем? Што?

малюнка: Freepik , IconFinder , Ўласныя разлікі.

Ці мае пост вы апынуліся карыснымі? Дапамажы мне, каб палепшыць і ацаніць яго!

[Да гэтага часу 20 прагаласаваў, з сярэднім балам 4,5]

Seo іншыя паведамленні , якія могуць зацікавіць кольцы