не отправляйте устаревший код javascript в современные браузеры

Кроссбраузерная совместимость: адаптивный веб-дизайн для старых браузеров

Кроссбраузерность — это способность сайта корректно отображаться в различных браузерах. Ресурс должен работать одинаково во всех версиях обозревателей.

Особенно это важно в эпоху адаптивного веб-дизайна, когда на первый план выходит способность front-end адаптироваться к широкому диапазону различных устройств и при этом обеспечивать оптимальное качество просмотра.

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

Текущая ситуация

Общемировая статистика за 2015 год показывает, что топ-14 используемых разрешений экрана находятся в диапазоне от 1920 на 1080 до 320 на 480 пикселей.

Хотя Windows 7 ( 31,20% ) до сих пор удерживает большую долю рынка, мобильные платформы начинают заменять традиционные, стационарные.

Взглянув на статистику за 2015 год по используемым браузерам, мы видим, что первое место принадлежит Chrome ( все версии — 44,87% ), второе место — Firefox ( все версии — 10,37% ), третье Internet Explorer 11 ( 6,84% ).

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

Проанализируйте свою аудиторию

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

Проблемы в устаревших браузерах и различные подходы к разработке

Источник

Вывод уведомления об устаревшем браузере с помощью jReject

Многие веб-сайты выводят предупреждения об устаревших браузерах или и вовсе отправляют пользователя устанавливать новый браузер или Google Chrome Frame.
jReject — специальный плагин для jQuery, позволяющий отображать подобные уведомления с помощью нескольких строчек кода.

Настройка блокируемых браузеров

Плагин позволяет гибко настроить список браузеров, пользователи которых увидят уведомление.
Например, чтобы выдавать сообщение пользователям неизвестных браузеров, а также Firefox 2 и Internet Explorer 5, достаточно сконфигурировать плагин следующим образом:

Internet Explorer пятой и шестой версий блокируются плагином автоматически, поэтому если вы почему-то хотите беспрепятственно пускать на сайт пользователей IE6 необходимо указать это отдельно (msie6: false ).

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

Предлагаемые браузеры

Полезные опции

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

Особенности

Прямо в самом плагине «вшит» стандартный набор предлагаемых браузеров вместе с их версиями, которые давно уже устарели. Несмотря на то, что плагин был обновлён менее месяца назад, он всё ещё предлагает по умолчанию установить Chrome 18 или Opera 11. Для того, чтобы исправить это недоразумение достаточно либо указать актуальные версии в самом коде плагина, либо вообще убрать оттуда версии, оставив лишь названия браузеров. Второй вариант, разумеется, будет намного корректнее — едва ли кто-то станет постоянно обновлять данные вместе с выходом новых версий браузеров. Можно также вручную указывать список браузеров с их актуальными версиями при вызове плагина.

Ещё один немаловажный момент: для того, чтобы корректно отображались логотипы браузеров, необходимо указать в параметре imagePath адрес каталога, где они размещены. По умолчанию используется путь ./images/.

Источник

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

Передать нужный код для каждого браузера – непростая задача.

В этой статье рассмотрим несколько вариантов, как эту задачу можно решить.

Передача современного кода современным браузером может очень сильно повысить производительность. Ваши JavaScript-пакеты смогут содержать более компактный или оптимизированный современный синтаксис и поддерживать старые браузеры.

Среди инструментов для разработчиков доминирует паттерн module/nomodule декларативной загрузки современного или legacy-кода, который предоставляет браузерам источники и позволяет решать, какие из них использовать:

К сожалению, не всё так просто. Показанный выше подход на основе HTML инициирует перезагрузку скриптов в Edge и Safari.

Что можно сделать?

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

Способ первый: динамическая загрузка

Но при таком подходе необходимо дождаться выполнения «лакмусового» модульного скрипта, прежде чем внедрять правильный скрипт. Это происходит, потому что всегда работает асинхронно. Но есть способ получше!

Можно реализовать независимый вариант, проверяя, поддерживается ли nomodule в браузере. Это означает, что мы будем рассматривать браузеры вроде Safari 10.1 как устаревшие, даже если они поддерживают модули. Но это может быть к лучшему. Вот соответствующий код:

Это можно быстро превратить в функцию, которая загружает современный или legacy-код, а также обеспечивает асинхронность их загрузки:

Какой же здесь компромисс?

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

Вот как это решение может выглядеть в эксплуатации:

Способ второй: отслеживание User Agent

У меня нет подходящего примера кода, поскольку отслеживание User Agent — задача нетривиальная. Но зато вы можете почитать прекрасную статью в Smashing Magazine.

По сути всё начинается с того же в HTML для всех браузеров. Когда запрашивается bundle.js, сервер парсит строку User Agent запрашивающего браузера и выбирает, какой JavaScript возвращать — современный или legacy, в зависимости от того, как был распознан браузер.

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

Способ третий: штрафуем старые браузеры

Негативный эффект паттерна module/nomodule виден в старых версиях Chrome, Firefox и Safari — их количество очень невелико, поскольку браузеры обновляются автоматически. С Edge 16-18 ситуация иная, но есть надежда: новые версии Edge будут использовать движок отрисовки на основе Chromium, который не имеет таких проблем.

Для некоторых приложений это было бы идеальным компромиссом: загружать современную версию кода в 90 % браузеров, а в старые — отдавать legacy-код. Нагрузка в старых браузерах повысится.

К слову, ни один из User Agent’ов, для которых такая перезагрузка является проблемой, не занимают значимую долю мобильного рынка. Так что источником всех этих лишних байтов вряд ли будут мобильные устройства или устройства со слабым процессором.

Если вы создаёте сайт, к которому обращаются в основном мобильные или свежие браузеры, то для большинства этих пользователей подойдёт простейший вид паттерна module/nomodule. Только удостоверьтесь, что вы добавили фикс Safari 10.1, если к вам заходят более старые iOS-устройства.

Способ четвёртый: применяйте условия использования пакетов

Хорошим решением будет использовать nomodule для условной загрузки пакетов с кодом, который не нужен в современных браузерах, например, с полифиллами. При таком подходе в худшем случае полифиллы будут загружены или даже выполнены (в Safari 10.1), но эффект от этого будет ограничен «переполифиллингом». Учитывая, что сегодня преобладает подход с загрузкой и выполнением полифиллов во всех браузерах, это может быть достойным улучшением.

Можно сконфигурировать Angular CLI для использования этого подхода с полифиллами, как продемонстрировал Минко Гечев. Узнав об этом подходе, я понял, что можно включить автоматическую инъекцию полифиллов в preact-cli — этот PR демонстрирует, насколько легко можно внедрить эту методику.

Так что же выбрать?

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

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

Лично я выбираю, ориентируясь на длительность парсинга на мобильных устройствах, а не на стоимость загрузки в десктопных версиях. Мобильные пользователи воспринимают парсинг и расходы на передачу данных как фактические расходы (расход заряда батареи и плату за передачу данных), тогда как пользователи десктопа не имеют таких ограничений. Также я исхожу из оптимизации под 90% пользователей — основная аудитория моих проектов пользуется современными и/или мобильными браузерами.

Что почитать

Хотите изучить эту тему подробнее? Можете начать отсюда:

Источник

Как стать свободным от «цепей» старых браузеров

Люди не готовы отказываться от старых друзей, старых традиций и старых-добрых предпочтений. А еще некоторые из них привыкли к устаревшим версиям браузеров, а современное ПО устанавливать отказываются. О том, что делать, если вы стали заложником старых браузеров, рассказал в своем докладе на конференции «Frontend Conf» руководитель направления разработки ДомКлик Денис Красновский.

Знакомьтесь: это Slowking, Slowpoke, Slowbro и Slow web.

Именно так выглядит ваше приложение, пока пользователь пытается его загрузить. То, как долго он будет смотреть на эту белую простыню, зависит трех вещей:

Хочу условиться о том, что под приложением в этой статье всегда имеется в виду Web, то есть неважно – это просто лэндинг или Rich JavaScript Application.

Представим банальную ситуацию: у нас гипотетический онлайн-кинотеатр, и есть конкуренты, опять же гипотетические. Важно, чтобы решив посмотреть «Игру престолов», потенциальные зрители в поиске нашли первым именно наш кинотеатр, и кликнули на него. Но и это только половина победы.

Проблема SEO заключается в том, что если вас нет на первой странице выдачи, скорее всего, в интернете вас не существует вовсе. Потому что пользователи не ходят дальше первой страницы. Более того, первые три варианта обычно закрывают все потребности. К тем приложениям, которые находятся в первых рядах первой страницы, люди подсознательно проявляют доверие, ведь «Google фигни не посоветует».

SEO – это первый шаг, второй – впечатления пользователей.

User experience

Даже если вы находитесь на хорошем месте в выдаче поисковика — это еще не все. Нужно поработать над user experience. Именно в этот момент белый экран, особенно если он грузится довольно долго, начинает напрягать. Долгая загрузка связана, скорее всего, с большим количеством статики. Под статикой подразумеваются js, css, svg, png — в общем, все, что мы собираем для нашего приложения.

Помимо того, что мы заставляем пользователя выкачивать очень большой объем данных, мы перегреваем телефоны и разряжаем их батареи. Может быть, во время серфинга по сети на своем мобильном, вы замечали, что он очень сильно разогревается, руки потеют, а экран весь заляпывается. Если дошло до этого, приложением пользоваться уже не хочется.

Существует метрика Retention, в которой можно увидеть количество пользователей, которое вы смогли удержать после того, как они воспользовались вашим приложением. Например, я посмотрел первую серию «Игры престолов», и у меня негативный опыт: все грузится слишком долго, постоянно появляются какие-то проблемы. Скорее всего, я уйду к конкурентам. Возможно, именно они предоставят мне то, что я не получил с первым результатом в выдаче.

Третий шаг для нас, как для инженеров, тоже очень важный: речь идет о качестве продукта.

Все мы привыкли пользоваться stylelint, ESLint, которые проверяют наши js и css. Но почему бы нам не взять за основу Lighthouse?

Sonar, ESLint, Stylelint проверяют наш код на наличие ошибок, а мы смотрим, что получится в итоге, с точки зрения конечного пользователя. Lighthouse расскажет, где мы ошиблись и предложит варианты для оптимизации, чтобы улучшить наши показатели среди всех других приложений и сайтов.

Я хочу рассказать о том, как стать свободным от «цепей» старых браузеров. Давайте рассмотрим историю о взлетах и падениях. Все персонажи вымышлены, все совпадения — случайны.

This is how we do

Как-то раз ко мне обратились с предложением: «Давайте вы сделаете офигенное приложение: быстро, качественно, а еще у него должен быть хороший перфоманс». Нужно было делать Single Page Application, что подразумевало борьбу за прорисовку.

Для себя мы определили паттерны, по которым работать:

Вес css + js, без gzip

Используя вышеописанные паттерны, мы сделали приложение, богатое на функциональность и js.
Вот те зависимости, с которыми мы решились работать:

Этот момент показателен. Если мы заходим на страницу с 8 КБ, зачем тащить туда все остальное? Дайте эти 8 КБ пользователю, и пусть у него все рисуется.

Диагностика

Мы сделали приложение, оно работает. Как проверить перфоманс?

Браузеры кричат, как в фильме: «Somebody, please, get this browser a polyfill!».

Нас просили поддержать не только IE, но и Chrome v35 и Safari v10. Казалось бы, в чем проблема? Поддержали, добавили пару строчек кода — и все хорошо! Но дело в том, что мы уже дали пользователю почувствовать, что приложение летает. Это как будто вы посадили в ресторане клиента за столик у окошка на 86 этаже, и у него дух захватило от открывшегося перед ним вида. А через пять минут подошли к нему и предложили пересесть к туалету. Мы не хотели допустить такого эффекта, поэтому начали искать варианты работы со старыми браузерами.

Варианты работы со старыми браузерами

Рецепт

package.json

Во всем package.json нас сейчас интересуют три строчки:

Первые две строки — инструкция к сборке. Ключевой особенностью является указатель переменной окружения TARGET=old и TARGET=modern. Эту переменную мы будем использовать далее.

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

Еще один важный нюанс, о котором иногда забывают: && — это последовательное выполнение, а & — параллельное выполнение. Нам не нужно ждать, пока у нас билдится modern билд, мы запускаем их параллельно.

target.js

Нам нужно написать совсем немного скриптов.

Что здесь происходит? Мы преследуем единственную цель: собрать статику с хорошими браузерами в отдельную папку, а все остальные, кроме «мертвых» (больше 1%) — в другую папку. Это своего рода сервис. Мы объявляем полифилы, которые нам понадобятся. Переменную окружения используем для того, чтобы вернуть отсюда именно тот конфиг, который нужен Webpack и Babel.

webpack.prod.js

Все, что нам нужно сделать в Webpack, это прокинуть полифилы:

Потом перейдем в Babel.config.js:

Babel преобразует наш офигенный код в более старый, который не нравится нам, но нравится браузерам. При работе с Babel и при поддержке старых браузеров, нам необходим babel-polyfill.

Это мощная машина, которая много весит. В этот момент мы тоже указываем таргеты.

Babel-polyfill используется с параметром useBuiltIns с флагами:

Итого, из исходных 294 КБ они превращаются в 384 КБ кода.

Я выбираю другой вариант.

Путем нехитрых манипуляций мы получили две сборки:

Я упоминаю Internet Explorer, поскольку для меня он является олицетворением старых браузеров.
Это разница:

69 KB – годная тема.

Во фронтенде — по крайней мере у нас — принято биться за каждый килобайт.

Поэтому разница, которую мы получили между двумя версиями, важна. Но эти цифры – процент от наших частных вычислений. Если ваш проект намного больше, у него больше зависимостей, естественно, у вас и div будет больше.

У меня лапки

Иногда в браузере можно увидеть ‘last 2 versions’. Это означает, что вы решили поддерживать две версии всех браузеров, даже мертвых.

Добавьте useBuiltIns: ‘entry’, и разница между хорошим билдом и том, о котором мы сейчас говорим, будет составлять:

117 KB.

И не нужно забывать о том, что эти цифры для разных случаев будут разными.

nginx split

Вишенка на торте хайпа, о которой я говорил.

Мы находимся в nginx и будем использовать директиву map, локальную переменную http_user_agent. Кроме того, объявили переменную template. В нее запишем название индексового файла, который будем отдавать пользователю.

Важный момент: мы получаем user_agent на regex. И если user_agent с версией Chrome от 0 до 74, то мы отдаем old индекс. Для всех остальных современных браузеров отдаем modern-индекс.
listen 5050 означает то, что при запуске nginx, вы зайдете на local host 5050, и он начнет следовать инструкциям, которые вы написали, и раздавать то, что вы хотите. В данном случае (строчка root) мы говорим, что по такому-то пути на компьютере рнаходится папка dist (это папка в проекте), и туда нужно отдатьпеременную template. Это либо old индекс, либо modern индекс.

Теперь смотрим, что произошло:

Chrome v74

Про v74 мы условно сказали, что это старый Chrome. Здесь есть строчка, которая заматчилась — значит, все работает.

Chrome Canary v76

Работает надежно, как швейцарские часы. Но фронтенд в целом надежен как швейцарские часы (в отличие от бэкенда).

Как выглядит реальный файл?

Real world nginx map

Он выглядит следующим образом:

В данном случае мы уже объявили переменную. Для чего мы это сделали и почему не объявили ее выше, что казалось бы логичным ходом? В nginx нельзя объявить переменную выше, чем скоуп сервер. Интересно, что нельзя сделать директиву map на скоуп сервер. Поэтому код выглядит немного странновато, но он работает.

Для чего мы написали здесь столько переменных? Если вы какой-то причине решите переименовать файлик и допустите ошибку, nginx не будет на это ругаться. Однако если здесь будет не переменная, пользователям в разбросе Chrome 0-9 будет отдаваться не то, что они хотят. И вы, как человек, у которого есть самая последняя топовая машина и самый последний топовый браузер, никогда об этом не узнаете. Насколько быстро всплывет эта ошибка, неизвестно. Почему это происходит большинство разработчиков так и не поймут. Поэтому в данном случае лучше делать все через переменные.

Наверное, вы знаете, что есть сервисы Polyfill.io, и существует вариант проверять на клиенте, работает ли тот или иной метод, и, в зависимости от полученных данных, собирать статику. Скажу сразу: этот вариант рассматривать не стоит. Почему?

Вы объявляете Polyfill.io render-blocking скриптом, потому что не можете загружать свои скрипты дальше, ведь иначе JavaScript не станет работать. Поэтому мы сначала скачиваем html, видим Polyfill.io, идем в него, и он уже решает, что нам нужно. При таком подходе о перформансе можно забыть.

По той же причине не работает проверка, есть ли метод. Вы просто создаете дополнительные round-trip’ы, которые замедляют прорисовку.

Лучше всего пойти легким путем, о котором я рассказал. У человека, который знает Webpack и Babel, создать сплит между старым и новым браузером получится за два-три часа. А если он с ними не знаком и времени потребуется больше, это все равно стоит того.

Как говорил Альтрон:

«Я покажу вам нечто прекрасное ( у нас это web, тонущий в мегабайтах JavaScript).
Вы хотите перформанс, но не готовы к эволюции, а я свободен ото всех цепей».

Источник

Скорость загрузки сайта: как проверить и улучшить

Как работает сайт

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

За работоспособность и скорость сайта отвечает сервер, то есть удаленный компьютер, который работает 24/7. Производительность сервера зависит от мощности «железа» и его настроек.

Смотрите ролик от нашего SEO-эксперта, чтобы было легче влиться в тему!

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

Казалось бы, все достаточно просто: домен-сервер-браузер…

Но просто это выглядит только внешне. Когда мы переходим по ссылке, сначала происходит запрос к системе информации о доменах (DNS). DNS отдает IP-адрес сервера, на котором находится сайт. Затем по IP-адресу осуществляется запрос на порт сервера. После соединения с портом происходит обмен пакетами по проверке сертификата SSL (согласовывается шифрование данных). Далее происходит запрос на сервер и формирование html-страницы.

Чтобы пользователь увидел страницу, с сервера скачиваются все ее элементы. Затем полученные файлы обрабатываются браузером, и отрисовывается страница.

На скорость сайта оказывает влияние:

Чтобы оценить скорость загрузки сайта, его первого экрана и работы скриптов, мы используем аудит Pagespeed Insight.

Основные показатели в скорости загрузки, на которые обращаем внимание, – это FCP (время до первого появления контента), LCP (отрисовка самого крупного контента − до 2,5 сек) и FID (время между первым взаимодействием пользователя со страницей и ответом браузера – 100 мс).

Аудит PageSpeed выполняет проверку по 34 пунктам, из которых 2 − по бэкенду, а остальные − по фронтенду.

Бэкенд

Эффективность работы сервера характеризуется скоростью и форматом его ответа.

Скорость ответа сервера

После запроса от браузера сервер его обрабатывает и отправляет ответ с запрашиваемой страницей. Этот промежуток и называется «Время ответа сервера».

Проверить время ответа можно с помощью Яндекс.Вебмастер. https://webmaster.yandex.ru/tools/server-response/

Еще один показатель работоспособности сервера – TTFB (время получения первого байта информации). Это промежуток времени от запроса страницы до ее формирования и передачи клиенту.

Увидеть TTFB можно в отчете PageSpeed или в самом браузере, нажав F12 – Network – All и выбрав HTML-страницу. В боковом окне смотрим вкладку Timing.

От чего зависит скорость ответа сервера?

1. Тип хостинга и его производительность.

Хостинг — это предоставление места на сервере.

Есть 3 вида хостинга:

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

2.Настройки сервера.

2.1. Версия PHP.

Чем выше версия PHP, тем быстрее страница формируется на сервере.

Как проверить версию PHP?

Проверить ее можно посредством инструмента Яндекс.Вебмастер.

Как поменять?

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

2.2. Наличие серверного кэширования.

Кэширование означает сохранение копий страниц на сервере для улучшения скорости загрузки сайта.

Как настроить?

Существуют плагины для настройки кэширования. Для разных типов серверов есть отдельные модули.

2.3. Нагрузка на сервер.

Чем выше популярность сайта – тем больше запросов поступает к серверу. Нагрузка возрастает, и скорость загрузки страниц падает. Дополнительную нагрузку дают парсеры и боты.

Чем больше сайтов на сервере, тем медленнее он работает.

Как проверить?

Выявить излишнюю нагрузку можно по наличию ошибок на сервере.

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

Что делать?

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

2.4. Эффективность генерации страниц сайта.

Сложность формирования страниц (обилие скриптов, запросов к таблицам) повышает нагрузку на сервере и снижает скорость загрузки.

Как проверить?

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

2.5. GZIP-сжатие.

GZIP-сжатие позволяет уменьшать объем передаваемых данных (до 90 %) и ускорить загрузку страницы. Браузер получает трафик в сжатом виде, а потом распаковывает его.

Как проверить?

Понять, включено ли сжатие, можно по уведомлению в отчете PageSpeed.

Проверяем при помощи того же DEV Tools Google Chrome. Для этого жмем F12 – Network – All – HTML-страницу. В боковом окне выбираем вкладку Headers. В списке заголовков ищем accept-encoding: gzip, deflate, br.

В сервисе вставляем адрес страницы и жмем Test.

Что делать?

Если сжатие на сервере не используется, его следует настроить, т. к. оно существенно влияет на скорость загрузки сайта. Для этого лучше привлечь опытного разработчика. Для CMS WP (приложение по созданию сайтов WordPress) можно использовать плагин https://ru.wordpress.org/plugins/hyper-cache/.

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript

Если ваш сайт находится на сервере Nginx, нужно вписать в файл конфигурации /etc/nginx/nginx.conf такой фрагмент:

Фронтенд

Большинство CMS по умолчанию генерирует страницы с неэффективной структурой HTML-кода, когда все внешние CSS- и JS-файлы подключаются в блоке head. В этом случае браузер снижает скорость загрузки страницы.

Сервис PageSpeed для страниц с подключенными в head внешними JS- и CSS-файлами рекомендует их удалить. Также он рекомендует оптимизировать загрузку сайта, если объем HTML-кода в блоке head слишком велик.

Количество файлов, которые загружаются в браузер

Чем больше ресурсов у веб-страницы (файлов, необходимых для ее генерации), тем ниже скорость загрузки.

К ресурсам относятся:

По каждому сайту производится запрос на сервер, и это снижает скорость загрузки сайта.

Как узнать сколько запросов делает браузер?

Список и количество ресурсов покажет PageSpeed. Также можно использовать сервис https://tools.pingdom.com/: вставляем URL страницы и жмем START TEST. Поле Requests показывает, сколько запросов делает браузер.

Как улучшить?

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

Сокращение числа файлов уменьшит и вес страницы. Целесообразно не отказываться от всех картинок и шрифтов, а использовать разумный минимализм.

Это сократит количество запросов и ускорит загрузку сайта.

Оптимизация JS-файла

Скрипты могут сильно снижать скорость загрузки. Они используют процессор устройства, на котором просматривается страница. Скрипты могут мешать или блокировать работу друг друга.

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

Как определить?

Ошибки с JS отображаются в аудите PageSpeed:

Для оптимизации скорости сайта JS-файлы должны подключаться в разделе footer, а не в head.

Проанализировать скрипты можно при помощи DEV Tools Google Chrome. Например, какой процент из загружаемых JS используется в рамках данной страницы: F12 – Network – Меню в правом верхнем углу – More Tools – Coverage.

Что делать?

Тут не обойтись без помощи разработчика.

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

Оптимизация CSS

Для отображения контента браузер запрашивает внешние файлы CSS. Большое их количество и вес замедляют загрузку сайта.

Как определить?

Первый способ увидеть ошибки − PageSpeed:

Работу скриптов можно проанализировать с помощью DEV Tools Google Chrome. Процент файлов CSS, участвующих в загрузке сайта, доступен с помощью меню: F12 – Network – Меню в правом верхнем углу – More Tools – Coverage.

Что делать?

Настраивать оптимизацию стилей лучше с помощью специалиста. Работа трудозатратная, но способна существенно нарастить скорость загрузки.

Оптимизация HTML

Объем HTML кода раздувают сложная структура, неиспользуемые блоки, пустые строки и комментарии. Объем прямо пропорционален и скорости загрузки сайта.

Как увидеть?

На признаки неоптимального кода укажут ошибки в аудите PageSpeed:

Для определения процента кода, который не используется, можно использовать DEV Toots: F12 – Network – Меню в правом верхнем углу – More Tools – Coverage.

Что делать?

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

Оптимизация шрифтов

Для отрисовки контента понадобятся шрифты. Хорошее решение − использовать системные шрифты, которые наверняка есть на компьютере пользователя, что не потребует их скачивания. Это повысит скорость загрузки страницы. https://msiter.ru/articles/css-priemy-stek-sistemnyh-shriftov

Вариант похуже – использование внешних шрифтов Google Fonts из-за необходимости их скачивания с внешнего сервера. Здесь скорость загрузки сайта вырастает.

Наилучшее решение − это использование шрифтов, размещенных на локальном сервере, и подключение inline (не через внешний css, а непосредственно в коде страницы в разделе head).

Как определить?

Открываем код страницы Ctrl+U. Если в разделе head кода страницы присутствует тег link https://fonts.googleapis.com/css, значит, есть возможность ускорить загрузку страниц.

Что делать?

Для переработки шрифтов понадобится помощь специалиста.

Оптимизация шрифтов и перенос их на локальный сервер может значительно ускорить отрисовку первого контента и повысить скорость сайта в целом.

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

Скорость загрузки сильно зависит от веса (объема) загружаемых файлов. Значительная часть общего веса приходится на картинки.

Факторы, влияющие на вес изображения:

Как проверить?

Проблемы с изображениями покажет аудит PageSpeed. Решаются вопросы с помощью:

Что делать?

Сжать изображение можно при помощи онлайн-сервисов.

Уменьшить расширение изображения можно при помощи любого графического редактора.

Изменить глубину цвета поможет «Фотошоп».

Ленивая загрузка изображений и медиафайлов

Изображения и медиафайлы (видео, карты и т. д.) можно подгружать по мере прокрутки страницы пользователем. Соответственно, браузер скачивает файлы частями.

Как проверить?

Понять, как грузятся изображения, можно в Google Chrome: F12 – Network – Img – CTRL+F5.

Как настроить?

Можно использовать атрибут lazy=»load» (в последней версии WP уже есть в стоке) для изображений либо настроить с помощью скриптов для любых медиафайлов.

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

Кэш браузера

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

Как проверить?

Увидеть, настроено ли кэширование, можно в данных PageSpeed.

Рекомендуется задавать правила эффективного использования кэша для статических объектов.

Можно проверить в браузере Chrome DEV Tools.

Если файл кэшируется, в столбце Size вместо размера указывается memory cache или disk cache.

Как настроить?

Для популярных CMS существуют плагины, которые помогут настроить кэширование файлов, например, WP-Optimize и WP Fastest Cache.

Подводя итог, отметим, что на скорость загрузки сайта влияет:

Мы показали, как определить те или иные проблемы, отображаемые в PageSpeed Insight.

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

Источник