Ответ 1

Чтобы прямо ответить на вопрос, нет, это не невозможно получить быстрый ярлык FCP. Там больше к вопросу, поэтому я попытаюсь уточнить.

Другой способ сформулировать "быстрые" критерии: "Есть ли у как минимум 90% опыта пользователя FCP менее 1 секунды?"

Почему 90%? Потому что это включает в себя огромную долю пользовательского опыта. Как говорят документы PSI :

Наша цель - убедиться, что страницы хорошо работают для большинства пользователей. Сосредоточив внимание на значениях 90-го и 95-го процентиля для наших метрик, это гарантирует, что страницы соответствуют минимальному стандарту производительности в самых сложных условиях устройства и сети.

Почему 1 секунда? Это субъективное значение того, как быстро пользователи ожидают, что страница начнет показывать значимый прогресс. Через 1 секунду пользователи могут отвлекаться или даже расстраиваться. Конечно, Святой Грааль должен иметь мгновенную загрузку, но это выбрано в качестве реалистичного ориентира, к которому нужно стремиться.

Так что в худшем случае 10% опыта FCP составляет 1 секунду или медленнее. Этот конкретный вид гарантии - достаточно высокая планка, чтобы быть уверенным в том, что пользователи постоянно получают быстрый опыт.

Это объясняет, почему панель установлена там, где она есть. На вопрос о том, насколько реалистично это достичь, мы можем ответить на этот вопрос, используя общедоступные данные CrUX на BigQuery.

#standardSQL
SELECT
  p90,
  COUNT(0) AS numOrigins
FROM (
  SELECT
    origin,
    MIN(start) AS p90
  FROM (
    SELECT
      origin,
      bin.start,
      SUM(bin.density) OVER (PARTITION BY origin ORDER BY bin.start) AS cdf
    FROM
      'chrome-ux-report.all.201901',
      UNNEST(first_contentful_paint.histogram.bin) AS bin)
  WHERE
    cdf >= 0.9
  GROUP BY
    origin)
GROUP BY
  p90
ORDER BY
  p90

Это запрос, который подсчитывает, где в источниках гистограммы FCP есть 90-й процентиль. Если это звучит странно, вот визуализация:

Там, где красная кумулятивная линия распределения пересекает отметку 1000 мс, показывает нам процент происхождения, который будет помечен как быстрый. Это не очень много; только 2% или 110153 происхождения в наборе данных.

Кстати, просматривая список источников "быстрого FCP", многие из них имеют TLD .jp и .kr. Разумно предположить, что это локализованные японские и корейские сайты, пользователи которых почти полностью находятся в этих странах. И это страны с высокой скоростью интернета. Поэтому, естественно, было бы проще обслуживать быстрый веб-сайт 90+% времени, когда у ваших пользователей стабильно быстрая скорость соединения.

Еще одна вещь, которую мы можем сделать, чтобы почувствовать популярность происхождения, - присоединиться к нему в списке Alexa Top 1 Million Domains:

#standardSQL
SELECT
  Alexa_rank,
  Alexa_domain,
  COUNT(0) AS numOrigins,
  ARRAY_AGG(origin LIMIT 3) AS originSample
FROM (
  SELECT
    origin,
    MIN(start) AS p90
  FROM (
    SELECT
      origin,
      bin.start,
      SUM(bin.density) OVER (PARTITION BY origin ORDER BY bin.start) AS cdf
    FROM
      'chrome-ux-report.all.201901',
      UNNEST(first_contentful_paint.histogram.bin) AS bin)
  WHERE
    cdf >= 0.9
  GROUP BY
    origin)
JOIN
  'httparchive.urls.20170315'
ON
  NET.REG_DOMAIN(origin) = Alexa_domain
WHERE
  p90 < 1000
GROUP BY
  Alexa_rank,
  Alexa_domain
ORDER BY
  Alexa_rank

Существует 35985 источников, чьи домены находятся в топе 1M. Вы можете запустить запрос для себя, чтобы увидеть полные результаты.

Вы можете видеть, что есть ~ 100 источников в 20 лучших доменах, которые соответствуют критериям FCP. Подбирая несколько интересных примеров ниже по списку:

• [# 139] https://mobile.alibaba.com
• [# 178] https://www.google.se
• [# 422] http://www.design.samsung.com
• [# 744] http://taxes.ca.gov

Большое предостережение о том, что это происхождение не обязательно занимает первое место, просто их домены. Без данных о происхождении это лучшее приближение, которое я могу сделать.

Меньше предостерегаем, что BigQuery и PSI - это несколько разные наборы данных и сегменты PSI для настольных компьютеров и мобильных устройств, в то время как мой анализ объединяет их. Так что это исследование не является идеальным представлением того, чего ожидать от PSI.

Наконец, я просто хочу обратиться к чему-то еще, что было в вопросе о получении 100 баллов в Lighthouse. 100 баллов не обязательно означают, что улучшать нечего. Подобные синтетические тесты необходимо калибровать, чтобы они отражали реальный пользовательский опыт. Так, например, аудит эффективности может начать проваливаться, если его тестировать в условиях, представляющих пользовательский опыт на Филиппинах. На самом деле запуск теста из этого места может вызвать проблемы с производительностью, например, проблемы с распространением контента, в дополнение к условиям, которые мы могли бы смоделировать в любом месте, например, скорость соединения.

Подводя итог все:

• Полоса установлена высоко, потому что мы хотим, чтобы подавляющее большинство пользователей работало быстро
• Многие веб-сайты уже превышают эту планку, хотя и составляют небольшую долю от общего набора данных
• Рейтинг Alexa показывает нам, что возможно иметь сайт с интенсивным трафиком, а также обеспечивать стабильно быстрый опыт

Ответ 2

Вы неправильно интерпретируете результаты Google Gighthouse. Прежде всего, ни один тест производительности не является абсолютным. Невозможно получить полностью 100% работоспособную страницу просто потому, что даже если она загружается за 1 секунду для меня, она может не загружаться за 1 секунду для человека в Гане из-за проблем с сетью и задержек. Даже если у меня есть чистая HTML-страница без javascript, которая используется в качестве статического файла с супербыстрого веб-сервера, эта страница может загрузиться через 10 секунд для человека с подключением к Интернету где-то на Кубе или Ямайке.

Интенсивный трафик просто означает, что "я получаю трафик не только из США или Европы, где интернет быстро распространяется, я также получаю трафик с Ямайки, где скорость интернета - шутка". У каждого серьезного веб-приложения есть эта проблема. Так что да, есть мало возможностей для улучшения, потому что вы все делаете правильно - это проблема локального Интернета.

Я предполагаю, что это немедленно переводит на социологическую/политическую проблему мышления "первой мировой проблемы". Вы, очевидно, живете в стране первого мира или, по крайней мере, имеете 3G/4G интернет, и вы не можете себе представить, что люди на Ямайке имеют 2G интернет. Так что не волнуйтесь о процентах маяка. Сделать веб-сайт полностью работоспособным, который загружается менее чем за 1 секунду в любой точке земного шара, невозможно из-за технических ограничений этой страны - вы не можете это исправить.

Ответ 3

  Будет ли страница, подобная nytimes.com, когда-либо считаться быстрой с этим стандартом, когда даже страница на рабочем столе google.com будет ранжироваться медленно на основе полевых данных?

Ответ: ДА, абсолютно.

Я понимаю твое замешательство. Это вызвано ложным предположением, что у Google есть хорошо работающий веб-сайт. Обратите внимание, что домашняя страница Googles смехотворно велика. Один только HTML более 200 КБ. Javascript, который он загружает, весит 436 КБ. Общий вес страницы превышает 1 МБ. И что мы видим на этой странице? Совершенно ничего. Это буквально пустая белая страница. Один мегабайт - это объем кода, который может заполнить 500 страниц книги. Код в этих двух романах о Гарри Поттере должен быть выполнен вашим браузером, как только вы загрузите эту пустую страницу.

Просто чтобы дать вам еще одно представление о том, насколько это велико: у меня есть агентство веб-разработок в Амстердаме, и мой веб-сайт (главная страница) такой же пустой, как и эта страница Google. Однако он весит всего 41 КБ (включая совершенно ненужный файл шрифта woff2, который занимает 17 КБ).

Когда вы подключаетесь к домашней странице Google с помощью обычного соединения 3G, загрузка страницы занимает более 3,5 секунд. Подумайте, что это значит для людей на Ямайке или на Кубе! У них практически не будет доступа к Google на рабочем столе или, по крайней мере, будет очень плохо. Для сравнения: мой сайт загружается за 0,7 секунды по сравнению с обычным 3G. Важно знать, что размер является основным фактором, влияющим на скорость, когда у вас медленный интернет (это половина мира).

Итак... домашняя страница Google на рабочем столе - очень плохой пример и более чем заслуживает своей низкой (скорости) оценки. Нью-Йорк Таймс легко может получить лучший результат, просто уменьшив вес своих страниц ниже веса главной страницы Google.

Оценка производительности по сравнению с FCP

В последний раз, когда я проверял (в начале февраля 2018 г.), Desktop google.com получил синтетическую оценку 100 Lighthouse, которая должна интерпретироваться как "мало места для улучшения", и все же страница оценивается как "медленная", поскольку 90-й процентиль FCP - более 3 секунд.

В приведенной выше части вы соотносите счет 100 с FCP. Это не так просто (больше). Оценка производительности - сложный показатель. Это взвешенное среднее из приведенных ниже переменных (обратите внимание, что FCP больше не является частью этого).

Первая значимая краска - вес: 5
Первый интерактив - вес: 5
Постоянно интерактивный - вес: 5
Метрика индекса скорости - вес: 1
Расчетная задержка ввода - вес: 1

Обратите внимание, что интерактивной странице Google требуется 3,5 секунды (по данным Lighthouse). Тем не менее, в настоящее время он по-прежнему набирает 97 баллов по производительности из-за способа расчета метрики, что по меньшей мере примечательно. Это подтверждает, что (около) 100 баллов может быть обманчивой цифрой.