Очень правильное замечание на счёт того, что долгогрузящиеся сайты должны иметь нормальный прелоудер/прогресс бар. По себе скажу, что ждать 10 секунд загрузку сайта в IE очень сложно после того, как я привык к Opera в которой есть статус бар с инфой что КОНКРЕТНО СЕЙЧАС делает браузер. FF и IE пишут что-то абстрактное и совсем не понятно - рухнул сайт, не нашёлся домен или ещё что. Сидишь и ждёшь как дурак. Это раздражает.
Этим комментом я какбе хочу сказать, что разработчики браузеров должны задуматься о том, как удержать пользователя на долгоотвечающем сайте. И на мой взгляд проще всего пойти путём Opera - сделать информативный статус бар.
У вас на сайте, который указан в профиле, выпадающее меню нормально работает только в IE. В FF после раскрытия обратно не закрывается, в Opera не работает совсем. А так все правильно ;)
"Nah заключила, что ТВО для веб-пользователей имеет максимум около 2 секунд"
Супер :)
В статье информации маловато, зато ссылочки интересные, почитаемс.
Все зависит от ценности контента. Если контент уникальный, то будем жать на reload, пока не загрузится, и еще завтра придем - проверить, не исчезло ли сообщение об ошибке. И потом еще через неделю.
А бывают парадоксы:
при моей безлимитке 64 кб/с страница, содержащая немного текста, грузится очень долго, а страница igoogle, перегруженная виджетами загражается за считаные 2-3 секунды. Плохая оптимизация?
Наоборот хорошая... у Гугла :)
А вообще есть еще ширина каналов провайдера, сайта и пиковая на них нагрузка, сложно так сразу сказать где именно лаги образуются.
Вот это понимаю актуальная тема. С увеличением размера канала выхода в интернет, многие забывают, что даже простая оптимизация картинок может существенно уменьшить скорость загрузки. Сам помешан на ускорении всего что попадается под руку. Спасибо за полезную статью и особенно за доп. материалы.
Предыдущем исследование продемонстрировало, что пользовательское раздражение сильно возрастает, если скорость загрузки страницы превышает 8–10 секунд безо всякого уведомления пользователя о процессе загрузки (Bouch, Kuchinsky и Bhatti, 2000, King, 2003).
8-10 секунд в 2000 году, на диалапе 19200... они наверно хотели сказать 80:)
прочитал, статью зашел webo.in, ускорил сайт на 35%
вот оказалось что на хостинге РБК, работает gzip сдатие для php файлов, а для css и js оно почему-то отключено.
нашел выход, так как мои js и css файлы редко обновляються то подошел такой способ,
в htacces файле нужно написать
и загрузить туда сжатые копии файлов
тоесть получаеться два файла
style.css который отдаеться если клиент не поддерживает сжатие
и
style.css.gz если поддерживает, очень доволен:))
ещё узнал что если сжимать js через регулярные выражения, тоесть packed, а потом gzip'ом то объем файла только увеличиваеться. а лучше убрать пробелы и лишнии символы переименовать переменные в более короткие,
помогла программка custom_rhino.jar (http://dojotoolkit.org/docs/shrinksafe)
а для css http://www.codebeautifier.com
и на последок объединил файлы в один, для уменьшения количества запросов,
хотя я так понял если клиент открывает содеинениее с параметром
Connection:прочитал, статью зашел webo.in, ускорил сайт на 35%
вот оказалось что на хостинге РБК, работает gzip сдатие для php файлов, а для css и js оно почему-то отключено.
нашел выход, так как мои js и css файлы редко обновляються то подошел такой способ,
в htacces файле нужно написать
и загрузить туда сжатые копии файлов
тоесть получаеться два файла
style.css который отдаеться если клиент не поддерживает сжатие
и
style.css.gz если поддерживает, очень доволен:))
ещё узнал что если сжимать js через регулярные выражения, тоесть packed, а потом gzip'ом то объем файла только увеличиваеться. а лучше убрать пробелы и лишнии символы переименовать переменные в более короткие,
помогла программка custom_rhino.jar (http://dojotoolkit.org/docs/shrinksafe)
а для css http://www.codebeautifier.com
и на последок объединил файлы в один, для уменьшения количества запросов,
хотя я так понял если клиент открывает содеинениее с параметром
Connection:прочитал, статью зашел webo.in, ускорил сайт на 35%
вот оказалось что на хостинге РБК, работает gzip сдатие для php файлов, а для css и js оно почему-то отключено.
нашел выход, так как мои js и css файлы редко обновляються то подошел такой способ,
в htacces файле нужно написать
и загрузить туда сжатые копии файлов
тоесть получаеться два файла
style.css который отдаеться если клиент не поддерживает сжатие
и
style.css.gz если поддерживает, очень доволен:))
ещё узнал что если сжимать js через регулярные выражения, тоесть packed, а потом gzip'ом то объем файла только увеличиваеться. а лучше убрать пробелы и лишнии символы переименовать переменные в более короткие,
помогла программка custom_rhino.jar (http://dojotoolkit.org/docs/shrinksafe)
а для css http://www.codebeautifier.com
ok, спасибо.
с условиями (IfModule mod_rewrite.c) у меня не сработало
зато я убрал Safari и Konqueror, странно что они не могли сделать поддержку gzip.
не работает возможно из-за того что на хостинге nginx вместо apache.
посмотрел nginx.conf то там
#gzip on
тоесть выключен.
можно его как-то включить через htaccess для nginx?
вот глюк:)) я не тот nginx.conf смотрел, а тот что нужен не смог найти.
зато оказалось что на хостинге РБК включено сжатие для txt файлов, а для css и js выключено :))
если файл переименовать в style.js.txt то сжатие работает
но Content-Type: text/html; charset=UTF-8
вместо Content-Type: text/css
с txt файлами почему-то не получилось, может из-за того что nginx нужно чтоб файл посылал header text/plain для того чтоб его сжать, а с этим header'ом в firefox не отображаеться css.
решил сделать так, чтоб снизить лишнюю нагрузку на сервер
Психология веб-производительности, или когда время равно деньги