Комментарии 73
Не знаю почему, но у меня на Андроиде падает хром при переходе на zenofpython.org
+ Vivaldi
ПК windows yandex.браузер = зависает
ПК windows 10 chrome = все ок
Самый оптимальный сайт. В конце концов, никогда зачастую лучше чем прямо сейчас ;)
Подтверждаю: Android + Brave
Андроид + Firefox = ОК
Это философия дзен. Никакой броузер не должен мешать медитации.
Win11+ЯБ - загрузка виснет.
Да там даже теков <html> нет
На ПК - яндекс, хром - не открывается
Опера и FireFox открывает
Desctop Win10 + Firefox = OK
тщетно, битва проиграна.
пока фронтендеру позволено раздувать и делать нетормозящее тормозящим - он будет это делать.
над разработчиком должен быть контроль качества, который продумал квоту по объему фронтенд кода, метрики перфоманса на каждое действие, CLS (который layout shift), итд итп, и не допускает в прод медленное, толстое и неповоротливое.
такого контроля качества нет
Поэтому, я беру какой-то генератор а-ля Jekyll, быстро создаю себе блог и размещаю там полезную инфу. Да, исходники моего блога занимают 400 килобайт (без собственно самого контента в виде текстов, файлов и изображений), но если я буду тратить время на экономию одного байта, у меня его не останется на более важные вещи.
так, вам нужен сайт на который хочется быстро выложить инфу.
а проблема-то в чем?
Скорость загрузки сайта конечно решает, но не настолько, чтобы делать сайт размером 1КБ. Удобства, семантическая верстка и адаптивность решают больше. Удобства даже в плане добавления статьи, когда ты из панели открыл редактор и написал, а не подключился по sftp к хостингу, скачал файл и написал в него сначала ссылку на другую страницу, потом пошел и создал эту самую другую страницу.
Я так же делал сначала - поставил джумлу, выбрал красивый шаблончик, и удобно редактировал содержимое сайта из админки. Потом сайт заблочил хостер, потому как какой-то корейский хакер его поломал и начал рассылать спам. Прочитал про использованные уязвимости, обновил весь софт, помогло на несколько месяцев - потом опять поломали. Опять закрыл уязвимости, зачистил оставленные бэкдоры, прошло еще время - опять поломали, и поставили целую админку ;)))
С учетом того, что мне зело лень постоянно мониторить уязвимости и закрывать их патчами - снес все к чертякам, сделал сайт на статике (и разместил его у себя на роутере, о чем написал).
Да, оформление занимает немножко больше времени. Но именно немного, потому как основное время - подготовка текста и графики, а впихнуть всё это в статический шаблон странички и прописать ее - несколько минут.
И никаких проблем со скрипт-киддями, боты тыкаются ежеминутно, перебирают разные эксплойты, но результат нулевой - никакой CMS там просто нет.
PS: Да, это годится только для частной странички или сайта-визитки предприятия, но, с другой стороны - таких достаточно много...
Нужно просто своевременно обновлять и не юзать плагины, так как они почти все кудрявые. А вообще, Django наше всё.
Слушай, у меня сайт с посещаемость в несколько тысяч уникальных посетителей в день и он был на джумле, поэтому не надо мне тут рассказывать как ты героически уязвимости закрывал. Враньё. Накачал плагинов и тем более "выбрал красивый шаблончик" - это уже помойка запрятанных бэков, в лучшем случае бэклинков. Сделать свой шаблон - ничего сложного, в крайнем случае открой ютуб и копипасте от туда. На килобайтный сайт один фиг потратишь во много раз больше времени, редактируя каждый раз. голый HTML каждый раз редактировать не удобно и долго, иначе не безопасносно.
Не, ну статический сайт можно и на github pages выложить с минимумом мороки. Тут даже на роутер не нужно себе ставить.
Так это нормальный размер. Ненормально когда корпорации тратят миллионы на сайты более 10 МБ, где информации на килобайт, и это грузят миллионы людей по минуте.
А еще они выпускают 500-мегабайтные инсталляторы драйверов, которые ставят на комп QT, затем программу, написанную на этом фреймворке со встроенным Chromium'ом для отрисовки веб-страничек, показываемых при старте той программы, а после всего этого распаковывают мегабайтный архив и ставят из него наконец-то таки собственно драйвер.
После чего пользователь, радуясь, что монитор перестал отрисовывать рабочий стол и окна других программ в 2 FPS сносит к чертям все эти свистопляски и освобождает на компе 2 гигабайта.
Есть еще где такие трюки очень сильно помогут и очень актуальны. Например написание веб интерфейса для микроконтроллера, с WiFi модулем. Память на них, как правило, жестко ограничена, и тут возможность уложиться в один килобайт - очень даже ценная.
Рекламщику нужен отклик, а его может и не быть с сайтом <= 1КБ.
Нет отклика = Нет прибыли = Нет программиста с рекламщиком
Почему на первой картинке сравниваются медиана и среднее, а не просто два средних?
1 Кб – это довольно-таки челенж, могу сказать как непосредственно участвовавший в таких извращениях
немного подробностей
особенно если речь идёт о странице с элементами управления, хостящейся на микроконтроллере, где есть 1 Кб RAM и (полу)хардварное ограничение на размер страницы в байт (ни о каких кило речь даже не идёт, не говоря уже о мега) этак на 600.
Получается что-то вроде:
приходится экономить буквально каждый char (и никакого там UTF) и выбирать слова, где поменьше букв. И оно даже работает в итоге
Но, как и в случае с буханкой-троллейбусом, зачем? Есть, действительно, случаи, когда это обусловлено необходимостью. Но сейчас в "клубе" страницы, где информации такой минимум миниморум, что возникает вопрос – не проще было зажать это в двухцветный GIF, добавив поля на ссылки?
не проще ли?
Сходу: сохранённый скриншот из огнелиса в png – ~50 Кб. Конвертация в ч/б gif – ~10 Кб. Ч/б png c максимальным сжатием – ~6 Кб. Практически нечитаемый JPEG c максимальным сжатием – ~10 Кб.
Т.е. есть, наверное, шанс извратиться, но в целом нет, не проще :)
приходится экономить буквально каждый char (и никакого там UTF) и выбирать слова, где поменьше букв
Попробуйте пожать файлы в gzip и отдавать их сервером с заголовком Content-Encoding: gzip, возможно так получиться не экономить на буквах.
Если я верно понял мысль, то: в случае целиком статичной страницы, т.е. той, которая просто отдаётся, а не генерируется, сервером, так действительно можно было бы сэкономить (я так понимаю, в МК были бы загружены предварительно пожатые статические страницы). Но если на странице что-то должно меняться в зависимости от внутреннего состояния или периферии МК, то будет сложнее – кучу фреймов, как минимум, придётся вводить, так навскидку.
Да, все верно. JS, CSS, SVG, шрифты (хотя последние вы вряд ли будите использовать в этом проекте) обычно простая статика и их содержимое не будет меняться в зависимости от состояния железки. HTML можно использовать только в качестве шаблона, а содержимое менять через js. Состояние МК лучше передавать не в текстовом формате, а в бинарном (в одном байте уместиться сразу 8 флажков вкл/выкл).
Верная мысль - все статичное жмем gzip. Для переменных в json файлах делаем короткие имена переменных. Еще можно сэкономить если выводить не список переменных , а массив.
например, файл com.json хранящийся в памяти мк имеет вид:
{
"prn":[
~Cmd_Matrix~
]
}На этапе вывода файла , файловая система понимает , что вместо ~Cmd_Matrix~ нужно вызвать функцию вывода, а затем снова продолжить вывод из файла. Файлы которые имеют такие переменные помечаются для файловой система специальным атрибутом. А это то что будет отдано http сервером браузеру
{
"comcount":"48",
"comhide":"0",
"comhidn":"0",
"prn":[
["relay,1,3","relay,1,3","1","1"],
["relay,2,3","relay,2,3","1","1"],
["relay,3,3","relay,3,3","5","5"],
["relay,4,3","relay,4,3","1","1"],
["relay,5,3","relay,5,3","1","1"],
["relay,6,3","relay,6,3","1","1"],
["","","1","1"]
]
}Но если на странице что-то должно меняться в зависимости от внутреннего состояния или периферии МК, то будет сложнее – кучу фреймов, как минимум, придётся вводить, так навскидку.
На самом деле в МК это не очень сложно, все решается callback функциями , которые занимают мало места. На хабре есть мои статьи с примером веб интерфейса для МК.
приходится экономить буквально каждый char (и никакого там UTF) и выбирать слова, где поменьше букв
и это действительно верно . никакой gzip не уменьшит размер файла до размеров файла без UTF .
Нет предела совершенству, давайте сжимать картинки в нечитаемый жпег, который будет почти нормально выглядеть:
Если не выводить текст на сайте, то он будет занимать ещё меньше места. Вот только будет ли полезным?
совершенно верно.
потому, что вставка гугл аналитики, путем сценария добавления тега script - єто поведение по умолчанию для тех, кто хочет сделать быстро из коробки.
если программист даст себе труд ознакомиться с протоколом, который использует аналитика, то ему не составит никакого труда сделать так, чтобы гугл аналитика не влияла на метрики (в их современном виде)
под словами - ознакомиться с протоколом, имеется ввиду чтение документации к аналитике.
Единственная стоящая страница, к которой применимо слово демосцена - https://1kb.jorgeff.com/ . Все остальные может сделать любой.
Можете, пожалуйста, объяснить код js с того сайта не для фронтендеров?
Я правильно понимаю, что этот человек кодирует цвет фона набором чаров?
d=b=>{e=Array.from({length:256},(_,i)=>String.fromCharCode(i));g="";for(v of b)b=e[v.charCodeAt()]||k+k[0],g&&e.push(k+b[0]),g+=k=b;return g};c=[1110,111,952,993,469];l=document.getElementById('l');d('0011ĀĄąĆā33ĂćČ12ĉĊČćĎĐċĒĀĎďĕăėęĚĉĂġĆĞ2ğĐđĄĤħĥ2ĜąĔĉĬĭĮĩIJĥĢēIJġĂĨĵķġĊ1Łľ14ĻŁĂņĩŅĻōʼnĮŅ4ŒœġŔįŒŕœŘŐŚśŔĠĘŝņʼnņŠāŢł3ŔŜŝũŘŊĩŭŤŌŗŔŚőĴőůŻŰŧŸŞŖŧƀŢŘĘĖŎĻ0').split('').forEach((v,i)=>{l.innerHTML+=`<p style="display:inline-block;margin:0;height:10px;width:10px;background:#${c[v]}">`;if(!((i+1)%18))l.innerHTML+='<br>'})
Да, вызывает прямо эстетическое удовольствие. Максимально быстрая загрузка и немного олдскульности. И даже там простор для оптимизации еще огромный.
Я бы отнес стремление к минимальному размеру страничку уже к оптимизации.
Да, это важно пользователю, но, как показывает практика, бизнесу это не особо важно, бизнес воспринимает оптимизации как лишние затраты ресурсов, и без серьезной причины заниматься ими не станет.
Проблема в том, что оптимизациями мало кто занимается. Обычно как: дизайнеры навалили идей, бизнес обрадовался, на страничку навалили тонну графики, видео, эффектов, раздули размер до 20-40мб и больше, проверили что она загружается на современном топовом железе, находясь в столице, прямо рядом с датацентром, и на этом все. Руководство бежит делать презентации, ну а остальное никому не интересно.
Никому даже не приходит в голову проверить как это будет работать откуда-нибудь за тысячу км или с мобильного интернета в условия плохой связи. Да и наверное не интересно: основная доля клиентов как правило в столицах, а там со связью все хорошо.
Всё упирается в деньги. Как ни странно, но (в идеале, конечно) решение об оптимизации принимает отдел БА и только они.
Если ускорить загрузку сайта с 14 сек до 5 сек выгоднее, чем пилить баннер - то все будут пилить оптимизацию. И наоборот.
Жаль только, что решение о борьбе за оптимизацию, (это, между прочим, ресурс разработчиков - один из самых дорогих) то это показывает хорошую квалификацию команды БА.
Специально для остальных, гугл потратили хренову тучу бабла и времени и выкатили график, гдё чётко прописано соотношение "время загрузки / свалившие пользователи". Там прямо типа "за каждую секунду загрузки валит Х% юзеров". Жаль не могу найти ссылку.
Если пользователи начнут байкот - например, поставят расширение, которое не даёт зайти на сайт, если он загружен менее, чем за 5-7 сек и это явление станет массовым - бизнес пересмотрит стратегию
Если пользователи начнут байкот - например, поставят расширение, которое не даёт зайти на сайт, если он загружен менее, чем за 5-7 сек и это явление станет массовым - бизнес пересмотрит стратегию
Думать такую мысль довольно приятно, но это всё же чересчур: лагают провайдеры, лагают роутеры, особенно домашние, лагают ПК и устройства. Анализировать ещё расширением, кто там по дороге слагал, будет вообще тем ещё квестом.
Вот что действительно стоило бы сделать, так это обязательные лёгкие версии сайтов HTML-only. Никакого там JS, никакой подгрузки со сторонних доменов. И плевать, сколько там его в месяц человек использует – законодательно установить обязательным, как стала обязательной плашка про куки. С раширения на эту тему можно было бы начать. А то взяли моду "You must enable JavaSript to view".
Новый дизайн Хабра, кстати, без JS прекрасно читается и шустро грузится, за что отдельное спасибо команде.
Кстати, в мобильном Хроме есть "упрощённый просмотр". Он невероятно полезен, когда пробуешь читать текст с неадаптированного сайта образца 2000х годов. Он каким-то образом вырезает всё, кроме текста, а сам текст походу ещё и нормализирует под экран.
Новый дизайн Хабра, кстати, без JS прекрасно читается и шустро грузится, за что отдельное спасибо команде.
Это побочка от продуманного SSR. Хитрость (даже при включенном JS) в том, что сайт продолжает загружаться примерно столько же времени как и раньше, но во время загрузки вы видите не белый экран, а контент, который можно скролить и кликать по ссылкам.
Интересно как веб постепенно возвращаются к рендеру на стороне сервера.
Как-то лепил тестовое задание - "веб-сервис с вопросами на тему ИТ". Была идея прикрутить время ответа к расчёту оценки. Если ответил за пару секунд - хорошо знает, за 10 секунд, хотя бы быстро гуглит. Но тоже подумал, что возможны задержки в сети, потому просто написал комментарий, что можно написать такой JS-скрипт. Пользователь, конечно, может его изменить у себя. Но такой пользователь уже заслуживает повышенной оценки.
Ребята! Вы все делаете сайты неправильно! Вы загружаете на свой сайт js, они от этого толстеют и им плохо! А так делать не нужно! Вот, взгляните на qwik https://qwik.builder.io/
Это фреймворк для создания сайтов без какого либо рантайма, гидрации и всего-всего вообще.
Ну, вообще там есть prefetching через сервис воркеры и js, конечно, обязательно будет загружен. Однако без prefetching будет загружен и исполнен только тот js с которым взаимодействует юзер)
Но правда, это прямо супер тема: никакой js не загружается до первой итерации с пользователем, за счет чего юзеру отдается чисто верстка + состояние, которое возобновляет гидрацию с сервера на клиенте после первого взаимодействия юзера. Сам js который приходит разбивается на крошечные части, у них там для этого даже отдельный символ $ есть, чтобы показать Vite как надо дробить компонент)
Как проверить, что я не выдумываю:
В доке qwik https://qwik.builder.io/docs/overview/ есть отличный пример как он работает на проде:
если открыть доку в режиме планшета, то у вас слева вверху появится значок мобильного меню
Hidden text
Но обработчик для кнопки еще не загружен! Чтобы он загрузился вам надо нажать на этот значок и тогда с сервера приедет js, который обрабатывает клик по этой менюхе.
А при разработке локально он еще и показывает от взаимодействия с чем именно и как приехал js файл)
Hidden text
Это не SPA, но SPA на нем можно замутить, есь тег Link, под капотом сервер с файловой структурой а-ля Next.js в качестве синтаксиса компонентов JSX
Чтобы он загрузился вам надо нажать на этот значок и тогда с сервера приедет js, который обрабатывает клик по этой менюхе.
Т.е. сайт будет лагать не один раз при загрузке, а каждый раз при клике на что-либо новое? Какая-то китайская пытка…
Но он не лагает при загрузке) Да и при клике на что либо не лагает тоже, проверьте сами) Плюс, там работает prefetching
Начну с конца: преимущество в том, что вы не загружаете js при загрузке страницы. Т.е совсем нет, вообще. Вы получаете html + css (инлайном), т.е сразу при открытии у вас html страница. Затем, когда пользователь начинает взаимодействовать со страницей у вас подъезжают нужные скрипты, которые начинают исполнятся по мере необходимости.
"Как оно может не лагать с точки зрения физики" - ответ достаточно просто и сложен одновременно: Qwik разбивает весь js на чанки, сохраняя при этом их состояние и записывает это в функции OnClick, делая что то такое: <button on:click="./chunk.js#handler_symbol">click me</button>
Вот почему оно не лагает: чанки крошечные, загружаются мгновенно. А те что побольше загрузятся тоже, но позже и с помощью service-worker'ов и prefetcing
Крошечность чанков не имеет значения, имеет значение сам факт огромного количества чанков. Если у меня сервер в Сингапуре с пингом 250 мс, то лаг при загрузке чанка физически меньше чем 250 мс быть не может.
Я недочитал доку 🤷♂️
И ввел Вас в заблужение) В проде все работает не так, как я писал) вот ссылка на их FAQ https://qwik.builder.io/docs/faq/#if-qwik-prefetches-js-then-whats-the-difference
Но я только сам разбираюсь в этом фреймворке и спор с Вами позволил мне его лучше понять😅
Конкретно вот эта либа https://partytown.builder.io/ обеспечивает "Prefetching off the main thread with a service worker."
Хотя компьютеры стали гораздо мощнее, а скорость доступа в интернет выросла, ...
... возросло внимание регуляторов к вопросам мониторинга и контроля над траффиком, цензурирование доступа к ресурсам, шейпинг не вскрываемого траффика (только не надо пожалуйста говорить что не везде - везде, просто где то не так явно), по этому, если года так до 2010 нам, в большинстве случаев, на прямой запрос прилетал прямой ответ, то теперь всё что может быть вскрыто разворачивается до данных, затем заворачивается обратно, а такая штука, как DPI, ещё умеет в TLS становиться man in the midle и подменять сертификаты на свои для запрошенного домена, подписанные CA, подписанные коренным CA, который есть во всех доверенных PKI базах ОС и браузеров. Шифрование на месте не стоит, совершенствуется, блокировки и мониторинг обходятся новыми способами, но и системы ТСПУ тоже на месте не стоят, их ещё и ставить начинают у магистральных провайдеров, что бы вообще жизнь мёдом не казалась, а ещё на сети создаётся в целом бешенная нагрузка всяким спамом, DDoS, ростом популярности FHD и UHD видеоконтента, в целом количество пользователей сети тоже прилично выросло, сайты тоже в среднем разжирели не слабо, между провайдерами появилось куча далеко не только технических и экономических оснований для пиринга/депиринга, так что бывает потом до какого то узла маршруты в 40+ хопов и тд и тп.
Так что может глядя на картинку в заголовке и кажется странным, мол как же так то - прогресс вроде есть, а результат как то не виден, но в принципе хорошо ещё что динамика хоть в какой то плюсик, а не в минус.
Полагаю что момент, когда крутизна технологий обгонит все факторы её нещадного торможения, таки наступит и даже жирнющие сайты будут грузиться почти мгновенно, но пока да, согласен, оптимизация в вёбе - наше всё.
Спасибо за очень нужную и полезную статью )
P.S. Я конечно не такой прям гуру гипероптимизации, да и наверное 1кб - это совсем не для React'а цель, но тем кто хочет посадить на диету своё React приложение, может будет интересен такой подход к управлению стейтом (0 зависимостей 926 байт билд)
я не специалист в области сайт строения, но с тех пор как стал делать девайсы на МК со встроенным ВЕБ настроек и управления, пришлось изучать способы минимизации объемов кода ВЕБ страниц. И надо отметить, что для многих ВЕБ дизайнеров это очень не просто. Они не могут понять как вместить в ограниченный объем памяти МК. Проблема не только в подходе к коду , но и проблема в дизайне и внешнем виде. Дизайнеры не могут думать в минималистическом стиле к сожалению.
Дизайнеры не могут думать в минималистическом стиле к сожалению.
Сложно одновременно экономить байты и играться со шрифтами.
Зачем нам вообще столько шрифтов? На заре интернета использовали стандартный шрифт из браузера. Почему теперь каждому сайту обязательно нужно 10-20 своих шрифтов с разными начертаниями?
А ведь когда-то сайты, которые весили по 10-20кб были нормой, а не "техночелленджем".
14 КБ это слишком много. Делаем сайты меньше 1 КБ