Открываешь сайт — и всё виснет. Знакомо?
Честно говоря, я уже давно перестал считать, сколько раз на старых или плохо оптимизированных проектах сталкивался с тормозами, когда сайт решает начать тормозить у самого первого прыжка. Вот вроде бы дизайн классный, идеи свежие — а вот с адаптивностью какая-то беда. И ты даже не всегда сразу понимаешь, что именно глючит: то ли картинка не подгрузилась, то ли скрипт просчитался в неправильный момент.
Тестирование адаптивности — вроде бы не такая уж загадка, если ты профессионал. Но на практике всё не так однозначно. Иногда проще всего сделать пару скриншотов на телефоне и подумать: «Ну, вроде всё ок». Но, представляешь, оказывается, что конкретно на iPhone X у кнопки скролл начинает глючить, а на планшете всё шустро, и ты только спустя пару часов понимаешь, что баг скрыт в неподдерживаемом браузере.
И да, сама идея тестировать на разных устройствах — это одно. А чтобы сделать это быстро и чисто, нужны правильные инструменты. Ну или, по крайней мере, какое-то понимание, как не тратить время зря, лазая по настройкам, подключая старенький андроид или держа в руках 4-5 устройств одновременно. Тут тут и начинается самое интересное.
Потому что хочется не просто проверить, висит ли сейчас весь сайт, а понять, почему именно так — что работает неправильно, а что — просто чуть-чуть не идеально, и стоит ли его переписывать или можно оставить как есть. И тут уже на сцену выходят инструменты. Быстрые, навороченные или просто проверенные временем — всё равно, главное, чтобы всё было понятно и не съедало полдня.
А дальше я расскажу про те, что реально помогают. Тех, что сам иногда использую на работе, даже знаю, какие лучше не трогать без хорошей причины. Честно говоря, когда я впервые столкнулся с этим всем, я промахнулся, потратил кучу времени, вместо того чтобы понять, что на самом деле важнее — быстро разобраться или долго искать, почему именно так.
Пока ещё не будем углубляться — расскажу дальше про конкретные инструменты, которые помогают реально разобраться со сложностями адаптивности и сделать так, чтобы сайт не тормозил даже на стареньких смартфонах или в браузерах, о которых ты давно забыл. Всю последующую “эпопею” с тестами я поделюсь дальше — чтобы было понятно, что делать, если вдруг ваш проект вдруг начал глючить на мобильных или планшетных версиях.
1
Вот где обычно всё идёт не так
Когда начинаешь рыться в инструментах для тестирования адаптивности, кажется, что всё должно быть просто. Есть симуляторы, есть эмуляторы – вроде бы нажал пару кнопок, и всё ясно. А потом сталкиваешься с тем, что большинство сервисов только «имитируют» реальные устройства или браузеры. И да, иногда эти имитации дают ложное ощущение, что всё идет хорошо. А поди, под правильным углом или при реальном использовании идет баг, который еле заметен на эмуляторе.
Например, недавно я тестировал сайт на эмуляторе Chrome и было всё в порядке: шрифты, кнопки – всё работает идеально. А как только зашёл на телефон, стало понятно, что скролл бара вообще не видно — и пользователь, даже не понимая, что он должен тянуть пальцем, видит, что ничего не происходит. В итоге выяснилось, что проблема в старой версии браузера, которую я на эмуляторе даже не решил проверить.
Или вот ещё кейс: сайт вроде бы адаптируется под мобильное, но у некоторых пользователей исчезает меню или бекграунд превращается в мусор, а ты такой — «ага, есть еще Safari 12 или Android 7». Вот тут эмул я надеюсь, что скрипты не леплены без учёта, а всё-таки, бывает, отключается видеоблокировка или даже — мельчишь — просто браузер не поддерживает CSS Grid, и всё выглядит как-то… не так.
Кое-что зависит от облачных сервисов для смартфонов, а кое-что — от характеристик устройств, которые ты держишь в руке. Но на практике всё равно оказывается, что большинство казусов всплывает только при реальном тесте. Тогда и появляется первый вопрос: а как это все проверять быстрее и правильнее, чтобы не гоняться за каждым багом по одному, ведь список устройств растёт?
Ну окей, а как это вообще меряется?
Здесь всё уже проще: есть инструменты, которые позволяют не просто сымитировать устройство, но и дать тебе понять, как сайт себя ведет с разными браузерами и железом. Но не все инструменты хороши, и некоторые – это чисто vanity metrics потому что показывают только внешний вид. А настоящая проверка — это понять, как сайт грузится, реагирует на взаимодействие, умеет ли он корректно показывать картинки с разным размером, работает ли скрипт при слабом интернет-соединении. Вот тут грамотные инструменты — просто находка.
Какие инструменты реально работают
Я расскажу именно про те, что сам использовал и не раз, потому что они реально спасают время и дают понимание ситуации. Тут и браузерные расширения, и облачные сервисы, и десктопные программы — всё по чуть-чуть, чтобы был выбор под разный сценарий.
1. Chrome DevTools — мини-лаборатория в кармане
Это самый доступный и знакомый большинству инструмент. Вместе с тем — один из лучших. Вкладка «Адаптивный дизайн» позволяет выбрать любой из предустановленных устройств или задать свою ширину/высоту. Можно даже отключить имитацию сети, чтобы понять, сколько реально времени занимает загрузка, и посмотреть, как выглядит сайт при слабом интернете.
Еще есть вкладка «Эмуляция условий подключения» — бесподобно позволяет понять, как сайт работает при 3G, 2G или даже оффлайн режиме. Когда-то я тут же понял, что некоторые скрипты не работают у меня при медленных соединениях, а я и не подумал проверить это.
2. BrowserStack и Sauce Labs — облачные эмуляторы
Да, они платные, зато реально живые устройства и браузеры. Можно выбрать конкретный iPhone, Samsung Galaxy или даже старенький Windows XP с IE7. В отличие от эмуляторов Chrome, тут ты испытываешь именно то, что пользователь увидит. И что важно — эти платформы часто дают доступ к старым версиям браузеров, о которых ты только слышал, но никогда не тестировал.
Я использовал их, когда нужно было убедиться, что дизайн не ломается при старых браузерах, и очень удивился, как много багов всё равно возникало именно там. И чтобы не платить много — у них есть бесплатные пробные периоды или бесплатные аккаунты с лимитами.
3. Responsively.app — быстрый и клевый локальный тестер
Это как легкая версия для быстрого переключения между устройствами. Просто открыл, вписал ширину окна — и смотришь, как выглядит сайт. Можно сохранить несколько пресетов для разных устройств — очень удобно, если часто проверяешь какой-то проект. Не полноценно, конечно, как Containous или BrowserStack, зато быстро, бесплатно и без риска.
4. Lighthouse от Google — проверка скорости и практичности
Только о скорости? Нет, тут есть раздел «Аудит» — и он рассказывает много интересного по поводу того, как сайт вообще грузится, и где есть «бутылочные горлышка» при адаптивной загрузке. Для меня лично — один из лучших способов понять общую картину, а дополнительно можно получить рекомендации по оптимизации.
5. Adobe Edge Inspect — старенький, но надежный друг
Если нужно было регулярно тестировать сразу на кучу устройств, раньше я пользовался им. Он позволяет подключать устройство прямо к компьютеру и смотреть, как сайт отображается. Сейчас вроде бы не так популярен, но у кого есть старое оборудование — почему бы не воспользоваться этим классическим решением.
Знаешь, самое важное — понять, что один инструмент обычно не даст полной картины. Лучше комбинировать, особенно чтобы проверить нагрузку и работу в реальных условиях. Например, открыть сайт в Chrome DevTools, проверить на облачном сервисе, а затем — дать пользователям поиграться. Тогда и видно, что реально не так.
Да и не скрывать: реально — все баги, что я рассказывал выше, выявлялись только при реальных тестах, а не на симуляторах. Поэтому рекомендую делать так: автоматизировать быстрые проверки, и погружаться в реальный браузер только когда есть конкретная проблема.
И, главное, не забывать, что тестирование адаптивки — это не только для красоты. Иногда баги на мобильных — это тормоза, которые напрямую влияют на отказы клиентов или рейтинги. Вкладывать в проверку стоит, даже если кажется, что всё работает. Потому что дальше — либо ты делаешь выгрузку на зрителя без ошибок, либо ищешь ошибку, когда наблюдаешь за провальными звонками поддержки, потому что кнопки не работают или меню исчезает.
Это всё фишки, что помогают мне быстрее находить и исправлять баги. Кто-то скажет — слишком много инструментов. Ну и что? Лучше так, чем регулярно слышать жалобы, что сайт тормозит или неправильно отображается, правда?Ну и что теперь с этим делать
Когда ты полнолицетворяетесь всеми этими инструментами, кажется, что всё просто: открыл, протестировал, увидел баг — поправил. Но на практике всё немного сложнее. Главное — понять, что ни один инструмент не даст 100% информации сам по себе. Их нужно использовать вместе и постоянно обновлять свой арсенал, ведь тестирование — это не разовая акция, а процесс. В современных условиях, когда обновляются браузеры, появляются новые ОС, а устройства — это вообще отдельная тема, важно быть в курсе новинок.
Лично я делаю так: использую Chrome DevTools для быстрой проверки, когда нужно быстро понять, как выглядит сайт на мобильных или десктопных разрешениях, потом подгоняю под реальные условия, используя облачные платформы вроде BrowserStack или Sauce Labs. Там я тестирую на самых разнообразных устройствах и браузерах, в том числе и древних, чтобы понять, где всё может сломаться. И обязательно обращаю внимание на скорость — Lighthouse помогает понять, где есть узкое место и что тормозит загрузку или взаимодействие.
Очень хорошо работает и Responsively.app, её используют для быстрого переключения между «устройствами» прямо в браузере, без особых накладных расходов. Ну и, конечно, никогда не лишним проверить сайт в реальных условиях — даже если больше всего relies на симуляцию — потому что баги именно вживую иногда вылезают совсем по-другому. И всё равно, эти баги очень часто всплывают только тогда, когда запускаешь сайт на реальном устройстве или под реальной сетью.
Вот тебе и мини-чеклист: чтобы быть уверенным, что сайт действительно адаптивен и не подведет, нужно вобрать: сначала быстро проверить в Chrome DevTools, понять работу при низкой скорости соединения, потом — во сне или в обед — дать тестерам или себе поиграться на облачных симуляторах, а потом – зареквизитировать пару устройств и пройтись по ним вживую. Не обязательно делать всё подряд каждый день, главное — периодически это повторять и помнить, что проверка должна быть комплексной.
Так что, если вдруг понимаешь, что твой сайт или проект ещё не готов к реальным условиям, попробуй делать так: сначала быстренько залетаешь в Chrome, устраиваешь проверку скорости и отображения; затем обращаешься к облачным тестам, чтобы добавлять разнообразия; и, наконец, — если есть возможность — берешь какое-нибудь старое или дешевое устройство, чтобы понять, как реагирует пользователь, которому не пофиг на тормоза или исчезающие навигации. И да, постоянно держать эти инструменты под рукой, чтобы не отставать — это как залог того, что баги не выйдут из-под контроля.
Ну вот как-то так. Вроде бы и просто, а по факту — чуть больше, чем кажется. Главное — системно подходить, не надеяться на один-единственный способ проверки и не забывать, что иногда реальный пользователь — самый лучший тестировщик.
