Комментарии 41
Хотя это тоже можно обойти — можно включать блокировку отображения контента, пока отладчик открыт
Можно установить дополнение в FF для реактивации правой кнопки мыши.
То же касается гугловского сервиса PageSpeed Insights, который меряет производительность страницы. Он будет вас распекать за лишние 100 байтов в JPEG картинке и требовать сжать их так, что начинают становиться заметными артефакты на картинках с резкими линиями, которые плохо жмутся JPEG. Но он ни слова не скажет, если вы влепите полмегабайтные PNG картинки или веб-шрифт, который блокирует отображение текста и реально замедляет загрузку в отличие от картинок, которые грузятся в фоновом режиме.
К сожалению, заказчики предпочитают именно хорошие цифры в тесте, а не качественный сайт.
P.S. на счет заказчиков — полностью вас поддерживаю
К сожалению, это вряд-ли когда-то изменится
Есть же куча людей, которые заняты другим (своим бизнесом, например), и у которых к тому же нет способностей к детальному пониманию работы компьютеров, но есть таланты в других областях.
Какой путь будем рекомендовать им? Чтобы это было экономически оправдано.
Тут нужно замерять реальную скорость загрузки сайта причем сервис должен загружать сайт с того же региона, где располагается целевая аудитория на которую ориентирован данный сайт.
И заказчики правильно делают, что распекают за плохие балы в PageSpeed. Вдруг кто-то переступит через свое самомнение и разберется в том, что действительно влияет на производителность страницы, а что является подсказками в направлении что еще можно улучшить.
Делаю краткий ликбез:
1. Google Page SPeed сейчас — это тот же Light House о котором говориться в статье. С немного измененным профайлом оценки ситуации (какой канал используется, какая эмуляция процессора и т.д.)
2. Рекомендации которые пишет PageSpeed, это не ошибки, устранив которые вы получите высокие оценки. Точнее не только ошибки. Современный тест понятия не имеет насколько объективно необходимо загружать мегабайтные изображения. Потому он может только рекомендовать что-то пережать.
3. Величина файла изображения и его формат — это вещи которые на метрики, либо не влияют вообще, либо их фактор влияния в сравнении с прочими — мизерный. Можно иметь страницу с сотней изображений по 15 мегабайт и иметь 90+ в мобильной выдаче.
4. Первостепенную важность для PageSPeed играет скорость формирования первого экрана — достаточной части контента на ней. Которая оценивается — внимание — через анализ ряда скриншотов, в момент от старта, до события window.load +3000мс.
5. Из 4 пункта следует какие метрики определяются как важные и формирующие оценку — скорость ответа сервера, нагрузка на ЦП (JS логика, рендер), наполнение рабочей области контрастными областями которые условно принимаются за главную часть контента.
Все эти метрики — ОБЪЕКТИВНЫ. И действительно определяют скорость формирования страницы. Ошибки случаются только тогда, когда алгоритм неверно выделяет важные области, определяемые как значимый контент в рамках первого экрана. И связано это с контрастом. Который, в случае его недостатка, уже говорит о проблемах с проектом.
Качественный сайт, не может быть без выполнения этих метрик.
За исключением ситуаций, когда аудитория состоит из посетителей, которые ничего кроме этого сайта не посещают. У проекта может быть качественный контент, он может быть удобным с точки зрения использования, но он не может быть проектом который загружается быстро при первом посещении. А это, для Google, который монетизирует трафик из поиска, первейшая характеристика.
Вы явно не работали с Google Page Speed. Пережимание JPG картинок и изменение их размера в моем случае давало значительную часть прироста оценки.
Величина файла изображения и его формат — это вещи которые на метрики, либо не влияют вообще, либо их фактор влияния в сравнении с прочими — мизерный.
Это неверно. Гугл считает, что картинка должна весить X байтов, а у вас она весит Y байтов. При этом картинка, сжатая Гуглом как образец, зачастую имеет артефакты сжатия. Чем больше разница между X и Y, тем больше баллов у вас вычитают. При этом, по крайней мере год назад, когда я оптимизировал сайт под требования Гугла (а не под более быструю загрузку), на PNG картинки он внимания не обращал. То есть Гугл требовал урезать JPG например с 42 до 35 килобайт, но если заменить эту же картинку на 500-килобайтный PNG, то никаких проблем тест не видел. Хотя любому очевидно, что фото в PNG будет грузиться в разы медленнее из-за объема. Также, Гугл ничего не говорил по поводу веб-шритов, которые реально замедляют загрузку сайта. В отличие от картинок, отсутствие которых не мешает читать текст.
Также есть другие трюки, вроде быстро загрузить статическую страницу, а потом медленно аяксом подгружать контент. С точки зрения пользователя, сайт грузится медленее, а очков в тесте он может получить больше.
Несколько советов, которые дает Гугл вообще бредовые — вроде встраивания CSS в тело страницы. Это не позволяет браузеру кешировать CSS код и раздувает страницы. Плюс, это малореалистично оптимально сделать с технической точки зрения.
Еще я помню, у Гугла было дурацкое требование ставить кеширующие заголовки на статику минимум на неделю. Почему именно на неделю, Гугл конечно объяснять не будет, просто какой-то чувак из гугла решил, что так правильно. При этом мы можем смело приписывать к ссылкам на статические файлы случайное число (тем самым отключая кеширование), но Гугл ничего не заметит и даст вам баллы за оптимизацию. Видите, я знаю немало трюков, как можно обмануть этот тест.
Кстати, многие ресурсы Гугла вроде doubleclick имеют время кеширования меньше недели и за их использование тест вас минусует.
Про скорость первого экрана тоже довольно бредовая идея. Пользователю нужен весь сайт, а не первый экран от него.
Также, Гугл наставивает на склеивании файлов, хотя HTTP2 дает хорошую скорость загрузки и без склеивания, и отсутствие склеивания улучшает кеширование файлов и упрощает разработку.
Все эти метрики — ОБЪЕКТИВНЫ.
Объективная метрика всегда поместит сайт с веб-шрифтами и 500-килобайтными картинками в красную зону независимо от числа применяемых оптимизаций.
Вот сейчас я проверил один сайт на Google Page Speed Insight. Знаете, что, по мнению Гугла, даст самый большой выигрыш и ускорит загрузку сайта на целых 3 секунды?
Используйте современные форматы изображений
Для изображений в форматах JPEG 2000, JPEG XR и WebP используется более эффективное сжатие, поэтому они загружаются быстрее и потребляют меньше трафика, чем изображения PNG и JPEG.
То есть Гугл то ли пиарит свой формат картинок WebP, то ли просто дает рекомендации из стандартного списка. Даже дураку очевидно, что самую большую оптимизацию тот сайт получит, отключив веб-шрифты (которые Гугл в упор не видит, хотя я сразу увидел эту проблему по скриншотам, на которых в начале нет текста, а Гугл глупый, он этого не видит), так как картинки не критичны для отображения контента и разница между JPEG и WebP в районе десятка процентов, и никак заметно не скажется на времени загрузки сайта.
Вообще, конечно, страница того сайта весит более 4 Мб и правильнее всего было бы переделать ее с нуля, а не заморачиваться с экзотическими форматами или "отложенной загрузкой CSS кода, который не нужен для отображения первого экрана". Гугл дает советы, выполнить которые технически сложно, а реального выигрыша они дают мало или не дают вообще. Совет про первый экран вообще вредный — кому нужен сайт, у которого только первый экран виден, а все остальное подгружается позже?
Я впрочем рад, что тест наконец-то научился мерять время выполнения JS кода и жаловаться на это (на сайте в примере он выполнялся 7 секунд, его не я писал, если что) — глядишь года через три Гугл-таки сделает что-нибудь путное.
Вы явно не работали с Google Page Speed.
Я человек который зарабатывает (в том числе)этим деньги — оптимизацией под PageSPeed любого проекта. Это мой хлеб. За последний месяц 17 проектов. Из 8-11 балов до 90 — 100балов.
Пережимание JPG картинок и изменение их размера в моем случае давало значительную часть прироста оценки.
В вашем случае, это могло занижать оценку косвенно — когда Ваша видимая часть страницы в рамках первого экрана, содержала изображение, которое занимало большую часть видимой области. И это изображение загружалось очень долго.
Это не проблема формата изображения или пережатия.
Это проблема программиста, который не знает как в этом случае нужно работать с изображениями.
Это неверно. Гугл считает, что картинка должна весить X байтов, а у вас она весит Y байтов. При этом картинка, сжатая Гуглом как образец, зачастую имеет артефакты сжатия. Чем больше разница между X и Y, тем больше баллов у вас вычитают.
То что я сказал — ВЕРНО.
А вы опять не можете переступить через свое самомнение и проверить сказанное мной. Повторяю — страница которая оценена Гуглом в 90+ может содержать сотни неоптиимзированных изображений формата JPG и PNG
Потому что тесту плевать на это. Тесту не плевать на то как и сколько загружается и в какой временной интервал.
Когда тест Вам пишет — используйте то или используйте это, это ответы, которые возможно повлияют на оценку. Но это не то, почему тест провален. Потому что даже не выполняя эти рекомендации можно иметь честные 90+ балов.
Также есть другие трюки, вроде быстро загрузить статическую страницу, а потом медленно аяксом подгружать контент. С точки зрения пользователя, сайт грузится медленее, а очков в тесте он может получить больше.
Эти трюки лишний раз подтверждаю насколько Вы далеки от реальной разработки.
Вам любой тим лид за это руки переломает, при условии конечно что проекту нужен органический трафик.
Оценка LightHoue формируется не так как Вы написали. Нет никаких очков за то и за это.
Оценка формируется по временным интервалам и зависит от — временной метки формирования первого кадра контента, формирования кадра с достаточным контентом, формированием всего контента, и максимальной задержки между возможностью посетителя взаимодейтсвовать с проектом.
Никто никакие балы из X Y меньше файл или больше — не считает.
Несколько советов, которые дает Гугл вообще бредовые — вроде встраивания CSS в тело страницы. Это не позволяет браузеру кешировать CSS код и раздувает страницы. Плюс, это малореалистично оптимально сделать с технической точки зрения.
Это не бредовые советы. А еще один аргумент, почему ВЫ очень слабый специалист.
Объясняю Вам на пальцах, почему 50 килобайт CSS стиля вставленного онлайн в тело страницы это лучше, чем иметь один выделенный файл CSS с кешированием.
В рамках типично 3g соединения, издрежки на устновку соединения и ревалидацию кеша, намного больше, чем издержки на загрузку html страницы большей на 50 килобайт.
Именно поэтому вставка стилей онлайн это маст хэв прием любой оптимизированной страницы.
Если быть более точным, то вставляют не весь CSS а только критически важный CSS для отображения первого экрана. Остальной загружается отложено.
Формирование же критикал цсс — лежит целиком и полностью на плечах верстальщика, ИЛИ на использовании автоматических инструментов которые проделывают это за него.
Объективная метрика всегда поместит сайт с веб-шрифтами и 500-килобайтными картинками в красную зону независимо от числа применяемых оптимизаций.
Это еще раз говорит о вашей некомпетентности в этом вопросе.
Важны не обьемы ресурсов, а важно то как проект этими ресурсами оперирует, чтобы посетитель не ощущял дискомфорта.
И суть теста в том, чтобы понять умеет это делать проект или не умеет.
Все что вы писали дальше, это из той же оперы, человека который слышал звон и не знает где он.
Откройте исходники LightHouse они в открытом доступе, посмотрите в них и перестаньте позориться.
Разработчикам некоторых сайтов следует узнать в этой статье себя. Но как раз они не поймут, что это пародия на них.
Из статьи вытекает отличный вопрос: как в, например, Firefox запретить перехват мыши или стандартных сочетаний вроде Ctrl+F?
А, ну еще в режиме инкогнито в Хроме-_-, хз, с чем связано, я в веб не умею.
Убер и лицокнига не светят
Броузер Lynx легко отобразил страничку, которую не смог отобразить Firefox. Но когда я направил Lynx ещё на одну страничку того же сайта CodePen (тоже по ссылке из этой статьи), меня туда не пустили.
Lynx:
К чёрту пользователей с мышками
А скролл?? Забыли про скролл.
Я бы за благо посчитал советы удалить со страницы загружаемые ресурсы соцсетей и все эти блоки share me — но вот об этом LH молчит! А ведь страница Хабра, при включенном блокировщике, грузится чуть не в 2 раза быстрее неочищенной версии — как по мне, это что-то да говорит!
Это я к тому, что верить LH нужно не всегда…
Это подсказка от теста, что можно улучшить.
Проблема в счетчиках не в том, что они имеют слабую политику кеширования, а в том,
что когда они инициализируются, а это в 90% случаев происходит в момент рендера страницы, они отжирают значимую долю ресурса у ЦП. Что тут же просаживает страницу в балах на 30 40 пунктов.
И это совершенно правильное поведение. Инициализации гугл аналитик, на типичном мобильном процессоре наших дней, может занимать от 500мс до 1500мс. То есть страница получает лаг почти на полторы секунды.
Вы наберетесь смелости утверждать что оценка LightHouse несправедлива?
После поста, который мы с вами комментим, я бы вас в ответ спросил: а у вас лично как со смелостью верить lh?
Для начала я сказал и скажу ещё, что Гугл, сделав ga и lh, мог бы согласовать логику: либо ga работает отложено (тогда отчёт приходит в норму и не ругается сам по себе), либо lh не смущает юзеров руганью про счётчик (что грубый чит). Конечно, первый вариант лучше.
Если GA будет работать отложено то вы и так к очень неточной статистике, получите еще большую погрешность. Суть работы счетчика в том, чтобы на самом раннем этапе получить максимальный контроль за страницей.
Кроме этого, в документации гугл, дано только два способоа инициализации счетчика. Для самых маленьких. Те кто понимает как и что работает может успешно запускать счетчик образом, при котором он никак не повлияет на балы. Плата за это, увеличение погрешности в работе счетчика.
Дальше идут вопросы бизнеса.
Насколько человеку нужна точная статистика. Насколько ему важна скорость загрузки страницы.
И если ответы на оба вопроса — да очень нужно, то гуглоаналитикой не пользуются. И работают исключительно на анализе своих собственных логов.
После поста, который мы с вами комментим, я бы вас в ответ спросил: а у вас лично как со смелостью верить lh?
Вы не поняли посыл поста.
Во первых пост о доступности, а не о скорости работы страницы.
В случае скорости работы страницы вы тоже можете получить 90+ балов разными хитрыми приемами. Но получите удар с другой стороны — ваш проект не будет нормально индексироваться в поиске. В силу используемых приемов.
LightHous в области измерения производительности страниц, я доверяю полностью, и уверенность моя идет от того что я знаю как он работает (исходники открыты) и логика его работы полностью отвечает реальности.
Создаём максимально недоступный сайт с идеальной оценкой Lighthouse