Как стать автором
Обновить

Комментарии 44

Простите, что я тут стучу из каменного века, но 15 лет назад, когда мегабит было весьма не плохо, а пентиум 4 — хорошей машиной, я привык, что скорость загрузки страницы меньше секунды это норма.
А теперь мне рассказывают, что блог с комментами, который грузится за 2 секунды на 100мегабитном канале и на пару порядков более мощном процессоре это особое достижение.
Есть такой писатель Леонид Каганов. У него есть блог. Один из старейших блогов рунета.
Пишет его не комманда топовых разработчиков с зарплатой в сотни килорублей, а один человек на пхп в текстовом редакторе.
Он грузится в несколько раз быстрее того же хабра. И там тоже можно прочитать статью, прокоментировать и полайкать комментарии.

Справедливое замечание и да, я тоже хочу жить в таком мире.
Хабр перегружен рекламой. Но тут от девелопера зависит только то, увидите вы конент ДО рекламной фигни или после. И спасибо что сделали это грамотно, а то контент мы бы видели через 10 секунд на 100мб. Плюс хабр понагруженнее будет я думаю.

Глянул показатели конкретно этой страницы.
Немного смущает что TTFB у статики 5-20мс, а вот у документа прыгает от 300 до 1300мс.

Во время очередного обновления страницы (Firefox):
DNS resolution: 3 ms
Connecting: 128 ms
TLS setup: 135 ms
Sending: 0 ms
Waiting: 1916 ms <<<
Receiving: 129 ms

Диагноз по фотографии ставить сложно. Когда я смотрел основную страницу, я думал что проблема в БД (хотя, хотя, по идее там вообще стоит кеширование и все должно быть быстрее) Почему тут такой TTFB сказать сложно. Возможно (пальцем в небо) высокая нагрузка, сервер не справляется и все идет через очередь запросов?

Мне, как человеку выросшему на диалапе, подчас хочется чтобы кто-то взял страничку хабра, ту самую что весит 10 мегабайт, и переверстал её на html4+css3, превратив ее в страничку в 300 килобайт c идентичным внешним видом.
Грусть и раздражение вызывает подход «интернет у всех быстрый, сервера дешевые, 5 мегабайт на страницу это не много».

P.S. Если помните, раньше можно было составить Word-документ, и конвертировать его в html. Там получался такой оверхед, что мегабайт весил хтмл-файл, который сверстанный руками весил бы 10 килобайт. Современная фронтенд-разработка иногда чем-то напоминает копипасту из таких «вордов».
Word то фигня, тогда рулил FrontPage, вот где адовая штука :)
А вы, часом, не путаете с DreamWeaver'ом?
Потому что FrontPage это был вполне внятный редактор без WYSIWYG примочек.

А нет. Это я путаю, простите.
В смысле? FrontPage как раз wysiwyg-редактор, его первая версия FP Express была инструментом номер один для создателей хомяков.)
Правда хтмл из под него не отличался оптимизацией, это да. Но более-менее работало все.

<td align="center"><font color="#0000FF"><b>В
            разделе </b></font><a href="software.htm"><font
            color="#00FF00" face="Lucida Handwriting"><b>Software</b></font></a><font
            color="#FF0000"><b> </b></font><font color="#0000FF"><b>находится </b></font> 
            <p><font color="#0000FF"><b>множество
            небольших ,но</b></font>  </p>
            <p><font color="#0000FF"><b>очень удобных
            и полезных </b></font>  </p>
            <p><font color="#0000FF"><b>программ,которые
            значительно</b></font>  </p>
            <p><font color="#0000FF"><b>облегчают
            работу с компьютером.</b></font></p>
            </td>


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

HomeSite?

Точно. Пользовался им году в 2005-2006
Хабр с выключенными скриптами относительно работоспособен для режима чтения, отправка комментариев же страдает. Хорошим решением было бы создать альтернативную обёртку для сайта в формате юзерскрипта, которая бы накладывалась на сайт без скриптов. Плюсом были бы открытый код без всяких минификаций с обфускациями, и гарантия того, что содержимое не изменится до тех пор, пока ты сам не прикажешь менеджеру юзерскриптов обновить скрипт.
Эм. Я, наверное, скажу какую-нибудь глупость, но разве скрипты и стили не кешируются?

Кешируются, результаты повторной загрузки — 953 ms до DCL (т.е. читать контент мы сможем еще раньше). Но с кешированием не интересно :)

Почему не интересно? Я хабр открываю много раз на дню.
И загрузку картинок я лично готов подождать — я ещё помню времена, когда я их минутами грузил.

Уже сектор для анализа. Что остается:


  • Загрузка страницы (она всегда грузится, тут надо что бы сервер отдавал ее как можно быстрее, т.е. оптимизировать TTFB)
  • Парс html -> стилией -> скриптов (теперь их не надо качать), соответственно на первый план выходит процессор. Соответственно нужно уменьшить количество скриптов (любых) до контента (на те что в конце можно вообще забить, css и html парсятся тоже быстро, тоже можно пока забить)
  • Все. Остальное будет грузиться фоном пока вы будете читать контент.
Это вы ещё в посты с большим количеством комментариев и активным обсуждением не заходили. Там бывало и страница до конца не грузилась.

Коментарии в мобильной версии хабра ещё то развлечение/мазохизм — у меня могут грузиться чуть ли не минутами при в общем нормальной связи.

Ага, в мобильном хроме даже сотня комментов грузится медленно, причем никакой индикации об этом нет — словно подвис.

Каюсь, не смотрел. Хотя зря наверное, тоже вспомнил что они знатно тормозили. Надо будет заглянуть.

Актуально. Что характерно, читаю, эпизодически, в том числе и сейчас, Хабр на канале 64Кб/с (дада, и сейчас такое бывает) на Celeron и, в принципе, размеренное чтение получается, но через TOR, через Chrome не реально. Да и рбк и подобные можно полистать. А вот на какой-нибудь сайт теле2 зайти никак не удасться при такой конфигурации (сравните информационность страниц ресурсов с точки зрения пользоваеля).

Я бы вообще добавил в процесс тестирования проверку сайта на каком-то +- старом устройстве. Пусть не celeron и не atom, но почему бы не I5U какого-то 16-17 годов. Уже будет неплохо. А то все привыкли к dev машинам и 100mb/s, а потом это грузиться 15 секунд у реального юзера.

i5 — это очень даже приличный комп на самом деле.
Надо на каком-нибудь atom, что сейчас таки продаются под видом планшетов с виндой.
И да, на телефоне с 512(!)Мб, которых тоже до сих пор полно и которые покупают(!), потому что «красненький»…

Я выше уже писал про советы и гипотезы. Тут такое дело, что время разработчика стоит денег и если ваша ЦА не сидит на atom-ах, то, наверное, вам они и не надо.


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

  1. Как вы определите, сидит ЦА на атомах или на каких-то других процессорах? Насколько мне известно, из браузера эта информация недоступна.
  2. Ошибка выжившего же. Если на атомах сайт неюзабельно тормозит, владельцы атомов могут просто избегать посещения сайта, дабы не страдать.

Замечательные замечания. Но разработчики не определяют ЦА, мы работаем с теми данными что есть. Сказали у нас нет атомов, значит нет :)


А вообще, наверное, есть какие-то опросы, есть процент атомов на рынке (хотя кто и как его считает это тоже вопрос). В конце-концов есть момент платежеспособности. Например у вас сайт продает какие-то статусные вещи или квартиры в элитном районе — вам атомы не интересны. А вот если вы масс сегмент (новостная площадка) то да, уже ближе. Но, опять же, вопрос сколько надо денег вложить в атом, и когда он окупиться. Помните же принцип 20/80?

На стороне сервера не должно быть сложно организовать профилирование пользователей (если они нужны сайту). Адрес известен, страница запрошена, вставить в неё маркер, по нему отслеживать время догрузки страницы. Если у большого процента пользователей загрузка длится существенно дольше порога комфортности, нужно что-то делать.
Целевая аудитория вполне может лежать с планшетиком, который не айпад…
Пока не разбил планшет, который брал под навигатор — периодически читал с него. Но именно периодически — как-то неудобно читать, когда проскроллил чуть-чуть комментариев и… они отрисовываются через секунду, причём именно отрисовываются — по сети ничего не гонялось.

P.S. Нет, не под хромом — планшет начинал греться и жрать неновую батарейку, не фф — дикий тормоз на бОльшей части андроидопланшетов, пользовался оперой.
Красный, значит быстрый. Очевидно же.

Спасибо, очень приятно.

У меня есть только черешневый сок.
Да, я прочитал)
Нет, я не зануда =)

Хоть кто-то :), легко нашли?

Наверное да)
Я чем-то задним почувствовал что этот тег будет =)

Сложно прочесть тэги, когда их нет [в мобильной версии хабра].

А только у меня в мобильной версии картинки не видны и спойлеры не открываются?

Долгий тап по фотографиям — будет в заголовке контекстного меню

Дальше все снова пошло хорошо [...] распарсили Math.Jax
Если я правильно понял, то данная библиотека используется далеко не на всех страницах. Поэтому считаю плохой идеей подключить неиспользуемую библиотеку (особенно, если она весит 492.25 KB).

Сохранение фотографий (не графических иллюстраций) в формате PNG — это грубое проявление неуважительного отношения к окружающим

Просто png — формат по умолчанию для сохранения в mspaint под Windows 10 (прогресс по сравнению с XP чувствуется — там по умолчанию был bmp). А чтобы приложение выбрало jpg, если вставленный скриншот является фотографией, а не иллюстрацией — тут, видимо, без ИИ не обойтись. Ну или естественного аналога.
Могло быть хуже. Если бы сообщество не отстояло mspaint, скриншоты скоро было бы не открыть без 3D редактора.
А чтобы приложение выбрало jpg, если вставленный скриншот является фотографией, а не иллюстрацией — тут, видимо, без ИИ не обойтись.

Хватит и тупого скрипта:


function getSaveFormat(image) {
  if (getPngSize(image) < getJpgSize(image)) {
    return 'png';
  } else {
    return 'jpg';
  }
}

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

Выборка может оказаться непредставительной — изображение пустым или нетипичным. Наверно, несложно определить происхождение картинки — искусственное или естественное — в процессе сжатия.
Вообще, логично было бы определить контейнер для изображения, как mkv для видео, а конкретный алгоритм сжатия выбирать исходя из природы изображения. Архиваторы так и поступают — для разных файлов внутри одного архива выбирают алгоритм исходя из их «начинки». Заодно добавлять оптимизации типа прогрессивного jpg, убирать избыточное разрешение, нерелевантные теги и т.п. Для лентяев.
А как быть Хабру с внешними ссылками? Грузить, смотреть вес и не принимать такие ссылки?

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


Вообще, мой комментарий относился к предложению про формат сохранения по умолчанию в графическом редакторе.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.