Комментарии 41
Не знаю почему, но у меня на Андроиде падает хром при переходе на zenofpython.org
+ Vivaldi
ПК windows yandex.браузер = зависает
ПК windows 10 chrome = все ок
Самый оптимальный сайт. В конце концов, никогда зачастую лучше чем прямо сейчас ;)
Подтверждаю: Android + Brave
Андроид + Firefox = ОК
Это философия дзен. Никакой броузер не должен мешать медитации.
Win11+ЯБ - загрузка виснет.
Да там даже теков <html> нет
тщетно, битва проиграна.
пока фронтендеру позволено раздувать и делать нетормозящее тормозящим - он будет это делать.
над разработчиком должен быть контроль качества, который продумал квоту по объему фронтенд кода, метрики перфоманса на каждое действие, CLS (который layout shift), итд итп, и не допускает в прод медленное, толстое и неповоротливое.
такого контроля качества нет
Поэтому, я беру какой-то генератор а-ля Jekyll, быстро создаю себе блог и размещаю там полезную инфу. Да, исходники моего блога занимают 400 килобайт (без собственно самого контента в виде текстов, файлов и изображений), но если я буду тратить время на экономию одного байта, у меня его не останется на более важные вещи.
так, вам нужен сайт на который хочется быстро выложить инфу.
а проблема-то в чем?
Скорость загрузки сайта конечно решает, но не настолько, чтобы делать сайт размером 1КБ. Удобства, семантическая верстка и адаптивность решают больше. Удобства даже в плане добавления статьи, когда ты из панели открыл редактор и написал, а не подключился по sftp к хостингу, скачал файл и написал в него сначала ссылку на другую страницу, потом пошел и создал эту самую другую страницу.
Я так же делал сначала - поставил джумлу, выбрал красивый шаблончик, и удобно редактировал содержимое сайта из админки. Потом сайт заблочил хостер, потому как какой-то корейский хакер его поломал и начал рассылать спам. Прочитал про использованные уязвимости, обновил весь софт, помогло на несколько месяцев - потом опять поломали. Опять закрыл уязвимости, зачистил оставленные бэкдоры, прошло еще время - опять поломали, и поставили целую админку ;)))
С учетом того, что мне зело лень постоянно мониторить уязвимости и закрывать их патчами - снес все к чертякам, сделал сайт на статике (и разместил его у себя на роутере, о чем написал).
Да, оформление занимает немножко больше времени. Но именно немного, потому как основное время - подготовка текста и графики, а впихнуть всё это в статический шаблон странички и прописать ее - несколько минут.
И никаких проблем со скрипт-киддями, боты тыкаются ежеминутно, перебирают разные эксплойты, но результат нулевой - никакой CMS там просто нет.
PS: Да, это годится только для частной странички или сайта-визитки предприятия, но, с другой стороны - таких достаточно много...
Нужно просто своевременно обновлять и не юзать плагины, так как они почти все кудрявые. А вообще, Django наше всё.
Слушай, у меня сайт с посещаемость в несколько тысяч уникальных посетителей в день и он был на джумле, поэтому не надо мне тут рассказывать как ты героически уязвимости закрывал. Враньё. Накачал плагинов и тем более "выбрал красивый шаблончик" - это уже помойка запрятанных бэков, в лучшем случае бэклинков. Сделать свой шаблон - ничего сложного, в крайнем случае открой ютуб и копипасте от туда. На килобайтный сайт один фиг потратишь во много раз больше времени, редактируя каждый раз. голый HTML каждый раз редактировать не удобно и долго, иначе не безопасносно.
Не, ну статический сайт можно и на github pages выложить с минимумом мороки. Тут даже на роутер не нужно себе ставить.
Так это нормальный размер. Ненормально когда корпорации тратят миллионы на сайты более 10 МБ, где информации на килобайт, и это грузят миллионы людей по минуте.
А еще они выпускают 500-мегабайтные инсталляторы драйверов, которые ставят на комп QT, затем программу, написанную на этом фреймворке со встроенным Chromium'ом для отрисовки веб-страничек, показываемых при старте той программы, а после всего этого распаковывают мегабайтный архив и ставят из него наконец-то таки собственно драйвер.
После чего пользователь, радуясь, что монитор перестал отрисовывать рабочий стол и окна других программ в 2 FPS сносит к чертям все эти свистопляски и освобождает на компе 2 гигабайта.
Ну, исходники моего блога занимают, пожалуй, ещё больше и вообще на Hakyll, но результирующая главная страница — десяток килобайт в gzip. Было по-своему прикольно писать свой оптимизатор HTML (и потом отправить его в апстрим, конечно).
Есть еще где такие трюки очень сильно помогут и очень актуальны. Например написание веб интерфейса для микроконтроллера, с WiFi модулем. Память на них, как правило, жестко ограничена, и тут возможность уложиться в один килобайт - очень даже ценная.
Рекламщику нужен отклик, а его может и не быть с сайтом <= 1КБ.
Нет отклика = Нет прибыли = Нет программиста с рекламщиком
Почему на первой картинке сравниваются медиана и среднее, а не просто два средних?
1 Кб – это довольно-таки челенж, могу сказать как непосредственно участвовавший в таких извращениях
немного подробностей
особенно если речь идёт о странице с элементами управления, хостящейся на микроконтроллере, где есть 1 Кб RAM и (полу)хардварное ограничение на размер страницы в байт (ни о каких кило речь даже не идёт, не говоря уже о мега) этак на 600.
Получается что-то вроде:
приходится экономить буквально каждый char (и никакого там UTF) и выбирать слова, где поменьше букв. И оно даже работает в итоге
Но, как и в случае с буханкой-троллейбусом, зачем? Есть, действительно, случаи, когда это обусловлено необходимостью. Но сейчас в "клубе" страницы, где информации такой минимум миниморум, что возникает вопрос – не проще было зажать это в двухцветный GIF, добавив поля на ссылки?
не проще ли?
Сходу: сохранённый скриншот из огнелиса в png – ~50 Кб. Конвертация в ч/б gif – ~10 Кб. Ч/б png c максимальным сжатием – ~6 Кб. Практически нечитаемый JPEG c максимальным сжатием – ~10 Кб.
Т.е. есть, наверное, шанс извратиться, но в целом нет, не проще :)
Если не выводить текст на сайте, то он будет занимать ещё меньше места. Вот только будет ли полезным?
Создаёшь сайт весом в 1Кб. Подключаешь Google Analytics. Проверяешь проект через сервис Google Page Speed, получаешь оценку 60 баллов из 100 с комментарием "вам нужно оптимизировать наш js" =)
Единственная стоящая страница, к которой применимо слово демосцена - 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) в том, что сайт продолжает загружаться примерно столько же времени как и раньше, но во время загрузки вы видите не белый экран, а контент, который можно скролить и кликать по ссылкам.
Интересно как веб постепенно возвращаются к рендеру на стороне сервера.
Ребята! Вы все делаете сайты неправильно! Вы загружаете на свой сайт 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
Хотя компьютеры стали гораздо мощнее, а скорость доступа в интернет выросла, ...
... возросло внимание регуляторов к вопросам мониторинга и контроля над траффиком, цензурирование доступа к ресурсам, шейпинг не вскрываемого траффика (только не надо пожалуйста говорить что не везде - везде, просто где то не так явно), по этому, если года так до 2010 нам, в большинстве случаев, на прямой запрос прилетал прямой ответ, то теперь всё что может быть вскрыто разворачивается до данных, затем заворачивается обратно, а такая штука, как DPI, ещё умеет в TLS становиться man in the midle и подменять сертификаты на свои для запрошенного домена, подписанные CA, подписанные коренным CA, который есть во всех доверенных PKI базах ОС и браузеров. Шифрование на месте не стоит, совершенствуется, блокировки и мониторинг обходятся новыми способами, но и системы ТСПУ тоже на месте не стоят, их ещё и ставить начинают у магистральных провайдеров, что бы вообще жизнь мёдом не казалась, а ещё на сети создаётся в целом бешенная нагрузка всяким спамом, DDoS, ростом популярности FHD и UHD видеоконтента, в целом количество пользователей сети тоже прилично выросло, сайты тоже в среднем разжирели не слабо, между провайдерами появилось куча далеко не только технических и экономических оснований для пиринга/депиринга, так что бывает потом до какого то узла маршруты в 40+ хопов и тд и тп.
Так что может глядя на картинку в заголовке и кажется странным, мол как же так то - прогресс вроде есть, а результат как то не виден, но в принципе хорошо ещё что динамика хоть в какой то плюсик, а не в минус.
Полагаю что момент, когда крутизна технологий обгонит все факторы её нещадного торможения, таки наступит и даже жирнющие сайты будут грузиться почти мгновенно, но пока да, согласен, оптимизация в вёбе - наше всё.
Спасибо за очень нужную и полезную статью )
P.S. Я конечно не такой прям гуру гипероптимизации, да и наверное 1кб - это совсем не для React'а цель, но тем кто хочет посадить на диету своё React приложение, может будет интересен такой подход к управлению стейтом (0 зависимостей 926 байт билд)
я не специалист в области сайт строения, но с тех пор как стал делать девайсы на МК со встроенным ВЕБ настроек и управления, пришлось изучать способы минимизации объемов кода ВЕБ страниц. И надо отметить, что для многих ВЕБ дизайнеров это очень не просто. Они не могут понять как вместить в ограниченный объем памяти МК. Проблема не только в подходе к коду , но и проблема в дизайне и внешнем виде. Дизайнеры не могут думать в минималистическом стиле к сожалению.
14 КБ это слишком много. Делаем сайты меньше 1 КБ