Nikeee, ты код ошибок дай, а не время доступа.
Ну это не только к ВП :)
Но его работоспособность, насколько я понимаю, зависит не только от браузера, но и от сервера. Ведь как минимум пхп должен быть собран с поддержкой gzip.
Почитай описание функции по ссылке выше - ЮА должен понимать этот метод сжатия.
Я ж и говорю - тут надо индивидуально смотреть. В конкретных условиях. Так же как и с кешированием.
А что ж будет рисоваться, если не его содержимое? Особенно в случае с 5-ти кратно вложенными дивами\спанами. ;)
Т.е. @import url("layout.css"); в style.css будет дольше, чем
<link rel="stylesheet" href="css/layout.css" type="text/css" media="all"><link rel="stylesheet" href="css/style.css" type="text/css" media="all">
в коде страницы?
Хм.. наверное да, логично.
+150
Китaёзa детектед :)
+1. Сие есть зло на 99% сайтах :)
Да. И для этого используется предзагрузка.
Судя по названию это скрипт для предзагрузки картинок (некоторых. Наверняка для слайдера какого-нить). Вещь в принципе полезная - юзер не будет ждать пока след. слайд догрузится. Правда, это же снижает общую скорость загрузки страницы. Особенно для "низкоскоростных" юзеров.
Так то, я спрашивал тех кто знает :)
В Амстердаме не один провайдер и ДЦ ;) (хотя я не знаю как работает конкретно пингдомтулс. Но обычно такие сервисы делят нагрузку на разные сервера\ДЦ)
Один я вижу несоответствие? ;)
ТС,:
<a href="<?php echo $_SERVER['REQUEST_URI'] ?>?sort=pd.name&order=ASC">Алфавит</a>
Тут надо смотреть по месту. Этот как с кешированием - палка о двух концах. Может случится, что на упаковку понадобится больше времени, чем на отдачу не пакованного.
А вот, кстати... я чот толком не помню - загружаются\запрашиваются ли картинки из ЦСС если правила, где они прописаны, не задействованы на вызываемой странице? Вроде как нет, но мб я ошибаюсь?
Для чистоты экспериментов лучше использовать свои сервера, а не паблик-сервисы. Тот же пингдомтулс может по разному ходить при каждом запросе (через разные прокси). Какой есть веб-софт для этого (аля пингдомтулс) тут я не подскажу - не интересовался.
Речь о том, что их нужно объединять в один файл. Меньшее кол-во запросов отдельных файлов - выигрыш в скорости получения страницы.---------- Добавлено 08.11.2013 в 21:21 ----------
В принципе Nadejda уже все пояснил(а?), я только добавлю. "Получение блока" - это не получение его содержимого (не всегда точнее). Это получения кода от <table> до </table>. Только когда получен блок - тогда начинается получение его содержимого.
Обрати внимание:
Т.е. чем больше и глубже вложенность блочных элементов - тем дольше ЮА будет получать и отрисовывать части страниц.
+100500 :)
Я тоже когда-то думал что пром.уа долго не продержится, однако реальность совсем другая. Много, даже очень много продавцов там торгуют (имеют свои ИМ) и очень не все хотят переходить на свой ИМ, даже несмотря на то, что его создание станет дешевле, чем годовая оплата сервиса. (причины разные, но я просто констатирую факты)
Я даже знаю случаи возврата на промуа. Банально продаж оттуда больше, чем со своего. А причина не столько в том, что свой сайт неюзабельный, а скорее в том, что реальных покупателей в сервисе на несколько порядков больше. Хотя мб это зависит от товаров - тут я не анализировал.
Да, промуа - это лишь один из китов. В рунете есть ещё как минимум с десяток кашалотиков. :)
И тебе дам медаль :)
Бери друпал и ковыряй потихонечку.
От расположения в коде. Но там есть важный нюанс: не все браузеры отправят запрос пока не получат блок полностью. Типа защита от разваливания страницы. (как яркий пример: с таблицами не всё гладко\просто. Было во всяком случае. Как сейчас ЮА парсят tr\td - я давненько не интересовался, но думаю ничего кардинально не изменилось)
Вот старой опере (и опере-мини тоже вроде бы) как раз на это было плевать, за счёт чего она и славилась быстротой получения контента (один из факторов её скорости): правильная отрисовка и выравнивание страницы происходила уже по мере получения остального.
