How to become an author
Streams
All streams Development Admin Design Management Marketing PopSci
Comments 44
Простите, что я тут стучу из каменного века, но 15 лет назад, когда мегабит было весьма не плохо, а пентиум 4 — хорошей машиной, я привык, что скорость загрузки страницы меньше секунды это норма.
А теперь мне рассказывают, что блог с комментами, который грузится за 2 секунды на 100мегабитном канале и на пару порядков более мощном процессоре это особое достижение.
Есть такой писатель Леонид Каганов. У него есть блог. Один из старейших блогов рунета.
Пишет его не комманда топовых разработчиков с зарплатой в сотни килорублей, а один человек на пхп в текстовом редакторе.
Он грузится в несколько раз быстрее того же хабра. И там тоже можно прочитать статью, прокоментировать и полайкать комментарии.
+17

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

+4
Глянул показатели конкретно этой страницы.
Немного смущает что 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
+1

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

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

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

А нет. Это я путаю, простите.
0
В смысле? 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>


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

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

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

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


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

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

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

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

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

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

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

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


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

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

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


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

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

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

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

0

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

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

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

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

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


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

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

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

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


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

0
Only those users with full accounts are able to leave comments. Log in, please.

Most reading

Your account

Sections

Information

Services

Language settings
Support
© 2006–2021 «Habr»