Мнение php-программиста

Скажу по секрету важную новость: иногда PNG меньше, чем JPG. Ну и если там есть текст, то в JPG он превращается в натуральный жопег.

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

Правда, я не пойму, как относится размер картинки к месту занимаемому ей в памяти, но это уже не важно…

И невдомёк ему, что метод формирования страницы для браузера не важен.

он важен для скорости, с которой ты получаешь страницу

допустим, у меня хостинг на Hetzner с 500 мегабайтами RAM. Он написан на эрланге и поэтому весит всего 50 мегабайт RAM. На него заходит 1 человек раз в месяц. Картинки все в жатом-пережатом джпеге с размерами 50х50 пикселей.

скорость - быстрая, секунды 2 до картинки

допустим, у меня тот же хостинг на Hetzner с 500 RAM. Сайт написан на Scala + Playframework и со старта требует 1Гб RAM. Но на хостинге нет столько RAM, поэтому приходится подключать своп-файл гига на два. Там же у меня видеостриминговый сервер, который рендерит мультики для веб-интерфейса во флеше. Но проблема в том, что видеосервер тоже хочет рамы. А еще хочет кэша жесткого диска. НО на сервере всего 4 Гб жесткий диск, 2 из них мы отдали на своп-файл, осталось всего-то два гига на видеокэш. Ну и за своп-файл они тоже подерутся (смотря какой сервер, есть один сервачок на эрланге который вообще почти не жрет, но не будем о нём).

в результате:
1) полсекунды - отправка URL
2) пять секунд - формирование страницы на сервере
3) три секунды - отрисовка страницы на клиенте
4) пять секунд - старт видеостримов и JS-анимации

вместе секунд 15 до того, как на экране появится что-то похожее на правду

плюс дополнительные вещи: флеш-видео и тэш video накапливают ошибки, и иногда браузер придется перезапустить. Либо браузер/флеш сами поправят ошибки, но на это потратится время. А еще - никто не сказал, что на клиенте будет достаточно RAM и процессора, чтобы отрисовать страничку вообще => своп и задержка => браузер тормознет on DOM load, и не отправит Ajax-запросы на получение картинок и прочего контента => содержимое странички посыпется, придется или ждать пока придут аяксом коррекции (если они вообще есть), или перезагружать страничку/браузер

так что, тут ВСЁ при чем. И какой там браузер - вопрос на восмьмом месте, когда сама веб-страничка жрет 400 мегабайт RAM, 20% процессора и после этого тормозит, т.к. сервер не вывозит вовремя отдавать данные

Если jQuery подсасывается с популрной CDN, то с большой долей вероятности библиотека уже окажется в браузерном кеше.

А, для пользователей медленно-интернета нужно еще добавить скорость загрузки данных, которая у них не мгновенная, и возможность что при переполенном канале данные вообще не подсосутся (н-р если врубить DC++ на 100% канала, то во ВКонтакте html - загрузится, а сосущиеся аяксом данные - не подсосутся, о чем в левом верхнем углу будут постоянно голосить ошибки, и освобождением канала или ожиданием это не лечится, надо перезагружать страницу)

Конечно Хром прожорливый. Пока просканирует страницу, пока вычленит ключевые слова, пока эвристика отработает, пока в Гугл запрос уйдёт...

Ты всё правильно пишешь, да не о том.
ТС говорил про потребление браузерами памяти из-за больших страниц.
Цитирую:

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

Ты внимательно прочитай, речь же о потреблении памяти браузером. Я не вижу прямой связи со скриптами на php на стороне сервера. О задержках вообще разговора не было.

с тех пор как жесткие диски стали измеряться в терабайтах, о потреблении ПАМЯТИ вообще не может идти речи, это просто такой способ говорить. Измерять страницы имеет смысл в секундах.

При чём тут диски если разговор об оперативной памяти? ТС привёл мнение, что хром прожорлив, не думаю что речь могла идти о дисковой памяти.

с тех пор как жесткие диски стали измеряться в терабайтах

А частота процессора в гигагерцах, о том какая там версия похапе или ещё чего вообще не может идти речи. Скорость зависит только от того, сколько напихано флеш-мусора и сколько денег не пожлобился отвалить владелец сайта за хостинг.

ты всегда можешь добавить +100500 гигабайт свопа, и сколько бы ни весил Хром, он туда влезет. При этом сократится скорость доступа, т.е. увеличится количество секунд до загрузки страницы. Т.е. полюбому всё сводится к секундам.

Это у тебя наверное пхп6 поэтому и вести так много!!

Черт, как я не подумал. У меня PHP 28, в общем-то.

А не очевидно?

сами страницы сегодня весят больше, картинки не в жпеге а в пнг, рекламы куча с видиками на флеше последнем

Безусловно - картинки и флешы и js-фреймворки утяжеляют. Только вот и браузеры действительно прожорливые.

Действительно стоит поставить flash-block и всё работает гораздо быстрее и потребляет меньше памяти, ну и AdBlock. Дальше остаются браузерные скрипты. Большая часть проблем интернета и браузеров - это коммерческая рекламная эксплуатация и adobe flash.

У меня нет флеша и я не посещаю сайты с рекламой, но в общем-то это так. Кроме того что adblock добавляет тормозов и до 50% оверхэд по памяти.

Кроме того что adblock добавляет тормозов

Как это?

и до 50% оверхэд по памяти.

Как вы этого добиваетесь? У меня всего 1,5 Гб памяти и всё работает как бы быстро благодаря перечисленным мною плагинам для лисы.

А касаемо хрома, то он действительно большой кусок говно-кода.

мнение php-программиста

Никого не интересует.

Достаточно сравнить на достаточно тяжёлой страничке с и без адблока. Но тормоза зависят от скорости памяти и процессора. Хром мне не нравится в основном из-за излишней переупрощённости и отсутствия кастомизации и нормальных аддонов. Ну и много вкладок не открыть.

Неужто так все плохо?

В наши дни, когда html генерится шаблонизаторами в клиентских браузерах, когда серверу достаточно отдавать json, все эти страдания с php кажутся лишними.

поди сублимация или вытеснение какое сработало, Юнгыч

Пользователь задолбался ждать пока у него в браузере «отобразится» твой веб-магазин и идет на другой.

Значит магазин написан через жопу и нужно делать оптимизацию, а не переносить эту жопу на сервер.

Реальный пример из рабочей практики. Веб-студия заказывает «слабый» VPS. Напихивает туда много чего, в результате серверу тупо не хватает оперативы.

Я не понял, это пример экономии на ресурсах сервера в ущерб ресурсам клиента или ты о чем?

Сам придумал, сам посмеялся, молодец, тебе и девушка наверное не нужна.

тебе и девушка наверное не нужна.

К чему это вообще?

Это я о попытках экономить на сервере, которые потом приводят к дополнительным затратам, нивелирующим в итоге экономию на сервере

на пхп5 а не на чём то потяжелее, на С уже никто писать и не подумает, а пхп5 раза в три тяжелее чем пхп2 в то время

лол

Мнение php-программиста

никого не интересует.

Ну пусть так, но опять таки при чём тут код на php выполняемый на стороне сервера и дисковая (или оперативная) память на стороне клиента? Ну предположим для чистоты эксперимента что сервер вообще не использует php и выдаёт статические страницы, какое влияние это окажет на потребление памяти на стороне клиента?

Безусловно - картинки и флешы и js-фреймворки утяжеляют. Только вот и браузеры действительно прожорливые.

Согласен.

Да никакой связи, просто кое-кто (и это не ты) ничего не понимает.

пользователь не знает (/не хочет знать), что такое «оперативная память», он видит только скорость загрузки страницы

что сервер вообще не использует php и выдаёт статические страницы, какое влияние это окажет на потребление памяти на стороне клиента?

например: из-за того, что сейчас страницы генерируются _легко_, довольно легко выдавать клиенту HTML/CSS на несколько мегабайт автосгенерированного кода.

даже когда код генерится условно-вручную, это в 10 раз больше, чем когда-тодавно

например, я обычно генерю все бэкграунды вот этой тулзой: http://www.colorzilla.com/gradient-editor/

оцени какой объем CSS там получается

ну да, она не на PHP, но если была бы на PHP (точнее, экстеншеном к LESS или SASS) в виде библиотеки - конечно использовал бы ее

а раньше когда-то люди геморроились, и выкладывали градиенты картинками, и занимало это одну строчку кода... хорошо что те времена прошли вместе с IE6 =)

Тут ты возможно и прав, просто речь шла про другое. Да, наверное для большинства пользователей единственный значимый фактор - скорость загрузки страниц.

Вот еще, если пошла такая пьянка.

Сейчас люди юзают фреймворки типа Vaadin, GWT итп.

Которые генерят не только декларативный код, но и вполне исполняемый javascript-код

Условно, ты на сервере пишешь «я хочу сюда кнопочку», а тебе генерится 100500 разного и клиентского, и серверного кода

Ну как минимум, любая (первая попавшаяся!) кнопочка подгрузит jQuery. Возможно, даже несколько разных версий jQuery ;) Плагин для dynamic layout тут же подгрузит Twitter Bootstrap, или AngularJS+дополнения, или еще что-то. Ну и фреймворк, на котором всё это пишется. Ну и собственно себя - виджет кнопочки.

И потом это всё стартанет вместе со страницей общаться AJAXом. Например, в Vaadin, каждое второе действие имеет server callback. (по крайней мере так было раньше, может за годы жизни он стал умнее)

Ну и посчитай, ты написал одну строчку «добавить кнопочку», а на клиенте поднялась адская машинерия на десятки/сотни мегабайт RAM и кучу процессора, кучу сети (для ajax)

Неужто так все плохо?

Всё хуже. И страницы сайтов тяжелее, и Хром для показа тех же страниц жрать куда больше стал...

С другой стороны, я помню, как грузились страницы сайтов на 80286/12МГц с 2Мб оперативки в 16-битной Опере :D

Сайт грузится больше 5 секунд? Понижаем его в рейтинге выдачи на 20 позиций для Гугла/Яндекса. И все проблемы. Плохим сайтам - ноль траффика. Медленно работаешь - «пшел нафик». Голосуем ресурсами. Можно даже замерять время загрузки сайтов с помощью плагинов для браузеров и вести картотеку неудачных аутсайдеров-толстячков. Которых помечать каким-нить опасным красным значком, типа толстого самурая, мол, не ходи сюды - раздавит!

Сайт грузится больше 5 секунд?

Ещё бы научить гугл различать обвешанное рекламой и/или жирное вебдванольное говно, с сотней ненужной логики на клиентсайде.

Сколько у него опыта работы?

Не очень большой. Все же, как оказалось, проблема не так проста как кажется

С другой стороны, я помню, как грузились страницы сайтов на 80286/12МГц с 2Мб оперативки в 16-битной Опере :D

И как?)

И как?)

Ну, по несколько минут :) И скроллинг потом тот ещё был — перерисовка страницы занимала секунду-две.

Хотя и в более цивильные времена, когда сидели уже на Первопнях с 16..32Мб оперативки (что позволяло с тогдашним HTML работать комфортно), был долгий период, когда на 10 человек через прокси сидело на одном модеме на 14400 kbps. Пинги были по 60000 ms и страницы (тогдашние, 20кБ на саму страницу без контента норма) тоже минуту могли грузиться :)

14400 kbps.

14.4 kbps

http://programmers.stackexchange.com/questions/221615/why-do-dynamic-language...

Угу, так.

Ты уверен, что он вообще программист?

Программист и php-программист - это как ява и яваскрипт. Вроде и похоже, но вещи разные.

Да я сам php-программист. Тут вопрос в том, что он делает сайты и не понимает, чем server-side отличается от страницы в браузере. Вопрос был без подвоха.

тормознутостью открытия видимо ?