Google PageSpeed Insights кардинально оновився, що зміниться? PageSpeed Insights: швидкість завантаження як фактор ранжування Приблизний час затримки під час введення.

Здрастуйте, шановні читачі блогу сайт. Сьогодні хочу поговорити з вами на таку важливу тему як швидкість завантаження сайту. Напевно, ви вже всі чули, що поряд з безліччю інших факторів, що впливають на просування Web проекту, пошукові системи з недавніх пір стали враховувати ще й це. Та й відвідувачів гальма на сайті сильно дратують, особливо тих, хто звик.

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

Онлайн сервіси для вимірювання швидкості завантаження сайту

Принаймні саме так я ставився донедавна до того, щоб спробувати прискорити свій ресурс. Але мені спало на думку, що краще не чекати неприємних тенденцій (а саме зменшення трафіку з , бо вона більш критично відноситься до швидкості завантаження), а виправити очевидний недолік прямо зараз.

Потрібно просто усвідомити, що швидкість, з якою завантажується ваш сайт, блог або форум, є дуже важливим показником. Якщо у вашого проекту з цим показником не все гаразд, то це може спричинити досить неприємні наслідки. І найважливіше те, що відвідувачі можуть відмовитися від роботи з вашим ресурсом, т.к. він дуже довго підвантажує сторінки. Крім цього пошукові системи, особливо Google, враховують її при загальній оцінці корисності того чи іншого ресурсу.

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

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

В результаті буде представлена діаграма часу завантаження окремих об'єктів вебсторінки, а також їх Урл і вага. Чим менше об'єктів завантажуватиметься і чим легше буде важити кожен з них, тим краще. Наприклад, я для цієї мети:

об'єднав деякі картинки з теми оформлення сайту

а також наскільки можна зменшив шляхом

крім цього є сенс

Власне деякі проблеми та історію вимірювання швидкості вашого сайту ви зможете відстежити на сусідніх вкладках верхнього меню Pingdom.

У спливаючому вікні вам запропонують скопіювати постійне посилання на виконаний тест, а також відправити його по e-mail або Twitter. Також у нижній частині вікна можна підписатися на предмет доступності. Якщо ваш ресурс впаде (стане недоступним для відвідувачів), то вам буде надіслано повідомлення на e-mail або SMS на стільниковий. Але ця послуга є платною, хоча є можливість безкоштовного тріалу.

Для вашого сайту, а також для перегляду Traceroute, потрібно буде вибрати у верхній частині сторінки вкладку «Ping and Traceroute». Вводьте в пропоновану форму Урл без http, ставте галочку в чекбокс Traceroute або Ping під цією формою, і тиснете Test now.

WebPageTest — як завжди, введіть Урл сторінки, що перевіряється (не обов'язково головною). Сервіс деякий час обраховує швидкість завантаження всіх елементів сайту, після чого видає дуже наочну діаграму (точніше, навіть дві — за перший прохід і за другий, коли вже частина елементів сайту завантажуються з кеша браузера):

На першій діаграмі приділяєте увагу положенню фіолетової вертикальної лінії – це буде час закінчення відтворення сайту. Друга вертикальна лінія (синя) означатиме час повного завантаження. Добре, якщо перша лінія знаходиться на 1-1,5 секунд завантаження сайту, а друга - раніше 4 секунд. Тоді наступні абзаци можна прочитати для довідки. Якщо сайт завантажується довше 4 секунд - то потрібно перейматися виправленням цієї ситуації.

Google PageSpeed Insights – це інструмент для розробників від самого Гугла. Він дає оцінку швидкості завантаження вашого сайту (а точніше оптимізації цієї швидкості) за стобальною шкалою. 100 - це ідеал, який недосяжний, а ось 80-90 отримати цілком реально, тим більше, що сервіс дає дуже докладні рекомендації щодо виправлення виявлених недоліків.

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

Але найголовніше те, що Google PageSpeed Insights дає рекомендації, як збільшити оцінку вашого сайту, тобто. як його пришвидшити. Починати треба, звичайно, з самого верху, бо ці виправлення зроблять найбільший внесок у прискорення.

У мене, наприклад, була проблема з налаштуванням gzip стиснення та із завданням часу кешування статики (картинок, css файлів і скриптів) у браузерах користувачів, бо у мене Апач працює у зв'язці з nginx, а з ним я працювати не вмію. Довелося писати в техпідтримку Інфобокса з проханням все налаштувати — зробили, і навіть грошей не взяли (дякую їм!). До речі, спочатку вони мені поставили час зберігання кешу в 1 годину, але Google PageSpeed Insights, як і раніше, лаявся:

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

Test my Site - новий сервіс знову ж таки від Гугла. В основному він наголошує на оцінці мобільної версії вашого сайту в тому числі і за критерієм його швидкості завантаження:

Просто і зі смаком, що називається. Можна передплатити розсилку змін.

GTmetrix - знову ж таки «не мудруючи лукаво» вводите Урл потрібної сторінки і трохи чекаєте закінчення аналізу. В результаті ви отримаєте звіт, сформований на основі даних двох плагінів для браузерів - Page Speed (читайте про роботу з ним нижче) та YSlow. Власне, яким даним довіряти і чиїм рекомендаціям слідувати — вирішувати вам.

Про те, я вже досить докладно писав і тому не буду повторюватися, щоб не захаращувати і без того вже громіздку статтю (дочитаєте до кінця — можете вважати себе героєм).

Ping Admin - аналогічний онлайн ресурс для вимірювання час відповіді сервера з різних куточків нашої величезної планети.

Host Tracker - практично те саме, тільки країни інші.

ByteCheck дозволяє виміряти значення TTFB (Time To First Byte) для вашого сайту, на який часто звертають увагу при оптимізації. Це час отримання першого байта даних браузером із сервера. Що значення TTFB, то повільніше обробка ресурсів сервером, що погано. Читайте поради щодо оптимізації завантаження сайтів.

Load Impact - це не зовсім про швидкість, але теж важливий сервіс. Він дозволяє протестувати здатність навантаження вашого сайту і те, чи при цьому падає швидкість завантаження сторінок. Дуже корисна штука.

Web Page Speed — онлайн-сервіс з дизайном початку дев'яностих, але цілком такий інформативний, якщо пристосуєтеся до відсутності юзабіліті. Внизу даються загальні рекомендації щодо виправлення ситуації.

Чи важливо відстежувати швидкість завантаження сторінок?

Але повернемося від виміру швидкості до пошуку можливостей її збільшення. , Раніше працювала експериментальна вкладка «Ефективність сайту», де давалася оцінка швидкості завантаження сайту.

Загалом нічого кримінального у зазначеній там швидкості завантаження немає, але те, що мій блог сайт завантажувався повільніше, ніж 84 відсотки всіх web ресурсів в інтернеті - це вже дзвіночок, на який слід було б відреагувати. Але раз Гугл думає, що за швидкістю мій блог є аутсайдером, то варто всерйоз поставитися до цієї проблеми і впритул зайнятися вирішенням питання — як її збільшити.

Власне, нічого особливо вигадувати не довелося, бо Google сам підказує найбільш оптимальне рішення. Точніше, він пропонує скористатися інструментом, який допоможе зрозуміти, що саме потрібно зробити для того, щоб ваш сайт трохи (або багато) прискорити. Я говорю про онлайн-сервіс Page Speed (раніше були ще й однойменні розширення для браузера FireFox і Хром, якими я в основному користувався).

Відразу зазначу, що цей інструмент оперує досить складними і не зовсім зрозумілими речами пересічним вебмайстрам, які пов'язані з тонкощами і нюансами роботи Web сервера. Якщо ви ніколи не адміністрували сервер, але буде складно.

Є вихід – напружити вашого хостера на тему виконання дій, які наказує Пейдж Спід. Чи погодиться чи ні — це вже інше питання. я так і не наважився, бо стрімко надавати доступ до сервака аби кому (ось такий я недовірливий).

На головній сторінці PageSpeed навіть пропонує встановити модуль на свій сервер, якщо він працює під керуванням Apache або Nginx (якраз мій випадок):

Але я так і не зрозумів, як це робиться, бо зовсім не тямлю в адмініструванні серверів і ніколи не працював з юнікс подібними системами. Це набагато складніше, ніж встановити програму або плагін в WordPress залити. Інший рівень занурення. Хостера теж не наважився з цього приводу напружувати. Загалом цей модуль залишився мною не випробуваний — можливо, що ви його вже спробували і має місце що сказати.

Взагалі, вперше я використав Page Speed як розширення для браузера (зараз воно, як я зрозумів, не функціонує). Раніше воно інтегрувалося в інструменти для розробників у Фаєрфоксі та Хромі. Правда, попервості (кілька років тому) я лише миттю подивився які поради він мені дає, і практично нічого не зрозумівши вирішив, що це не для мене, після чого з легкою душею видалив плагін PageSpeed як не потрібний і чужий для мого розуму елемент.

Справа в тому, що навіть розуміючи на що лається цей плагін, я до ладу не знав, що потрібно зробити, щоб усе це усунути і хоч якось прискорити свій блог. Загалом, у мене знайшлося відразу дуже багато важливіших справ, порівняно з якими мишача метушня з налаштуваннями Web сервера (тим більше, що я в них і не розуміюся особливо) здалася дрібною і несуттєвою.

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

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

P.S. Зараз Page Speed можна використовувати тільки онлайн і встановлювати його в браузер вже не потрібно (принаймні з новими версіями хрому цей плагін несумісний), хоча суті це не змінює.

Отже, раніше потрібно було встановити у свій браузер плагін, але зараз достатньо перейти сюди, ввести Урл адресу сторінки, яку ви хочете проаналізувати (на різних типах сторінок можуть виникати різні проблеми зі швидкістю завантаження, тому в цьому інструменті є сенс перевіряти всі варіанти) і натиснути на синю кнопку "Аналізувати".

Дочекавшись результатів процесу перевірки ви побачите вікно подібне до того, що я вже приводив на скріншоті вище за текстом (у пункті 3 описів онлайн сервісів з перевірки швидкості завантаження сайтів). Т.о. в результаті ви побачите цілий список претензій, які цей онлайн-сервіс має до вашого ресурсу, а саме до швидкості його завантаження. При цьому він дасть вам деякі вказівки щодо оптимізації роботи Web сервера в поєднанні з використовуваним вами двигуном.

Причому в самому верху вікна Page Speed будуть розташовані зауваження та рекомендації, які вам бажано буде подивитися і змінити в першу чергу («виправте обов'язково»), бо це дасть найбільший ефект у плані збільшення швидкості завантаження і вимагатиме від вас невеликих зусиль. Наведу приклад аналізу одного з моїх другорядних проектів, яких руки особливо не доходять:

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

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

У мене початкова картина кілька років тому (ще при використанні плагіна — зараз те саме можна побачити в http://gtmetrix.com/, бо він використовує API PageSpeed) для https://сайт була така:

Я вирішив тоді почати з першого пункту «Leverage browser caching» (зараз це називається «Використовуйте кеш браузера» ), бо за логікою роботи Page Speed, ці рекомендації повинні привести до найбільшого прискорення мого блогу.

Якщо натиснути на спойлер поруч із цим написом, то з'явиться список різних файлів, які не задовольняють оптимальним вимогам кешування статичних об'єктів (скрипти, файли CSS, файли зображень, що використовуються на web сторінці) в браузерах користувачів (тобто у читачів):

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

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

Оптимізація кешування у браузері та перевірка його роботи

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

Загалом ми спробуємо вплинути на сервер де хоститься ваш проект таким чином, щоб він віддавав браузерам команди спрямовані на оптимізацію кешування статичних елементів. Робити це будемо за допомогою відомого інструменту віддаленого керування сервером — файла.htaccess. Чи знаєте про існування такого?

Живе він зазвичай у кореневій папці. Природно, що все нижчеописане працюватиме тільки на серверах під керуванням Apache, але їх зазвичай більшість. Після підключення до свого ресурсу по FTP (), відкрийте кореневу папку (зазвичай це PUBLIC_HTML, або HTDOCS) і перевірте наявність в ній файлу.htaccess.

З цього моменту ви все робите на свій страх та ризик. Тому обов'язково скачайте на комп'ютер копію цього файлу, щоб у разі чого оперативно відкотитися назад.

Якщо .htaccess не видно, спробуйте у програмі FileZilla вибрати з верхнього меню пункти «Сервер» — «Примусово відображати приховані файли». Якщо і після цього він докорінно не проявився, то створіть у себе на комп'ютері порожній текстовий файл у будь-якому зручному для вас редакторі (я користуюся Нотепад плюс плюс), назвіть його якось і скопіюйте в корінь.

Після цього перейменуйте файл в.htaccess у програмі FileZilla. Тепер потрібно буде відкрити його на редагування і додати до нього наведений нижче код. Але спочатку трохи поясню.

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

Спочатку наведу код для модуля mod_headers. Звертаю вашу увагу, що використовується перевірка наявності у вашого хостера даного модуля. Якщо його знайдено не буде, код виконуватися не буде і жодних помилок це не викличе. Однак, я ще раз рекомендую попередньо скопіювати оригінальний (до внесення розташованого нижче коду) файл.htaccess до себе на комп'ютер, щоб уникнути ексцесів.

#кешувати html і htm файли на один день Header set Cache-Control "max-age=43200" #кешувати css, javascript і текстові файли на один тиждень місяць Header set Cache-Control "max-age=2592000" #вимкнути кешування Header unset Cache-Control

Коментарі (їх рядки починаються зі знака решітки) потім можете видалити, але вони будь-якою на роботу коду впливу не будуть.

Можна ще додати блок коду, розрахованого на модуль для mod_expires , де знову ж таки використовується перевірка його наявності на вашому сервері, що гарантує безпеку використання цього фрагмента коду:

ExpiresActive On #за замовчуванням кеш в 5 секунд ExpiresDefault "access plus 5 seconds" #кешувати флеш і зображення на місяць ExpiresByType access plus 2592000 seconds" ExpiresByType image/gif "access plus 2592000 seconds" ExpiresByType application/x-shockwave-flash "access plus 2592000 seconds" ExpiresByType text/javascript "access plus 604800 seconds" ExpiresByType application/javascript "access plus 604800 seconds" ExpiresByType application/x-javascript "access plus 604800 seconds" #кешування " #кешувати xml файли на десять хвилин ExpiresByType application/xhtml+xml "access plus 600 seconds"

Коментарі знову ж таки потім можна буде видалити.

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

ExpiresActive On ExpiresByType application/javascript "access plus 1 year" ExpiresByType text/javascript "access plus 1 year" ExpiresByType text/css "access plus 1 year" ExpiresByType image/gif "access plus 1 year" ExpiresByType image/jpeg "access year" ExpiresByType image/png "access plus 1 year"

Header set Cache-control: private Header set Cache-control: public

BrowserMatch "MSIE" force-no-vary BrowserMatch "Mozilla/4.(2)" force-no-vary

FileETag MTime Size ExpiresActive on ExpiresDefault "access plus 1 month"

Тепер після того, як ви вставили в.htaccess код, що дозволяє підвищити швидкість за рахунок оптимізації кешування в браузері на стороні відвідувача, і зберегли зроблені зміни, знову перевірте сторінку вашого ресурсу в PageSpeed Insights і переконайтеся, що проблема зникла.

Як бачите, у моєму випадку «Використовуйте кеш браузера» вже не є критичною недоробкою, що уповільнює завантаження, і значок поруч із цим зауваженням змінився на помаранчевий, але не на зелений. На жаль, вплинути на сторонні сервіси, звідки мій сайт підвантажує статики (типу Янедкс, Гугла, Фідбернер і Аптулайка), я не в змозі.

Що й потрібно було довести. Ось так граючи ми з вами розібралися з однією з найістотніших і найвагоміших проблем знайдених у Page Speed.

Як увімкнути стиснення статичних об'єктів на сервері

Також дуже частою проблемою, на яку лається сервіс GTmetrix, буває відсутність стиснення файлів на сервері перед передачею їх у браузери користувачів.

Використовується при цьому, про який я вже писав. Якщо ви аналізуєте не безпосередньо через PageSpeed Insights, а за допомогою GTmetrix, то в області PageSpeed «Включити стиск» називається «Enable gzip compression», а YSlow - «Compress components with gzip».

Для того, щоб цей самий Gzip стиск включити на хостингах, де використовується сервер Апач, достатньо буде додати файл.htaccess (він є дистанційним файлом управління сервером) відповідний фрагмент коду. Апач має два модулі для стиснення і який-небудь з них буде встановлений у вашого хостера (хоча не факт).

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

AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/css text/javascript application/javascript application/x-javascript

Трохи менш популярним і для нього код включення Gzip стиснення для потрібних типів файлів виглядатиме так:

mod_gzip_on Yes mod_gzip_dechunk Yes mod_gzip_item_include file \.(html?|txt|css|js|php|pl)$ mod_gzip_item_include mime ^text\.* mod_gzip_item_include mime ^application/x-ja _gzip_item_exclude rspheader ^ Content-Encoding:.*gzip.*

Власне, спробуйте та перевіряйте сторінку в PageSpeed Insights після встановлення коду. Якщо проблема зникла, то вважайте, що вам пощастило. Мені ж через наявність Апач з nginx все це не допомогло (хостер сказав, що за статику відповідає nginx, при такому розкладі і налаштовувати треба саме його — як він це зробив мені невідомо).

Удачі вам! До швидких зустрічей на сторінках блогу сайт

Вам може бути цікаво

Вимірювання та збільшення швидкості сайту в GTmetrix, а також налаштування завантаження бібліотеки jQuery з Google CDN
Gzip стиск для прискорення завантаження сайту - як його увімкнути для Js, Html та Css за допомогою файлу.htaccess
Як збільшити швидкість завантаження сайту по максимуму та оптимізація навантаження на сервер
Прискорення сайту – що дає, як виміряти і як самому прискорити сайт
Створення CSS спрайтів в онлайн-генераторі Sprites Me для зниження кількості запитів до сервера
Оптимізація та стиснення CSS у Page Speed - як відключити зовнішні файли стилів та об'єднати їх в один для прискорення завантаження
Як отримати швидкий сайт - оптимізація (стиснення) зображень та скриптів, а також зменшення числа Http запитів

PageSpeed Insights (PSI) повідомлень на виконання сторінок на стільникових мобільних телефонах і робочих місцях, і повідомлень про suggestions на тому, що сторінка може бути improved.

PSI дає змогу бути лабораторними і польовими даними про сторінку. Lab data is useful for debugging performance issues, as it is collected in a controlled environment. However, it mai не capture real-world bottlenecks. Field data is useful for capturing true, real-world user experience - але має більше обмеженого набору метриків. See for more information on the 2 types of data.

Performance score

На top of the report, PSI дає змогу виразити, які сумісні page's performance. Цей показник визначається за виконанням повідомлень і analyze про сторінку. Значення показника 90 або більше, що розглядається, а 50 - 90, вважається граничним. Below 50 is considered to be slow.

Real-World Field Data

Якщо PSI є на URL, це буде йти до (CrUX) dataset. Якщо наявні, PSI повідомлень (FCP) і (FID) метричні дані для оригіналу і потенційно конкретну сторінку URL.

Classifying Fast, Average, Slow

PSI також classifies field data в 3 ящики, що показують випробування поглинені швидким, скороченням, або повільним. PSI натисніть на наступні трехholds для швидкий / average / slow, заснований на нашому аналізі з CrUX dataset:

Fast Average Slow

FCP		(1000ms, 2500ms)	over 2500ms
FID		(50ms, 250ms)	over 250ms

Загалом розмовляють, швидкі сторінки є сильно в верхній ~10%, середні сторінки є в 40%, а низькі сторінки є внизу 50%. Номери мають бути закрученими для readability. Ці Thresholds apply to both mobile and desktop and have been set based on human perceptual abilities .

Distribution and selected value of FCP and FID

PSI становлять розповсюдження цих метрів так, що розробники можуть піддаватися рівню FCP і величини FID для того, що сторінка або початок. Ця distribution є також split в трьох категоріях: Fast, Average, і Slow, покриті green, orange, і red bars. Для прикладу, розміщення 14% при FCP "з орієнтовною точкою оцінки, що 14% всіх зареєстрованих FCP цін на 1,000мс і 2,500мс. Це дані становлять агрегативний перегляд всіх сторінок навантаження за попередні 30 днів.

Забороняючи розповсюдження bars, PSI reports 90th percentile First Contentful Paint and the 95th percentile First Input Delay, presentd in seconds and milliseconds respectfully. Ці проценти є такими, що розробники можуть піддаватися найбільшим frusttrating user experiences on their site. Ці сфери метрових рівнів є classified as fast/average/slow by applying the same thresholds shown above.

Field data summary label

На overall label is calculated from the field metric values:

Fast: If both FCP and FID є Fast.
Slow: If any either FCP або FID is Slow.
Average: All other cases.

Differences between Field Data in PSI and CrUX

Відмінність між field data в PSI versus Chrome User Experience Report on BigQuery, є те, що PSI's data is updated daily for trailing 30 day period. The data set on BigQuery є лише updated monthly.

Lab data

PSI використовує Lighthouse для аналізу довжини URL-адреси, що генерують продуктивність відображення того, що вимірюють сторінку" дії на різних метрах, включаючи: , and .

Який field data і lab data contradict each other? Field data says the URL is slow, але the Lab data says the URL is fast!

Поле дата є історичним повідомленням про те, що особливі URL-адреси були виконані, а також anonymized performance data від користувачів в реальному світі на безлічі пристроїв і мережних умов. Lab data є базованою на simulated load of page on single device and fixed set of network conditions. Як результат, значення може бути різним.

Чи є 90-х відсотків chosen для FCP і 95-х відсотків для FID?

Наш список є зробити, що сторінки працюють добре для багатьох користувачів. Використовуючи на 90-х і 95-х процентних значеннях для наших метриків, ці основи того, що сторінки запропонують мінімальний стандарт розв'язання під most difficult device and network conditions.

Які FCP в v4 і v5 мають різні значення?

V5 FCP є на 90% percentile, коли v4 FCP reports median (50%).

What is a good score for lab data?

Any green score (90+) is consideraed good.

Why does the performance score зміни від ходу до ходу? I didn’t change anything on page!

Вірабільність в продуктивності вимірювання є введена за допомогою номера каналів з різними рівнями дії. Середня загальна джерела метичної variability є локальна мережа availability, client hardware availability, і client source contention.

Google PageSpeed ​​Insights кардинально оновився, що зміниться? PageSpeed ​​Insights: швидкість завантаження як фактор ранжування Приблизний час затримки під час введення.

Google PageSpeed Insights кардинально оновився, що зміниться? PageSpeed Insights: швидкість завантаження як фактор ранжування Приблизний час затримки під час введення.