Почему PageSpeed Insights считает что скрипты блокируют отображение?

[BETEPAH]

Здравствуйте!

Немного поломал себе голову уже с оптимизацией. Может кто-то знает из-за чего PageSpeed Insights может считать, что скрипты подключенные непосредственно перед </body> могут блокировать отображение содержимого?
В частности вот:
https://developers.google.com/speed/...&tab=deskt op
В перечне "Удалите код" значатся скрипты, которые расположены внизу страницы. Почему? И почему на титульной странице сайта, которая собирается из того же шаблона, этой проблемы нет?
https://developers.google.com/speed/...2F&tab=desktop

[BETEPAH]

Rise,
это их рекомендация https://developers.google.com/speed/...izeCSSDelivery
но вопрос не об этом

[alex.vv]

BETEPAH, подключаемые js/css файлы, которые идут до контента, считаются render-blocking JavaScript and CSS. Т.е. пока они не загрузятся, пользователь не увидит контент. Решения такие:
1.) Повесить подключение скриптов в onReady event, т.е. подключать скрипты только после полной загрузки страницы. Альтернативно, можно попробовать засунуть все js/css файлы непосредственно перед закрывающим тегом body.
2.) Запихнуть js/css в качестве содержимого тегов <script> и <style> (если кеширование не важно)
3.) Конкатенировать/минифицировать весь js в один файл (и тоже самое с css) и подключать его + повесить cache хедеры при отдаче файлов. Заказчику объяснить, что грузится все только в первый раз, а потом ложится в клиентский кеш и не влияет на скорость отображения контента. Правда, гуглинсайтовское предупреждение это не уберет.

(также, если память не изменяет, содержимое <style> и <script> тегов, расположенного в head, тоже будет render-blocking)

BETEPAH, а нормально что у тебя стиль подключен после </html>?

Ну и это, конечно, невалидно и надо поменять.

[BETEPAH]

Альтернативно, можно попробовать засунуть все js/css файлы непосредственно перед закрывающим тегом body.

Вы внимательно читали топик?

[Vlasenko Fedor]

Попробуй поигратся с defer/async и в конце концов, можно использовать автозагрузчик вынесенный в файл к примеру

var loader = (function (src, callback) {
    var doc = window.document, cache = {};
    return function (src, callback) {
        if (cache.hasOwnProperty(src)) {
            callback && (callback());
        } else {
            var el = doc.createElement('script'), loaded = 0;
            el.src = src, doc.body.appendChild(el), cache[src] = 1;
            if (callback) {
                el.onload = el.onreadystatechange = function () {
                    if ((el.readyState && el.readyState !== 'complete' && el.readyState !== 'loaded') || loaded)
                        return false;
                    el.onload = el.onreadystatechange = null, loaded = 1, callback();
                };
            }
        }
    };
}());
loader('test1.js', me);
function me() {
    alert('This callback Me');
}

или http://jsfiddle.net/vlasenkofedor/5pDXf/
Динамически вставленные скрипты загружаются асинхронно, при этом они будут кешироватся браузером

[BETEPAH]

Poznakomlus,
К сожалению, не все скрипты из используемых, можно загружать асинхронно. К примеру, api гугл-карт используется во множестве мест сайта и переписывать функционал под использование в callback займет много времени. Да и хотелось бы докопаться до истины.
Почему одинаковое подключение на двух показанных страницах, может по-разному восприниматься анализатором google?
Могут ли на это влиять абсолютно позиционированные элементы? Или код анализируется построчно, согласно расположению в html?

[alex.vv]

BETEPAH, предположу, что у вас на страничке http://traveltipz.ru/review есть jQuery onReady события ("$(function() {..."), (строчки 1950-2800) которые ждут, пока все вышеперечисленные js файлы (из pagespeed insights) загрузятся. Попробуйте переместить скрипты со строчек 1950-2800 в самый низ, перед закрывающим тегом body.

[BETEPAH]

alex.vv,
а вот это очень похоже. Спасибо!
Буду пробовать, хотя это и не легко будет, страница же собирается из модулей и скрипты, которые нужно вынести вниз принадлежат только этой странице, а не всему шаблону.