Pull to refresh

Comments 17

Интересный подход, но что-то подсказывает, что на клиенте в итоге он приведет к замедлению загрузки и тормозам. На каком количестве одновременно установленных баннеров вам приходилось его тестировать?
4-5 рекламных блоков, визуально грузится быстрее.
можно на nnm-club.ru посмотреть, сорри если реклама
это не рекламные блоки у вас, а помои какието.
уж простите конечно, но лично для меня что это — что порнотизеры — одно и тоже…

в тоже время нормальную рекламу описанным выше образом какраз нельзя вставлять себе на сайт, причин две — либо дохнет таргетирование и контексная привязка, либо ( если реклама не на столько умна ) реферер.
Не возможность отследить рекламодателю откуда был переход и почему — оч хренова.
>В связи с последними инициативами гугла учитывать время загрузки страницы становится всё более актуально асинхронно подгружать части веб-страниц уже после загрузки основного минимума.

Другой топик:
>Ряд крупных компаний, среди которых Google, KDDI, Globe Telecom и пр. планируют в ближайшее время приступить к строительству международной кабельной системы под названием «Юго-восточный азиатско-японский кабель» (Southeast Asia Japan Cable, SJC).
>пропускная способность канала составит 17 Тбит/с; с возможностью увеличения до 23 Тбит/с.

фейспалм.жпг
Почему бы просто не всосать нужно содержимое через XHR и не добавить его через innerHTML?
если в уже готовый документ добавляется document.write — он заменит весь документ а не допишет в него, т.к. старый уже закрыт — он откроет новый для записи
Так он не выполнится при вставке через innerHTML.
Но я вообще не вижу смысла использовать document.write(). Или так принято вставлять рекламу?
Увы, многие баннерокрутилки работают именно так. Хотя иногда код удается переписать без document.write()
а почему не подменить document.write своим кодом, который не будет себя так вести?
Идея подгрузки вспомогательной информации после основного контента, достаточно старая. Кроме скорости есть еще соображения повышения доли уникального контента на странице.
Но как это будет оценивать Гугл не очень понятно. Он однозначно парсит динамический контент. По ссылке которую вы привели утверждается что он учитывает суммарное время подгрузки и HTML и JS. В этом случае непонятно за счет чего можно достигнуть сокращения суммарной скорости загрузки.
вот тут говорится что время загрузки считается до события DocumentComplete, т.е. если что-то подгружать в onLoad это уже на время, учитываемое гуглом, влиять не будет.

и для конечных пользователей, если рекламный блок висит вверху страницы с подгрузкой внешнего js, то пока он не загрузится — остальная страница видна не будет. при отложенной подгрузке содержимое страницы видно сразу.
Вы сослались на «последние инициативы гугла». Насколько я понял, там высказывается мнение, что будет учитываться все — и время подгрузки основного документа и время подгрузки JS.
интересное решение, но кажется довольно сложным, наверно будет куча подводных камней, да и что делать с Хромом и ИЕ, проще переопределить document.write, будет кроссбраузерно
а iframe-то зачем? Web Optimizer юзает перемещение блоков в конец в собственных div'ах. Уже полгода безотказно работает везде.

document.write переопределять — зло. Быстро ломает любую обратную совместимость с другими решениями.
А если потом переопределять его обратно?
можно, а смысл? если можно проще
Я помню решал таким образом отложенную вставку Яндекс.Директа — при падениях Яндекса, не загружались страницы с контекстом. Уже потом они сделали опцию, позволяющую вставлять код рекламы в указанный элемент.
Sign up to leave a comment.

Articles