Pull to refresh

Comments 111

Это скрытая реклама своего сервиса по предоставлению DNS.
Это в итоге типа будет так, что если днс не гугловский, то на первые 50 страниц результатов поиска не попадаешь?
Интересно, каким образом связан гугловский кэширующий ДНС и веб-сервер в данном случае?
Да-да, конечно связи нет, сходу просто вот такая первая ассоциация возникла из предложенных элементов — Гугл, DNS, SERP

А может где-то и есть связь, просто сразу не видна…
У меня все еще хуже :)

Total loading time:
8.3 seconds
Total objects:
282 (979.9 KB)

Ну ничего, скоро буду оптимизировать :)
tools.pingdom.com особой интеллектуальностью не отличается — грузит абсолютно все картинки из css, даже если они не используются на странице, причем похоже в один поток
а google, по Вашему, отличается?
мне кажется, что google всё таки не грузит все картинки из css
картинки грузит только Image Search crawler
Может посоветует другой подобный сервис?
Корефан, основатель www.seomoz.org/ пользуется пингдомом и другим советует. Я правда задумал аналог сделать, но программиста найти не могу. Сделать именно для сеошников.
webo.in работает на порядок точнее, чем pingdom, хотя пользует тот же подход: все картинки из CSS, по-другому не получается
Чем же webo.in/ лучше?
все картинки из CSS, по-другому не получается — а точно не получается? или есть выход?
Тем, что корректно распознает data:URI / mhtml + других ряд более мелких случаев.
+ диаграмма загрузки индиффирентна к загрузке сервера / пингу до него, а не как на pingdom: все сайты из России изначально медленно загружаются.

Для фоновых картинок выход-то есть, но он, может быть, еще хуже — в SpriteMe реализован — брать из DOM все видимые картинки и их анализировать. Только тогда все, что относится к динамике (hover и проч), вылетает…
Т.е. «серебряной пули» здесь не наблюдается.
да, мы со Steve'ом там неплохо поработали, качественный вышел продукт
наиболее мощный сейчас продукт, но не из-за субъективных советов, а из-за того, что собирается статистика для живого сайта, а не синтетические тесты. За этим будущее.

Мы такое где-то год назад запускали, только сервер не выдержал нагрузки от счетчика. Поэтому свернули.
А скриншот хоть того, как работало у вас остался? Или и след простыл? И что за сервер накрылся, полноценный мощный сервер не выдержал?
Накрылись отчеты по многомерным кубам (запросы в базы слишком долго шли). Сама статистика собиралась (а может быть, еще и собирается) в штатном режиме.
Некоторые скрины есть в этой статье
webo.in/articles/all/2009/06-clientside-optimization-vaclavak.ru/
+ здесь
habrahabr.ru/blogs/client_side_optimization/44567/

Вы бы почитали блог «Клиентская оптимизация» что ли… :)
Теперь официально

Ну и где официальная ссылка?
Скриншот лично мне ни о чём не говорит… Вот если бы адресная строка в кадр попала — другое дело )))
Это Google Инструменты для веб-мастеров — Экспериментальные функции — эффективность сайта.
Заглянул уже в панель инструментов Google для веб-мастеров. Да, в «Экспериментальных функциях» появилась «Эффективность сайта». Радует, что с описанием и советами на русском языке:

Про «Эффективность сайта» в справке Google
PS: пока печатал, уже появились ответные комментарии :)
Дамс советы по оптимизации загрузки, разместите у себя на домене jquery и google-analytics и включите там gzip ) могли бы и сами gzip'ить скрипты который у них хостяться ^_^
Вопрос, у какого процента посетителей скрипты google-analytics (да и jquery) уже закэшированы при посещении других сайтов? Если у большого, то перенос к себе может привести к ухудшению.
:) а вот насчет этого ничего не известно, к тому же я думаю что у большинства оно уже закэшировалось, так что переносить не стоит ) поэтому и удивлен таким советам :)
Советы от гугла что гуглохостинг это плохо :)
Хабр:
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 ещё с девяностых годов.
Чтобы избежать индексации скрытого и слабочитаемого текста.

Из тех же соображений наверняка уже давно и 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 минут!
Какой поисковик полюбишь?

про такую логику не подумал, да
вообще не нашёл кэнон 850д (только ссылки на ваш пост)
Я специально его придумал, чтобы показать эталонную ситуацию и пресечь субъективные мнения
а я уж испугался, что пропустил пару релизов от сапога. прошу прощенья.
https://www.google.com/webmasters/tools/labs-googlebot-fetch-1 попробуйте, вопросы отпадут. Хоть 2012 год.
Мое скромное мнение — если ресурс делает легковесный, «легкий» на взгляд дизайн, то он должен быть легким и на практике…
С другой стороны корни моих взысканий идут с привычек конца 80-х, начала 90-х, когда мегабайт был МЕГАБАЙТОМ… Вопрос спорный…
>морда хабра весит 750 кб. Мало?!
афигенно не мало, чес слово…
web-optimizer будет в плюсе.

Но вот вопрос такой — некоторые советы по ускорению сайта прямо противоречат стандартам. Например, вопиющий — скрипты ставит в подвал. Может в связи с этим, стандарты стоит обновить?
А что такого в script в подвале?
Там сыро, поэтому они быстро портятся. Не рекомендуется никому хранить свои скрипты в подвале!
например YSlow советует ставить скрипты (например jquery + ваш рабочий Javascript) ставить перед в самом конце HTML-кода. А валидатор на это ругается, мол, «ставь все внутри »
ну вот, Хабр съел мои теги. Имелись ввиду теги /body и /html
Перед закрывающим body, а не в самом конце.
не придирайтесь, я ж написал, что хабр съел теги. Там было «ставить перед </боди></хтмл> в самом конце кода».
W3C пишет:
«The script element places a script within a document. This element may appear any number of times in the HEAD or BODY of an HTML document»
Спасибо вам. Почему-то был уверен, что скрипты внизу — это нарушение стандартов. Сейчас проверил — нет. Открыли глаза. Поставил плюс.
видимо, какой-то плохой DOCTYPE используется. Если внутри body, только в самом конце, то все нормально
да, мы уже почти нашли свой первый миллион инвестиций в связи с этой новостью :)
UFO just landed and posted this here
тогда идём дальше, не используйте js, не используйте картинки и оптимизировать не понадобится.
у меня на проекте были скрипты, для реализации эффектов, размер 78295, в то же время jquery около 30K + 6K реализация тех же эффектов на jquery.
UFO just landed and posted this here
Ни разу не оправдывая излишнее увлечение фреймворками, хочу всё-таки поинтересоваться: вы как, без костылей в виде стандартных библиотек обходитесь? А STL назвать программированием можно?

И да, как вы относитесь к тем, кто до сих пор использует телетайп в качестве терминала?
UFO just landed and posted this here
Страница с единственной формой логина на сайте из вашего профайла — суммарным весом в 533 Кб (!) — говорит об очень трогательном подходе к проблеме слабого проникновения высокоскоростной связи.

Особенно прекрасен вот этот ява-скрипт (за подписью Jörn Zaefferer and Brandon Aaron). Без блокнота такого не написать, конечно.
UFO just landed and posted this here
UFO just landed and posted this here
Тогда будем считать, что не в вашей части было:

1) вес страницы в 186 Кб, не считая флеша
2) невозможность отключить флеш, даже указанной для этого кнопкой
3) использование «прикольной, завораживающей моталки» — вы ведь не любитель сторонних костылей
4) очень «лаконичный» css

Честное слово, если использовать неосознанное зло jQuery — половину кода всех страниц можно выкинуть. Там ведь сплошной копипаст.

Или это тоже не ваша часть?
UFO just landed and posted this here
можно ссылки на свежие и актуальные проекты, которые делали полностью вы или ваша команда?
UFO just landed and posted this here
Мне тоже хочется на деле убедится в достоверности ваших возможностей, если все так как вы говорите то перенять опыт
> Покажите, что бы вы выкинули изо всех страниц, будь у вас жквери.

Меню, начинающееся с <div class=«highlevel»>
UFO just landed and posted this here
Неужели так трудно головой подумать? Убрать 20 Кб со всех страниц, прицепив 80 Кб единожды.
UFO just landed and posted this here
Это можно. С предложением сроков и оплаты за рефакторинг кода прошу в личку. На этом болтовню в комментах прекращаю, прошу прощения у хабровцев.
UFO just landed and posted this here
Заказывайте, народ ждет.
UFO just landed and posted this here
вот именно, это говорит, что плохому танцору всё время что-то мешает. а, когда пишешь свой велосипед, можно получить самокат размером с самосвал, который будет ломаться на каждом повороте.
Ваш совет хорош, только последовать ему могут не многие, потому что у большинства получится ещё хуже. В своей жизни видел массу примеров.
>>И да, как вы относитесь к тем, кто до сих пор использует модем?
Думаю вы имели ввиду диал ап? Тогда — с сочувствием, сам с сентября сидел месяца два, ругался плевался на гмэйл, но всё же юзал аджакс морду и даже грузил картинки на сайтах.

UFO just landed and posted this here
если бы он цеплял самописный фреймворк, то можно было спросить зачем. а если jquery из гугла, то логика есть, он с большой вероятностью уже есть в кэше. всё относительно.
но и на фрэймворках бывают такого понаделывают :( жаль, что нет «серебрянной пули».
>жвери для проверки заполнения поля адреса электронной почты
Мне больше нравится постоянно возникающий на хабре jQuery-plugin, который выводит баннер «Stop IE6!»
wordpress зло, но часто меньшее, чем самописный код — и это тоже факт
UFO just landed and posted this here
заказчик в идеале выбирает сам, хочет быстро и дёшево — получает wp, дорого и сердито — расчитывает на велосипед студии. только, наверняка, вы и сами знаете, какие велосипеды получаются у большинства новорождённых веб студий.
Сегодня, использование библиотек программистами — повседневная обыденность. Если вы хороший программист, вы должны ценить свое время.
По какой причине вы используете перл, если это «надстройка» над Си, в несколько раз более медленная?
Во время, когда объем жестких дисков, оперативной памяти и процессорного времени удешевляется практически дважды ежегодно, нам рациональнее всего использовать наработки других людей.

Естественно, речь идет о повседневных задачах. Особенные задачи (например, узкие места), конечно же, рациональнее писать самостоятельно.
UFO just landed and posted this here
так и делаю — оптимизация всё равно требуется.
как-минимум на крупных проектах.
Особенно интересно натравить это на blogger (в общем-то сервис гугла), и смотреть на то, что гугл сам себе рекомендует исправиться :)
Да, это действительно трогательно. Только смысл не удается постичь.
Вот касательно скорости загрузки страниц возникают некоторые вопросы в общем-то. Возможно я не смотрел подробно методы оптимизации и т.д. но на сегодняшний день все оптимизаторы предлагают для ускорения загрузки соединять все css в один файл и все это прогонять ещё алгоритмами для уменьшения размера и т.д.
Отсюда и выходит вопрос: а что если у меня используется 3 отдельных css файла (1 — для всех страниц; 2 — только для страниц с формами; 3 — для страниц с каталогом). Все эти css относительно большие к примеру.
1. Зачем тогда мне их слепливать вместе и грузить на всех страницах, ведь это в некотором смысле тоже замедлит загрузку моих страниц для пользователей пришедших по линку извне на какую-либо из страниц…
2. а что если этих стилей и отдельных скриптов ещё больше?
3. а что если в некоторых файлах эти стили переопределяют родные из основного css файла?
ответа нет. Точнее, ответ в общем виде был дан в этой статье — выход «алгоритмическое кэширование»
webo.in/articles/habrahabr/48-flow-slices-optimization/
чем меньше обращаемся, тем больше может быть файл. Некоторые стили можно и в сам HTML закинуть.
Если не затрагивать 2-й вопрос, то выходом может быть создание 3-х файлов:
— для форм: склеить 1 и 2
— для каталога: склеить 1 и 3
— для всех остальных отдавать существующий 1

Чтобы избежать правок в 3-х местах, склеивать можно автоматом при деплое приложения. Если в 1 много стилей переопределяемых в 2 и 3, то можно ручками (а может и скрипты уже есть) удалять при склейке из 1 «мертвые» правила, что не только сократит размер, но и увеличит скорость отрисовки страницы браузером.
Ну и намудрили. Не выход. Совсем не выход. Только усложнили.
Для кого усложнение? Было 3 файла, скажем, по 10 кБ, стало два по 20 (если не оптимизировать «мертвые» правила") и один остался 10. Трафика расходуется на 20 кБ больше лишь при первоначальной прогрузке форм и каталогов (если считать, что CSS попадают в кеш браузера), зато при остальных обращениях браузер обрабатывает только один файл, а не два.
очень правильно склеивать все стили и JS в минимум файлов, при публикации проекта в веб.
UFO just landed and posted this here
Идеал всякой оптимизации. Попробуйте сделать меньше, чтобы не потерять функционал и чтобы фотки не изуродовать. Мне уже не получилось.
UFO just landed and posted this here
Да, грузиться долго. Фотки хоть сжали бы чуток. Глазу не заметно, браузер за то бегает.
UFO just landed and posted this here
AdblockPlus — да, хороший совет.
Есть еще Yslow для FireBug/FireFox, дает аналогичные рекомендации. И не стоит искать скрытый смысл в сообщении по поводу DNS lookup на GoogleAnalytics, речь идет о злоупотреблении картинками с чужих серверов, каждая такая картинка тянет за собой еще и лишний запрос к DNS.
Sign up to leave a comment.

Articles