Ниже перевод статьи "Optimizing Page Load Time", в которой автор математически рассчитывает оптимальный размер файлов для эффективной передачи при веб-запросах, рассматривает некоторые прикладные вопросы оптимизации загрузки страницы с учетом особенностей браузеров, а также дает несколько развернутых и ценных советов. Мои комментарии далее курсивом.
Существует распространенное мнение, что быстро загружающая страница положительно влияет на впечатление пользователя (improve the user experience). В последние годы многие сайты начали использовать для этой цели технологию AJAX, чтобы уменьшить время ожидания (при загрузке данных). Вместо того, что запрашивать с сервера новую страницу полностью при каждом клике, браузер часто можно либо поменять вид самой страницы (отобразив или скрыв какие-либо блоки), либо подгрузить небольшую порцию HTML-, XML- или JavaScript-кода и внести изменения на существующую страницу. В любом случае, это значительно уменьшает время, проходящее между кликом пользователя и окончанием визуализации браузером нового содержания.
Что влияет на загрузку страницы?
Однако, для большинства сайтов, загрузка страницы затрагивает десятки внешних объектов, основное время загрузки тратится на различные HTTP-запросы картинок, JavaScript-файлов и файлов стилей. AJAX, возможно, поможет в данной ситуации, но ускорение или удаление этих HTTP-запросов может принести гораздо больше пользы, хотя на данный момент нет единого мнения (a common body of knowledge), как именно это следует делать.
читать дальше на webo.in →
комментарии (49)
Btw: может быть, "оптимизируем загрузку веб-страницы"? Вроде как и по переводу подходит больше, и сама статья только анализом не ограничивается .)
http://webo.in/articles/
а там уже есть "оптимизируем..." :) слова закончились
+Fav
А так - животрепешуший вопрос - где можно взять построителя этих симпошных картинок чтобы свои проекты потестить?
http://tools.pingdom.com/fpt/
есть неплохой анализатор, строящий графики загрузки наподобие YSlow (на англйиском), а на
http://webo.in/
есть просто анализатор скорости загрузки (на русском)
Исправьте, пожалуйста.
Автомобиль, с максимально-возможной скоростью движения 40км/ч. не будет двигаться по автобану на скорости 150км/ч. Потому, что не умеет :)
Допустим, у Вас на сервере лежат следующие файлы:
— index.html;
— javascript.js;
— styles.css;
— image1.gif;
— image2.gif;
— image3.gif;
— image4.gif;
— image5.gif;
— image6.gif.
В index.html все эти файлы инклудятся в страницу и загружаются браузером. Так вот в этой теме разговор ведётся о том, как серверу быстрее отдавать эти файлы, а браузеру их быстро загружать. Причём, чтобы браузер лишний раз не загружал с сервера НЕ ИЗМЕНИВШИЕСЯ файлы (styles.css; javascript.js; imagesN.gif), а брал их из кэша. То есть при хорошей настройке клиент будет загружать только HTML (изменившийся), а остальное будет брать из кэша. Какой смысл грузить то, что не менялось?
И неважно какая у Вас скорость доступа. Важно, как быстро сервер отдаст браузеру эти файлы, по какому пути эти файлы идут к Вам на компьютер, и как их много. Если Вы заметили, тут обсуждаются ещё и очерёдность загрузки этих файлов, да и ещё много чего.
Честно признаться, мне пока не удаётся победить кэш. Как я ни стараюсь.
Пример www.nba.com очень тяжелая страница , грузится 3 - 5 секунд макс. Ну а если ваша страничка слишком медленно загружается , есть много вариантов, кривая верстка, кривые настройки сервера, полохой хостинг , кривой движок.
CSS Sprites — как бритва Оккамы, если профессионализм разработчика позволяет их использовать (так, чтобы все выглядело хорошо), то они используются, иначе — это уже камни в огород разработчика.
Однако, вторая половина включает технологии кеширования и gzip'ования HTML, которые также способны ускорить загрузку на 30-50%
А для HTML кода самое лутчшее уберать на стороне сервера все лишнее пробелы и переносы строк и отправлять браузеру такой код. К стати в Файерфоксе в некоторых ситуациях чтобы Javascritp работал правильно надо так обезательно делать.
Попробуйте поресайзить http://www.creative.su — там картинки никуда не уползают.
Ну а про CSS Sprites сделано удачно. Только такой не знаю на резине как будет себя вести. Но для вашей страничке то что надо.
что-то мне не нравятся эти игры с пиаром и отводом трафика…
а тут получается, можно написать интересную статью, получить 100 балов и поменять на чёрного властелина :-)
я за апдейты без координального изменения контента, друг ;-)
Наоборот, плохо то, что IT-шники сторонятся их и не пользуются ими. В результате даже с их немудрящим маркетингом Microsoft с "виндой галимой" делает Linux как черепаху с точки зрения бизнеса.
Между прочим, даже создатели "Хабра" используют его именно как маркетинговый инструмент. Вы вот много слышали о Futurico раньше? ;-)
вы абсолютно правы — it-шники не умеют ими пользоваться, ждут готовых решений от гугл, яндекса и подобных. но я отстаиваю не пиар в данной беседе, а изменение контента автором.
я был удивлён, что, проголосовав за полную статью, и, положив её в закладки, я обнаружил её отсутствие на хабре. стало просто неприятно. значит, я зря пометил звёздочкой её в гугл ридере? а ведь можно было сразу поставить ссылку и я бы положил её в избранное и не чувствовал бы себя «обманутым».
Иначе все маркетинговые ходы можно признать неудачными
Лишь потому, что под роликами мелким шрифтом стояли ссылки на мой блог и студию. Шума и вони он поднял очень много, возможно, даже у кого-то смог создать иллюзию "народного негодования" посредством виртуалов.
Но если судить не по возмущениям одного человека, а смотреть на картину в целом (посты в блогах, комментарии, письма) — то все наоборот. 99% одобряют сами ролики, а к ссылкам под ними относятся нейтрально.
Так что, конечно же, судить об удачности маркетингового хода с подменой ссылок нужно по динамике числа посещений и подписчиков того блога.
в целом согласен, что корректные данные в хттп запросе могут значительно улучшить статистику.
только вот для сайтов с большой посещаемостью намного важнее поработать над кешированием, оптимизацией работы с базой.