Потребности наших пользователей росли и совершенствовались, в частности благодаря двум вещам: первому прогрессу внедрения, с момента появления Gmail и его асинхронной загрузки, а также его эволюции в этой области, где он обеспечил функциональность приложений. все более продвинутый; Вторым фактором является мобильное использование, теперь пользователь хочет видеть на своих мобильных веб-сайтах, которые работают без каких-либо проблем на их устройствах, например, они не хотят использовать подходы или находить компоненты, которые не работают.
Что происходит потом?
Что-то очень простое, концентрируясь на предоставлении всех этих функциональных возможностей нашим приложениям, мы часто забываем, что производительность должна сопровождать наше предложение, одна из самых распространенных ошибок заключается в том, что, как только мы завершили всю нашу разработку, мы не понимаем, что ваш Производительность очень низкая, и мы замечаем, что проблема возникает только после запуска продукта в производство.
Адаптивный дизайн
Тенденция Адаптивного Дизайна увеличилась и была определена как нечто, что необходимо принимать во внимание, в том числе Google немного изменил свой алгоритм поиска, чтобы дать приоритет страницам в своем представлении результатов, которые имеют адекватные версии для мобильные телефоны
Проблема заключается в том, что, хотя мы понимаем, к чему это приведет, во многих случаях мы игнорируем лучшие способы этого процесса, но одной из классических ошибок является отсутствие у нас подходящих изображений для устройства.
Распространенная ошибка
Эта последняя ошибка, о которой мы упоминали, заставляет нас загружать изображения в 3 раза больше, чем необходимо, но, конечно же, красота супер четкого изображения заставляет нас ошибочно думать, что клиент получит немного меньшую производительность для результата. Что мы не совсем понимаем, так это то, что если страница не загружается в течение 5 секунд на мобильном телефоне или планшете, мы, вероятно, перейдем в другое место из-за плохого просмотра.
Другая проблема возникает, когда мы загружаем больше элементов, таких как таблицы стилей, дополнительный JavaScript и даже дополнительные изображения, при доступе с мобильного телефона. Это делает версию нашего приложения, которая должна быть легче, в итоге оказывается более тяжелым монстром, чем версия для ПК.
Лучше всего сначала узнать, какую мобильную разработку мы хотим осуществить, поскольку существует несколько альтернатив и стратегий развития.
Начальные тесты Как их сделать?
Когда мы разрабатываем, у нас почти всегда есть локальная среда, в которой мы первоначально тестируем наш код, и эта практика неплоха для этой цели, видя, как наш код обретает форму и дает нам удовлетворительные результаты.
Но всегда случается так, что как только у нас появляется достойная версия для пользовательского опыта, мы показываем нашим функциональным аналитикам, клиентам или руководителям эту же среду, и, очевидно, не будучи подключенными к Интернету или являясь внутренним сервером, производительность будет казаться удивительной. Это вводит нас в заблуждение, так как не видя проблем с производительностью по указанным причинам, мы будем считать, что наше веб-приложение чрезвычайно оптимально с точки зрения скорости.
Производственные ошибки
При развертывании в рабочей среде мы начинаем видеть первые неудачи, компоненты, которые не загружаются должным образом, процессы, которые терпят неудачу, потому что система занимает много времени, пользователи недовольны, потому что Интернет очень медленный и должен ждать слишком долго, среди других ошибок.
Именно здесь мы должны увидеть реальные тестовые среды, конечно же, должна быть среда разработки, в которой проверяется функциональность кода, но мы должны создать качественную среду, в которой мы проверяем пользовательский опыт и производительность, этой средой можно управлять в домен, отличный от продукта, который мы выпустим, но он должен иметь что-то особенное, и он должен быть в Интернете, если это возможно, в том же хостинг- провайдере или в той же команде, что и наш конечный продукт.
У последнего, который мы объясняем, есть смоделированная причина, близкая к конечной производственной среде, поэтому, если наше приложение работает медленно, мы увидим его, когда будем показывать работу тем, кто несет совместную ответственность за проект, и там мы увидим, насколько эффективно мы были Сделай что-нибудь, что даст.
Мобильный сначала
Одним из первых действий, которые мы должны принять во внимание, является создание дизайна Mobile First, то есть мы должны сначала создать версию, которая будет использоваться для мобильных телефонов, а затем перейти к более крупным версиям ( планшеты, фаблеты и т. Д.), пока вы не достигнете окончательной версии для настольного компьютера, это не позволит нам добавлять новые элементы для адаптации настольного компьютера к мобильной версии.
Но не только для того, чтобы избежать загрузки элементов, дополнения - это преимущество, которое дает нам эта методология, мы также можем начать тестирование производительности мобильных устройств раньше, что даст нам преимущество во время обнаружения возможных узких мест, поскольку это Версия должна быть намного быстрее, чем другие. $config[ads_text5] not found
Что такое веб-производительность?
Производительность в сети - это измерение времени между посещением веб-сайта, которое полностью отображается для возможности его использования.
Эта простая концепция скрывает несколько граней позади, во-первых, хотя между началом посещения и тем, что показано, будет некоторое время, не обязательно, чтобы в начале все выглядело идеально, мы можем постепенно показывать разделы, чтобы пользователь мог их видеть. Например, показывается структурированный контент, и, наконец, загружаются изображения, а затем функции JavaScript .
Тем не менее, измерение будет, когда все доступно для использования посетителем или пользователем.
Индикаторы для учета
Есть несколько показателей, которые мы должны принять во внимание, чтобы оценить производительность нашего сайта, а именно:
количественный
В этой категории показателей у нас есть факторы или параметры, которые мы можем измерить в соответствии с формулой, числами или определенными методами, которые не могут быть подвергнуты субъективной интерпретации.
качественный
Эта категория противоположна предыдущей, потому что факторы, которые мы принимаем во внимание, не могут быть измерены с помощью числа или формулы, и в основном это субъективные интерпретации, однако во многих случаях они могут опираться на количественные показатели для поддержки некоторых из своих объяснения.
Поскольку мы знаем две широкие категории, давайте рассмотрим некоторые конкретные показатели, которые мы можем начать учитывать, когда начинаем измерять производительность наших веб-приложений.
Время загрузки страницы
Этот количественный показатель позволяет нам получить число, выражающее секунды, которые требуются для полной загрузки приложения или веб-страницы, обычно выражается в секундах и должно быть меньше 2 цифр, то есть меньше 10 секунд .
Размер страницы
Это сумма весов всех компонентов, составляющих наше приложение, то есть общий вес перевода, который происходит с момента нашего посещения нашей страницы до ее отображения.
Количество HTTP-запросов
Это количество подключений, которые наше приложение устанавливает при загрузке, эти запросы могут быть запросами на загрузку CSS- файлов, файлов JS, изображений и вызовов в другие библиотеки или службы.
Время отображения страницы
Это время, которое проходит между тем, как мы загрузили ресурсы, и чтобы страница или приложение могли отображаться правильно.
инструменты
Поскольку мы знаем, что мы должны искать и измерять, нам нужно знать, какие инструменты использовать, в настоящее время у нас есть много вариантов для этого, от веб-инструментов, которые выполняют онлайн-анализ, до дополнений текущих браузеров, которые помогают нам понять процесс, пока мы находимся жить в реальном времени
GTmetrix$config[ads_text5] not found
Веб-сайт gtmetrix.com предлагает очень интересный сервис, он предоставляет нам статистику загрузки нашей страницы, основанную на двух уважаемых алгоритмах на уровне производительности веб-сайтов, один - скорость страницы, а другой - медленно. Кроме того, мы также предлагаем рекомендации по улучшению.
На следующем изображении мы видим анализ сайта с высоким трафиком, такого как Facebook, поэтому мы можем видеть, что мы можем найти.
Мы отмечаем, что они сообщают нам, где находится компонент, который они измеряют, и приоритет для повышения производительности, это нам очень помогает, когда мы начинаем, поскольку мы быстро решаем базовые проблемы. $config[ads_text6] not found
Консоль разработчика Chrome
Google Chrome стал вездесущим браузером, и это правильно, чтобы быть одним из наиболее используемых, а также имеет большой набор инструментов для разработчиков, среди них у нас есть сетевая консоль, здесь мы можем увидеть количество ресурсов, запросов и время, необходимое для загрузки.
Идеально, как только мы освоим GTmetrix, напасть на проблему производительности отсюда, потому что мы можем увидеть более подробно вещи, которые влияют на нас.
Давайте посмотрим на следующем рисунке, как выглядит эта консоль при повторном анализе Facebook :
Мы замечаем, как указывают время и ресурс, который вызывается во время загрузки страницы, это очень полезно, когда у нас возникают проблемы с производительностью, и мы не знаем, как их атаковать, здесь мы графически видим весь процесс нашей страницы.
На этом мы завершили этот урок, мы узнали, что такое производительность, как она измеряется, и некоторые инструменты для достижения цели по ее улучшению. Очевидно, что это не та тема, которая решается простым чтением учебного пособия, есть много переменных, и лучший способ достичь хорошего результата - через практику и постоянный анализ.
СТАТЬИ