Ускоряем загрузку мобильной версии сайта - Часть 2 ⋆ Блог Digital агенції UAMASTER

Во второй части статьи продолжаем делиться советами, как ускорить загрузку мобильной версии сайта.

Оптимизация иконок, спрайт изображений

После оптимизации основных изображений остаются мелкие картинки, иконки, которые часто находятся в подвале сайта.

Все эти картинки загружаются как отдельные маленькие графические файлы. В случае с мобильными устройствами, это не очень хорошо, потому что гораздо проще загрузить один файл того же размера, чем 5-ть разных файлов.

Это позволяет сэкономить на запросах, что в свою очередь влияет на время загрузки. Для внедрения правок, необходимо обратиться к Gruntfile.js в котором будет использоваться задача под названием sprite:{}

module.exports = function(grunt){ grunt.initConfig({ compass: { //Запускаем задачу по сборке стилей dev: { options: { outputStyle:'compressed', sassDir: 'sass', cssDir: 'css', // watch : true, watch : false, } }, },

sprite:{ //Генерируем атлас спрайтов и отдельную таблицу стилей для него all: { src: 'img/sprites/raw/*.png', //указываем источник, где брать картинки dest: 'img/sprites/spritesheet.png', //куда эти картинки "слить", в какой файл destCss: 'css/sprite.css' //куда разместить каскадную таблицу стиля, с помощью которой мы потом }, //этот спрайт сможем использовать&t;/> }, });

grunt.loadNpmTasks('grunt-contrib-compass'); grunt.loadNpmTasks('grunt-spritesmith'); };

В результате получаем следующую картину. Вместо загрузки мелких изображений, подгрузился один файл spritesheet.png, содержащий в себе все картинки, которые в этот спрайт сливались.

Просто использовать такой файл проблематично, поэтому нужно использовать CSS, который управляет этим файлом.

Как можно видеть, для каждого файла:

создается стилевой класс .icon-имя-файла
используем спрайт как background-image:
ставим нужную позицию, зная размер изображения background-position:
указывая высоту и ширину. width: height:

В результате, в html-файле получаем следующее:

Вместо изображений, указываем тег <i></i> и class="" и уже CSS берет на себя управление размером: подставление правильного участка спрайта и т.д.

В результате таких правок, удастся сэкономить несколько http-запросов с мобильного устройства.

DNS prefetch

DNS perfetch – это способ ускорить веб-страницы путем предварительного разрешения DNS.

Читайте також: Google переносить інструмент SafeSearch в Search Console

Использование rel=dns-prefetch предполагает, что браузер должен разрешить DNS определенного домена до того, как он будет явно вызван.

Проще говоря, вы сообщаете браузеру, по каким адресам могут находиться ресурсы вашей страницы (картинки, видео, скрипты), что бы он мог разрезолвить имена сразу.

Что бы каким-то образом DNS-запросы не тормозили процесс загрузки в самый нужный момент, мы говорим браузеру, чтобы он заранее обратился к DNS-серверу и зарезервировал доменные имена в IP-адреса.

Достигается это все очень простым способом.

В коде страницы в разделе <head> укажите:<link rel='dns-prefetch' href='//name-donmen.com'>

Браузер преобразует имя домена в IP адрес в фоне. Это означает, что браузер уже «знает», куда ему нужно пойти, чтобы достать ресурс, пока до него дойдет парсер.

Оптимизация слайдера

Следующее улучшение – убираем из загрузки на мобильных устройствах огромный слайдер, который должен быть виден только на десктопной версии.

Если посмотреть на исходный код страницы, то видно, что загрузка слайдера все же происходит.

Визуально на экране его нет, но в коде он есть. Отображение его выключено в CSS, и делает его невидимым. Если принудительно включить отображение слайдера, то картина будет следующая:

При загрузке страницы с мобильного в html-коде подгружается часть кода, которая отвечает за загрузку слайдера.

При убирании слайдера, возникает несколько вопросов:

Как обеспечить обнаружение мобильного устройства на сервере?
Как это все правильно убрать?

Реализация будет следующая: в файле index.php необходимо:

добавить в корень сайта файл вызова класса Mobile Detect (mobile_detect.php*) для определения типа запроса

*это стандартная библиотека, которая позволяет на сервере сказать: «запрос пришел с десктопного устройства или с мобильного»

<?php
require_once 'mobile_detect.php';
$detect = new Mobile_Detect;
?>

использовать условные операторы php

<?php if (!$detect->isMobile()): ?> //если это не мобайл, то
<link rel="stylesheet" type="text/css" href="css/owl.css"> //мы подключаем CSS для слайдера (слайдер
<?php endif; ?> // организуется библиотекой owl.css)
/*
*
**/
<?php if (!$detect->isMobile()): ?> //если это не мобайл, то в этом случае добавляем
<script type="text/javascript" src="js/libs/owl.js"></script> // библиотеку для слайдера owl.js
<?php endif; ?>

Дальше в самом html-коде:

Читайте також: Google Chrome показує більш актуальні рекомендації пошуку

<?php if (!$detect->isMobile()): ?> //если это не мобайл, html-код слайдера показываем

<?php endif; ?> //если мобайл, то не показываем

В результате, мы на уровне сервера определим тип запроса, и исходя из результата, подгружаем часть html-кода или не подгружаем.

Оптимизация подгрузки видео на страниц

Очень часто на страницах можно увидеть вставленное видео с YouTube. Данное добавление влияет на скорость загрузки страницы. Если посмотреть на html-код десктопной версии страницы, то увидим, что это видео загружается как iFreme. Это самый простой способ вставки видео с YouTube. Напомним, что iFreme это, по сути, отдельное окно браузера, в который загружается отдельный документ.

Для того чтобы оптимизировать загрузку видео на странице, необходимо:

применить js;
применить bgset.min.js (библиотека для подстановки background of, под те места, куда будут лениво загружены изображения).

В самом html-коде, вставка выглядит следующим образом:

Здесь используем стилевой класс lazyload, указываем в атрибуте date-bgset="" где брать background в зависимости от размеров экрана, пока видео грузится. В результате, когда пользователь добирается до места расположения видео на экране, подгружается background картинка, а сам клип возникает только после того когда нажимаем на кнопку проигрывания.

Минификация html-кода

Улучшение не является таким уж важным, и не дает существенного прироста в скорости. Но если можно хоть немного ускорить загрузку, то почему бы и не воспользоваться.

Суть метода – добавление функции function sanitize_output по очищению html-кода и использование php-ный out of buffer. То есть все, что будет сгенерировано, сначала попадет в out of buffer и будет обработано функцией sanitize_output которая уберет все лишнее. А в самом конце, то, что получилось после очистки, отдаем пользователю. В самом начале index.php включаем буферизацию потока вывода с фильтрацией через функцию sanitize_output, которая удаляет лишние пробельные символы из HTML-кода:

<?php
function sanitize_output($buffer) {
$search = array(
'/\>[^\S ]+/s', // strip whitespaces after tags, except space
'/[^\S ]+\</s', // strip whitespaces before tags, except space
'/(\s)+/s' // shorten multiple whitespace sequences
);
$replace = array(
'>',
'<',
'\\1'
);
$buffer = preg_replace($search, $replace, $buffer);
return $buffer;
}
ob_start("sanitize_output");
?><!DOCTYPE html>

В самом конце index.php выводим содержимое отфильтрованного буфера:

Читайте також: Google припиняє експеримент «Notes on Search»

</html>
<?php ob_end_flush(); ?>

В заключение

Для оптимизации страницы, в которую входят все выше перечисленные решения необходимо собрать в едино файл Gruntfile.js

В файле соберутся все задачи, которые мы использовали для наших небольших оптимизаций:

compass: для сборки CSS
sprite: для сборки маленьких картинок в один большой спрайт
responsive_images: изменяет размеры изображений и готовит их для экранов разных размеров
concat: не содержит библиотеки owl.js из-за оптимизации слайдера
uglify: помогает объединить js в один файл и минифицировать его. Содержит owl.js
critical:
replace: помогают выявить критический CSS

Если удастся внедрить все выше перечисленные решения, вы увидите значительное увеличение в скорости появления первого экрана на мобильном устройстве, а также существенно увеличите скорость полной загрузки страницы.

Следует помнить, что если какое-то из перечисленных решений будет существенно влиять на работоспособность сайта или будет ухудшать RAIL Performance Model производительности сайта, то такое решение лучше не применять.

Все детали по коду можно посмотреть на https://github.com/Slony/speed-lab

Статья подготовлена на основе видеодоклада сотрудников Google Ивана Бригида и Александра Приходько