Abnormal programming
Website development
CSS
HTML
Comments 41
+17
Можно еще убрать возможность копировать текст и нажимать правую кнопку мыши
+1
Всё равно останется возможность перейти на сайт с уже открытым отладчиком
Хотя это тоже можно обойти — можно включать блокировку отображения контента, пока отладчик открыт
+2
во первых тогда уж setInterval
во вторых можно отключить остановку на брейкпоины, на debugger это тоже распространяется.
0
Ещё можно сделать именно детектор наличия открытой консоли. Например, спам console.log(x) через тот же setInterval, где x это объект с подменённым toString, но это тоже можно обойти при желании.
0

Можно установить дополнение в FF для реактивации правой кнопки мыши.

+13

То же касается гугловского сервиса PageSpeed Insights, который меряет производительность страницы. Он будет вас распекать за лишние 100 байтов в JPEG картинке и требовать сжать их так, что начинают становиться заметными артефакты на картинках с резкими линиями, которые плохо жмутся JPEG. Но он ни слова не скажет, если вы влепите полмегабайтные PNG картинки или веб-шрифт, который блокирует отображение текста и реально замедляет загрузку в отличие от картинок, которые грузятся в фоновом режиме.


К сожалению, заказчики предпочитают именно хорошие цифры в тесте, а не качественный сайт.

+1
Для этого они советуют webp или png (которые замечательно сжимаются без визуальной потери качества)

P.S. на счет заказчиков — полностью вас поддерживаю
К сожалению, это вряд-ли когда-то изменится
0
Ну так а как неспециалисту оценивать работу сайта?

Есть же куча людей, которые заняты другим (своим бизнесом, например), и у которых к тому же нет способностей к детальному пониманию работы компьютеров, но есть таланты в других областях.

Какой путь будем рекомендовать им? Чтобы это было экономически оправдано.
0
Сервис PageSpeed Insights сам по себе рекомендательный сервис, он показывает где у Вас могут быть проблему. Хотя при этом сайт у Вас будет грузится менее 1 секунды. Сами сайты Google не проходят этот сервис по всем параметрам.
Заголовок спойлера
Тем более после обновления, когда «зеленая зона» сузилась.

Тут нужно замерять реальную скорость загрузки сайта причем сервис должен загружать сайт с того же региона, где располагается целевая аудитория на которую ориентирован данный сайт.
0
Строил год назад хостинг для студии. Все просто: nagios+PhantomJS и раз в 30 минут меряем скорость загрузки страницы. Клиенту в договоре указываем, что мы гарантируем загрузку страниц каталога в течение определенного времени (например 3 секунды) и даем учетку на nagios с правами просмотра результатов последних измерений и истории. Если вывалились за отведенное время — открываем браузер и смотрим вкладку Network чтобы понять что затормозило. Ну а далее по ситуации. Жмем картинки, оптимизируем базу и прочее…
+1
Хм, пейдж спид всегда говорил о том, что надо использовать jpg вместо png, а также прелоадер шрифтов.
0
Я кстати так и не смог добиться того, чтобы он перестал ругаться на шрифты, хотя выполнил все рекомендации.
0
Вы как и многие разработчики, не понимая как и что влияет на балы в пейдж спид, несете чепуху.

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

Делаю краткий ликбез:
1. Google Page SPeed сейчас — это тот же Light House о котором говориться в статье. С немного измененным профайлом оценки ситуации (какой канал используется, какая эмуляция процессора и т.д.)

2. Рекомендации которые пишет PageSpeed, это не ошибки, устранив которые вы получите высокие оценки. Точнее не только ошибки. Современный тест понятия не имеет насколько объективно необходимо загружать мегабайтные изображения. Потому он может только рекомендовать что-то пережать.

3. Величина файла изображения и его формат — это вещи которые на метрики, либо не влияют вообще, либо их фактор влияния в сравнении с прочими — мизерный. Можно иметь страницу с сотней изображений по 15 мегабайт и иметь 90+ в мобильной выдаче.

4. Первостепенную важность для PageSPeed играет скорость формирования первого экрана — достаточной части контента на ней. Которая оценивается — внимание — через анализ ряда скриншотов, в момент от старта, до события window.load +3000мс.

5. Из 4 пункта следует какие метрики определяются как важные и формирующие оценку — скорость ответа сервера, нагрузка на ЦП (JS логика, рендер), наполнение рабочей области контрастными областями которые условно принимаются за главную часть контента.

Все эти метрики — ОБЪЕКТИВНЫ. И действительно определяют скорость формирования страницы. Ошибки случаются только тогда, когда алгоритм неверно выделяет важные области, определяемые как значимый контент в рамках первого экрана. И связано это с контрастом. Который, в случае его недостатка, уже говорит о проблемах с проектом.

Качественный сайт, не может быть без выполнения этих метрик.
За исключением ситуаций, когда аудитория состоит из посетителей, которые ничего кроме этого сайта не посещают. У проекта может быть качественный контент, он может быть удобным с точки зрения использования, но он не может быть проектом который загружается быстро при первом посещении. А это, для Google, который монетизирует трафик из поиска, первейшая характеристика.

+1

Вы явно не работали с 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 секунд, его не я писал, если что) — глядишь года через три Гугл-таки сделает что-нибудь путное.

0
Вы явно не работали с 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 они в открытом доступе, посмотрите в них и перестаньте позориться.

0
За последний месяц 17 проектов. Из 8-11 балов до 90 — 100балов.

Как вы убеждали менеджеров убрать аналитики, аллоки и прочие живосайты? У меня за всё это баллов 30 снимают.
0
С живосайтом ещё прокатит, а с аналитикой и аллокой? У меня не получается объяснить преимущество потери минимум первых 5 секунд после загрузки и подмены номера с такой задержкой.
0
Честно, не понимаю вас. Почему нельзя подгружать на 5 секунд позже основного потока? За 5 секунд посетитель успеет сделать заказ и не будет отловлен Client ID или что?
0
За 5 секунд пользователь может перейти по какой-нибудь ссылке, и вы так и не узнаете referer, откуда же пришел этот пользователь. Некоторым это важно.
0
Статистика отказов портится. А как ещё убедить менеджеров, что попап с подпиской это плохо? А то лично я закрываю такие попапы при помощи Ctrl + W, вместе с сайтом.
+11
В FF переход в режим «Вид для чтения» позволил обойти все ловушки. Похоже что еще есть куда стремиться:)
+2
Благодарю автора и переводчика.

Разработчикам некоторых сайтов следует узнать в этой статье себя. Но как раз они не поймут, что это пародия на них.
0

Из статьи вытекает отличный вопрос: как в, например, Firefox запретить перехват мыши или стандартных сочетаний вроде Ctrl+F?

0
Если рандомно водить и жмякать мышкой — ее все-таки видно)
А, ну еще в режиме инкогнито в Хроме-_-, хз, с чем связано, я в веб не умею.
Убер и лицокнига не светят
0
У меня на Safari под iOS видна форма и через автодополнение можно ввести текст, попытка хорошая, но требует доработки.
0
Ещё раз благодарю автора и переводчика. Но упомянутый в статье сайт CodePen делают недоступным вовсе не те ухищрения, которые описаны в статье.

Броузер Lynx легко отобразил страничку, которую не смог отобразить Firefox. Но когда я направил Lynx ещё на одну страничку того же сайта CodePen (тоже по ссылке из этой статьи), меня туда не пустили.
скриншот
One more step == Please complete the security check to access codepen.io == Why do I have to complete a CAPTCHA? Completing the CAPTCHA proves you are a human and gives you temporary access to the web property.
Для сравнения, на другом сайте (тоже использующем CloudFlare, если что), заявлено: «Владельцы некоторых сайтов ненавидят людей. Поэтому они любят капчи. Мы любим людей и следовательно мы ненавидим капчи».
два скриншота (Firefox и Lynx)
Firefox:
Owners of some sites hate human beings. Hence, they love captchas. We love human beings and therefore we hate captchas. == So, please tell fairly: are you a human being or a robot? We hope at your fairness, thank you! (Firefox)
Lynx:
Owners of some sites hate human beings. Hence, they love captchas. We love human beings and therefore we hate captchas. == So, please tell fairly: are you a human being or a robot? We hope at your fairness, thank you! (Lynx)
0
К чёрту пользователей с мышками

А скролл?? Забыли про скролл.
0
Lighthouse и иже с ним очень еще любят ругать за некеширование загружаемых ресурсов, которые на поверку оказываются счетчиками Гугла, Яндекса и прочими. Ладно Яндекс, Гуглопроверялка про него может и не знать (сарказм), но уж счетчик Гугла они могли бы за best practice посчитать!

Я бы за благо посчитал советы удалить со страницы загружаемые ресурсы соцсетей и все эти блоки share me — но вот об этом LH молчит! А ведь страница Хабра, при включенном блокировщике, грузится чуть не в 2 раза быстрее неочищенной версии — как по мне, это что-то да говорит!

Это я к тому, что верить LH нужно не всегда…
0
Некешируемость ресурсов никак не влияет на балы в PageSPeed (LightHouse).
Это подсказка от теста, что можно улучшить.

Проблема в счетчиках не в том, что они имеют слабую политику кеширования, а в том,
что когда они инициализируются, а это в 90% случаев происходит в момент рендера страницы, они отжирают значимую долю ресурса у ЦП. Что тут же просаживает страницу в балах на 30 40 пунктов.

И это совершенно правильное поведение. Инициализации гугл аналитик, на типичном мобильном процессоре наших дней, может занимать от 500мс до 1500мс. То есть страница получает лаг почти на полторы секунды.

Вы наберетесь смелости утверждать что оценка LightHouse несправедлива?
0
Для начала я сказал и скажу ещё, что Гугл, сделав ga и lh, мог бы согласовать логику: либо ga работает отложено (тогда отчёт приходит в норму и не ругается сам по себе), либо lh не смущает юзеров руганью про счётчик (что грубый чит). Конечно, первый вариант лучше.

После поста, который мы с вами комментим, я бы вас в ответ спросил: а у вас лично как со смелостью верить lh?
0
Вы наберетесь смелости утверждать что оценка LightHouse несправедлива?

Я наберусь. LightHouse на данный момент совершенно не учитывает скорость перехода по страницам. Он поднимет результаты за встраивание CSS в код страницы, и ему совершенно плевать, что эти пусть даже 50кб теперь будут таскаться с каждым запросом, раз за разом.
0
Для начала я сказал и скажу ещё, что Гугл, сделав ga и lh, мог бы согласовать логику: либо ga работает отложено (тогда отчёт приходит в норму и не ругается сам по себе), либо lh не смущает юзеров руганью про счётчик (что грубый чит). Конечно, первый вариант лучше.

Если GA будет работать отложено то вы и так к очень неточной статистике, получите еще большую погрешность. Суть работы счетчика в том, чтобы на самом раннем этапе получить максимальный контроль за страницей.
Кроме этого, в документации гугл, дано только два способоа инициализации счетчика. Для самых маленьких. Те кто понимает как и что работает может успешно запускать счетчик образом, при котором он никак не повлияет на балы. Плата за это, увеличение погрешности в работе счетчика.

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

После поста, который мы с вами комментим, я бы вас в ответ спросил: а у вас лично как со смелостью верить lh?

Вы не поняли посыл поста.
Во первых пост о доступности, а не о скорости работы страницы.
В случае скорости работы страницы вы тоже можете получить 90+ балов разными хитрыми приемами. Но получите удар с другой стороны — ваш проект не будет нормально индексироваться в поиске. В силу используемых приемов.

LightHous в области измерения производительности страниц, я доверяю полностью, и уверенность моя идет от того что я знаю как он работает (исходники открыты) и логика его работы полностью отвечает реальности.
0
На работе придумали писать текст в content псевдоэлементов и сортировать их при помощи order от Flexbox.
Only those users with full accounts are able to leave comments. , please.