Комментарии 111
Это скрытая реклама своего сервиса по предоставлению DNS.
У меня все еще хуже :)
Total loading time:
8.3 seconds
Total objects:
282 (979.9 KB)
Ну ничего, скоро буду оптимизировать :)
Total loading time:
8.3 seconds
Total objects:
282 (979.9 KB)
Ну ничего, скоро буду оптимизировать :)
tools.pingdom.com особой интеллектуальностью не отличается — грузит абсолютно все картинки из css, даже если они не используются на странице, причем похоже в один поток
а google, по Вашему, отличается?
Может посоветует другой подобный сервис?
Корефан, основатель www.seomoz.org/ пользуется пингдомом и другим советует. Я правда задумал аналог сделать, но программиста найти не могу. Сделать именно для сеошников.
webo.in работает на порядок точнее, чем pingdom, хотя пользует тот же подход: все картинки из CSS, по-другому не получается
Чем же webo.in/ лучше?
все картинки из CSS, по-другому не получается — а точно не получается? или есть выход?
все картинки из CSS, по-другому не получается — а точно не получается? или есть выход?
Тем, что корректно распознает data:URI / mhtml + других ряд более мелких случаев.
+ диаграмма загрузки индиффирентна к загрузке сервера / пингу до него, а не как на pingdom: все сайты из России изначально медленно загружаются.
Для фоновых картинок выход-то есть, но он, может быть, еще хуже — в SpriteMe реализован — брать из DOM все видимые картинки и их анализировать. Только тогда все, что относится к динамике (hover и проч), вылетает…
Т.е. «серебряной пули» здесь не наблюдается.
+ диаграмма загрузки индиффирентна к загрузке сервера / пингу до него, а не как на pingdom: все сайты из России изначально медленно загружаются.
Для фоновых картинок выход-то есть, но он, может быть, еще хуже — в SpriteMe реализован — брать из DOM все видимые картинки и их анализировать. Только тогда все, что относится к динамике (hover и проч), вылетает…
Т.е. «серебряной пули» здесь не наблюдается.
Спасибо, изучаю spriteme.org/
да, мы со Steve'ом там неплохо поработали, качественный вышел продукт
Тогда как оцените code.google.com/webtoolkit/speedtracer/? Выглядит мощнее developer.yahoo.com/yslow/
наиболее мощный сейчас продукт, но не из-за субъективных советов, а из-за того, что собирается статистика для живого сайта, а не синтетические тесты. За этим будущее.
Мы такое где-то год назад запускали, только сервер не выдержал нагрузки от счетчика. Поэтому свернули.
Мы такое где-то год назад запускали, только сервер не выдержал нагрузки от счетчика. Поэтому свернули.
А скриншот хоть того, как работало у вас остался? Или и след простыл? И что за сервер накрылся, полноценный мощный сервер не выдержал?
Накрылись отчеты по многомерным кубам (запросы в базы слишком долго шли). Сама статистика собиралась (а может быть, еще и собирается) в штатном режиме.
Некоторые скрины есть в этой статье
webo.in/articles/all/2009/06-clientside-optimization-vaclavak.ru/
+ здесь
habrahabr.ru/blogs/client_side_optimization/44567/
Вы бы почитали блог «Клиентская оптимизация» что ли… :)
Некоторые скрины есть в этой статье
webo.in/articles/all/2009/06-clientside-optimization-vaclavak.ru/
+ здесь
habrahabr.ru/blogs/client_side_optimization/44567/
Вы бы почитали блог «Клиентская оптимизация» что ли… :)
Теперь официально
Ну и где официальная ссылка?
Скриншот лично мне ни о чём не говорит… Вот если бы адресная строка в кадр попала — другое дело )))
Это Google Инструменты для веб-мастеров — Экспериментальные функции — эффективность сайта.
тьфу это предложения от Page Speed но в инструменты для веб-мастеров это уже разместили
code.google.com/intl/ru-RU/speed/page-speed/
code.google.com/intl/ru-RU/speed/page-speed/
Заглянул уже в панель инструментов Google для веб-мастеров. Да, в «Экспериментальных функциях» появилась «Эффективность сайта». Радует, что с описанием и советами на русском языке:
Про «Эффективность сайта» в справке Google
PS: пока печатал, уже появились ответные комментарии :)
Про «Эффективность сайта» в справке Google
PS: пока печатал, уже появились ответные комментарии :)
Дамс советы по оптимизации загрузки, разместите у себя на домене jquery и google-analytics и включите там gzip ) могли бы и сами gzip'ить скрипты который у них хостяться ^_^
Хабр:
Lib.ru:
Все вполне нормально
Total loading time:
2.2 seconds
Total objects:
115 (861.3 KB)
Lib.ru:
Total loading time:
1.2 seconds
Total objects:
6 (24 KB)
Все вполне нормально
https://www.google.com/webmasters/tools/labs-site-performance-1?hl=en&siteUrl=http%3A%2F%2Fwww.ya.ru%2F зайдите и посмотрите у себя. Тут еще www.google.com/support/webmasters/bin/answer.py?hl=en&answer=158541 и www.google.com/support/forum/p/Webmasters/thread?tid=61ac244dd6e43fcc&hl=en — а официальную ссылку потерял. Но на www.mattcutts.com/blog/ уже мелькало. А это вердикт.
Хабр нелёгонький, я это с мобильника не раз замечал уж.
>морда хабра весит 750 кб
Бот который индексирует текст вряд ли грузит CSS+img+flash. Да и js тоже.
А без этого морда весит 90К. Не так много для 2009 года.
Бот который индексирует текст вряд ли грузит CSS+img+flash. Да и js тоже.
А без этого морда весит 90К. Не так много для 2009 года.
Боты, которые собирают текст для индексации, грузят css ещё с девяностых годов.
Чтобы избежать индексации скрытого и слабочитаемого текста.
Из тех же соображений наверняка уже давно и js грузят и анализируют.
Боты, которые индексируют картинки — разумеется, грузят и картинки.
Чтобы избежать индексации скрытого и слабочитаемого текста.
Из тех же соображений наверняка уже давно и js грузят и анализируют.
Боты, которые индексируют картинки — разумеется, грузят и картинки.
Ах да. Флеш тоже индексируют.
кстати, Вы случайно не в курсе, а что будет, если закрыть js/css файлы в robots.txt, а ссылки в коде естественно скрывать стилями из этих файлов? будет ли их гугл качать?
причем тут бот, гугл же старается для пользователя.
Меньшая страница -> Быстрее загрузка -> Быстрое решение поискового запроса пользователя -> Более релевантный поиск -> Гугл на коне!
Или это только я когда что то ищу гружу сразу несколько результатов в несколько вкладок, пока одни грузятся другие смотрю?
Меньшая страница -> Быстрее загрузка -> Быстрое решение поискового запроса пользователя -> Более релевантный поиск -> Гугл на коне!
Или это только я когда что то ищу гружу сразу несколько результатов в несколько вкладок, пока одни грузятся другие смотрю?
>Быстрое решение поискового запроса пользователя
при запросе гугл по своим индексам в базе ищет, а не по всему интернету ответ ищет.
при запросе гугл по своим индексам в базе ищет, а не по всему интернету ответ ищет.
Под «быстрое решение поискового запроса» подразумевается весь процесс — от ввода запроса в поле поиска и до того момента, когда Вы нашли то, что искали.
Например (цифры примерные, ну чтоб наглядно было):
1. открыть google.com (1 сек)
2. ввести «buy canon 850D body kit» (3 сек)
3. получить выдачу (3 сек — да, тут он себе на уме, сам свою базу быстро обрабатывает)
… и понеслась…
4. клик на резульатате №1. (1 сек)
5. ждем пока загрузится сайт (ждем, емае, чего этот сайт такой тормозной! нахрена там куча картинок и флеш-панорама этого кэнона???) — ***120 сек****
6. дождались, но черт, тут его в наличии нет! (понять — 10 сек)
7. открываем вкладку с гуглом другой результат, номер 2
8. сайт открвается быстро и легко за 3 сек.
9. понять, что в наличии есть и цена устраивает — 10 сек.
10. НАШЛИ.
Видите, где затык?
Если сразу пользователю дать сайт номер 2, который грузится быстро, то пользователь получит решение своего поискового запроса на 2 минуты быстрее.
Нашел кэнон 850д на гугле за 30 секунд, а в Яху — за 5 минут!
Какой поисковик полюбишь?
Например (цифры примерные, ну чтоб наглядно было):
1. открыть google.com (1 сек)
2. ввести «buy canon 850D body kit» (3 сек)
3. получить выдачу (3 сек — да, тут он себе на уме, сам свою базу быстро обрабатывает)
… и понеслась…
4. клик на резульатате №1. (1 сек)
5. ждем пока загрузится сайт (ждем, емае, чего этот сайт такой тормозной! нахрена там куча картинок и флеш-панорама этого кэнона???) — ***120 сек****
6. дождались, но черт, тут его в наличии нет! (понять — 10 сек)
7. открываем вкладку с гуглом другой результат, номер 2
8. сайт открвается быстро и легко за 3 сек.
9. понять, что в наличии есть и цена устраивает — 10 сек.
10. НАШЛИ.
Видите, где затык?
Если сразу пользователю дать сайт номер 2, который грузится быстро, то пользователь получит решение своего поискового запроса на 2 минуты быстрее.
Нашел кэнон 850д на гугле за 30 секунд, а в Яху — за 5 минут!
Какой поисковик полюбишь?
https://www.google.com/webmasters/tools/labs-googlebot-fetch-1 попробуйте, вопросы отпадут. Хоть 2012 год.
Мое скромное мнение — если ресурс делает легковесный, «легкий» на взгляд дизайн, то он должен быть легким и на практике…
>морда хабра весит 750 кб. Мало?!
афигенно не мало, чес слово…
афигенно не мало, чес слово…
web-optimizer будет в плюсе.
Но вот вопрос такой — некоторые советы по ускорению сайта прямо противоречат стандартам. Например, вопиющий — скрипты ставит в подвал. Может в связи с этим, стандарты стоит обновить?
Но вот вопрос такой — некоторые советы по ускорению сайта прямо противоречат стандартам. Например, вопиющий — скрипты ставит в подвал. Может в связи с этим, стандарты стоит обновить?
А что такого в script в подвале?
Там сыро, поэтому они быстро портятся. Не рекомендуется никому хранить свои скрипты в подвале!
например YSlow советует ставить скрипты (например jquery + ваш рабочий Javascript) ставить перед в самом конце HTML-кода. А валидатор на это ругается, мол, «ставь все внутри »
ну вот, Хабр съел мои теги. Имелись ввиду теги /body и /html
Перед закрывающим body, а не в самом конце.
видимо, какой-то плохой DOCTYPE используется. Если внутри body, только в самом конце, то все нормально
да, мы уже почти нашли свой первый миллион инвестиций в связи с этой новостью :)
НЛО прилетело и опубликовало эту надпись здесь
тогда идём дальше, не используйте js, не используйте картинки и оптимизировать не понадобится.
у меня на проекте были скрипты, для реализации эффектов, размер 78295, в то же время jquery около 30K + 6K реализация тех же эффектов на jquery.
у меня на проекте были скрипты, для реализации эффектов, размер 78295, в то же время jquery около 30K + 6K реализация тех же эффектов на jquery.
НЛО прилетело и опубликовало эту надпись здесь
Ни разу не оправдывая излишнее увлечение фреймворками, хочу всё-таки поинтересоваться: вы как, без костылей в виде стандартных библиотек обходитесь? А STL назвать программированием можно?
И да, как вы относитесь к тем, кто до сих пор использует телетайп в качестве терминала?
И да, как вы относитесь к тем, кто до сих пор использует телетайп в качестве терминала?
НЛО прилетело и опубликовало эту надпись здесь
Страница с единственной формой логина на сайте из вашего профайла — суммарным весом в 533 Кб (!) — говорит об очень трогательном подходе к проблеме слабого проникновения высокоскоростной связи.
Особенно прекрасен вот этот ява-скрипт (за подписью Jörn Zaefferer and Brandon Aaron). Без блокнота такого не написать, конечно.
Особенно прекрасен вот этот ява-скрипт (за подписью Jörn Zaefferer and Brandon Aaron). Без блокнота такого не написать, конечно.
НЛО прилетело и опубликовало эту надпись здесь
Да то понятно. А вот www.o.kg — ваша работа?
НЛО прилетело и опубликовало эту надпись здесь
Тогда будем считать, что не в вашей части было:
1) вес страницы в 186 Кб, не считая флеша
2) невозможность отключить флеш, даже указанной для этого кнопкой
3) использование «прикольной, завораживающей моталки» — вы ведь не любитель сторонних костылей
4) очень «лаконичный» css
Честное слово, если использовать неосознанное зло jQuery — половину кода всех страниц можно выкинуть. Там ведь сплошной копипаст.
Или это тоже не ваша часть?
1) вес страницы в 186 Кб, не считая флеша
2) невозможность отключить флеш, даже указанной для этого кнопкой
3) использование «прикольной, завораживающей моталки» — вы ведь не любитель сторонних костылей
4) очень «лаконичный» css
Честное слово, если использовать неосознанное зло jQuery — половину кода всех страниц можно выкинуть. Там ведь сплошной копипаст.
Или это тоже не ваша часть?
НЛО прилетело и опубликовало эту надпись здесь
можно ссылки на свежие и актуальные проекты, которые делали полностью вы или ваша команда?
> Покажите, что бы вы выкинули изо всех страниц, будь у вас жквери.
Меню, начинающееся с <div class=«highlevel»>
Меню, начинающееся с <div class=«highlevel»>
НЛО прилетело и опубликовало эту надпись здесь
Им не повезло?)
вот именно, это говорит, что плохому танцору всё время что-то мешает. а, когда пишешь свой велосипед, можно получить самокат размером с самосвал, который будет ломаться на каждом повороте.
Ваш совет хорош, только последовать ему могут не многие, потому что у большинства получится ещё хуже. В своей жизни видел массу примеров.
>>И да, как вы относитесь к тем, кто до сих пор использует модем?
Думаю вы имели ввиду диал ап? Тогда — с сочувствием, сам с сентября сидел месяца два, ругался плевался на гмэйл, но всё же юзал аджакс морду и даже грузил картинки на сайтах.
Ваш совет хорош, только последовать ему могут не многие, потому что у большинства получится ещё хуже. В своей жизни видел массу примеров.
>>И да, как вы относитесь к тем, кто до сих пор использует модем?
Думаю вы имели ввиду диал ап? Тогда — с сочувствием, сам с сентября сидел месяца два, ругался плевался на гмэйл, но всё же юзал аджакс морду и даже грузил картинки на сайтах.
НЛО прилетело и опубликовало эту надпись здесь
если бы он цеплял самописный фреймворк, то можно было спросить зачем. а если jquery из гугла, то логика есть, он с большой вероятностью уже есть в кэше. всё относительно.
но и на фрэймворках бывают такого понаделывают :( жаль, что нет «серебрянной пули».
но и на фрэймворках бывают такого понаделывают :( жаль, что нет «серебрянной пули».
>жвери для проверки заполнения поля адреса электронной почты
Мне больше нравится постоянно возникающий на хабре jQuery-plugin, который выводит баннер «Stop IE6!»
Мне больше нравится постоянно возникающий на хабре jQuery-plugin, который выводит баннер «Stop IE6!»
wordpress зло, но часто меньшее, чем самописный код — и это тоже факт
Сегодня, использование библиотек программистами — повседневная обыденность. Если вы хороший программист, вы должны ценить свое время.
По какой причине вы используете перл, если это «надстройка» над Си, в несколько раз более медленная?
Во время, когда объем жестких дисков, оперативной памяти и процессорного времени удешевляется практически дважды ежегодно, нам рациональнее всего использовать наработки других людей.
Естественно, речь идет о повседневных задачах. Особенные задачи (например, узкие места), конечно же, рациональнее писать самостоятельно.
По какой причине вы используете перл, если это «надстройка» над Си, в несколько раз более медленная?
Во время, когда объем жестких дисков, оперативной памяти и процессорного времени удешевляется практически дважды ежегодно, нам рациональнее всего использовать наработки других людей.
Естественно, речь идет о повседневных задачах. Особенные задачи (например, узкие места), конечно же, рациональнее писать самостоятельно.
так и делаю — оптимизация всё равно требуется.
как-минимум на крупных проектах.
как-минимум на крупных проектах.
Особенно интересно натравить это на blogger (в общем-то сервис гугла), и смотреть на то, что гугл сам себе рекомендует исправиться :)
Вот касательно скорости загрузки страниц возникают некоторые вопросы в общем-то. Возможно я не смотрел подробно методы оптимизации и т.д. но на сегодняшний день все оптимизаторы предлагают для ускорения загрузки соединять все css в один файл и все это прогонять ещё алгоритмами для уменьшения размера и т.д.
Отсюда и выходит вопрос: а что если у меня используется 3 отдельных css файла (1 — для всех страниц; 2 — только для страниц с формами; 3 — для страниц с каталогом). Все эти css относительно большие к примеру.
1. Зачем тогда мне их слепливать вместе и грузить на всех страницах, ведь это в некотором смысле тоже замедлит загрузку моих страниц для пользователей пришедших по линку извне на какую-либо из страниц…
2. а что если этих стилей и отдельных скриптов ещё больше?
3. а что если в некоторых файлах эти стили переопределяют родные из основного css файла?
Отсюда и выходит вопрос: а что если у меня используется 3 отдельных css файла (1 — для всех страниц; 2 — только для страниц с формами; 3 — для страниц с каталогом). Все эти css относительно большие к примеру.
1. Зачем тогда мне их слепливать вместе и грузить на всех страницах, ведь это в некотором смысле тоже замедлит загрузку моих страниц для пользователей пришедших по линку извне на какую-либо из страниц…
2. а что если этих стилей и отдельных скриптов ещё больше?
3. а что если в некоторых файлах эти стили переопределяют родные из основного css файла?
Вопрос интересный. Сам мучаюсь, как лучше сделать.
code.google.com/speed/page-speed/
code.google.com/speed/page-speed/
ответа нет. Точнее, ответ в общем виде был дан в этой статье — выход «алгоритмическое кэширование»
webo.in/articles/habrahabr/48-flow-slices-optimization/
чем меньше обращаемся, тем больше может быть файл. Некоторые стили можно и в сам HTML закинуть.
webo.in/articles/habrahabr/48-flow-slices-optimization/
чем меньше обращаемся, тем больше может быть файл. Некоторые стили можно и в сам HTML закинуть.
Если не затрагивать 2-й вопрос, то выходом может быть создание 3-х файлов:
— для форм: склеить 1 и 2
— для каталога: склеить 1 и 3
— для всех остальных отдавать существующий 1
Чтобы избежать правок в 3-х местах, склеивать можно автоматом при деплое приложения. Если в 1 много стилей переопределяемых в 2 и 3, то можно ручками (а может и скрипты уже есть) удалять при склейке из 1 «мертвые» правила, что не только сократит размер, но и увеличит скорость отрисовки страницы браузером.
— для форм: склеить 1 и 2
— для каталога: склеить 1 и 3
— для всех остальных отдавать существующий 1
Чтобы избежать правок в 3-х местах, склеивать можно автоматом при деплое приложения. Если в 1 много стилей переопределяемых в 2 и 3, то можно ручками (а может и скрипты уже есть) удалять при склейке из 1 «мертвые» правила, что не только сократит размер, но и увеличит скорость отрисовки страницы браузером.
Ну и намудрили. Не выход. Совсем не выход. Только усложнили.
Для кого усложнение? Было 3 файла, скажем, по 10 кБ, стало два по 20 (если не оптимизировать «мертвые» правила") и один остался 10. Трафика расходуется на 20 кБ больше лишь при первоначальной прогрузке форм и каталогов (если считать, что CSS попадают в кеш браузера), зато при остальных обращениях браузер обрабатывает только один файл, а не два.
очень правильно склеивать все стили и JS в минимум файлов, при публикации проекта в веб.
НЛО прилетело и опубликовало эту надпись здесь
Есть еще Yslow для FireBug/FireFox, дает аналогичные рекомендации. И не стоит искать скрытый смысл в сообщении по поводу DNS lookup на GoogleAnalytics, речь идет о злоупотреблении картинками с чужих серверов, каждая такая картинка тянет за собой еще и лишний запрос к DNS.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Скорость имеет значение. Теперь официально