Я недавно путешествовал по кроличьей норе, которая требуется, чтобы ответить на вопрос заголовка. В этой статье я попытаюсь поделиться некоторыми из своих выводов, которые могут помочь вам сэкономить время.
В другой статье я описал, как полезно, если каждый заинтересованный человек лучше понимает некоторые технические аспекты системы.
Производительность одних систем очень легко измерить, а другие намного сложнее.
вступление
Если вам нужно измерить производительность вашего веб-сервера, уже должны быть показатели, на которые вы можете посмотреть, чтобы определить среднее время отклика и т. д.
С помощью этого показателя вы можете отслеживать любые улучшения, которые вы вносите в код своего веб-сервера, и отслеживать его влияние на среднее время отклика.
Круто, теперь веб-сервер находится под наблюдением, и мы можем внести улучшения, если считаем, что время отклика слишком медленное. Большой!
Если представить, что мы доставляем сторонний скрипт на веб-сайт, он должен отображать что-то на их сайте (рекламу). Вдруг клиент (владелец сайта) жалуется, что наш скрипт тормозит и реклама показывается слишком медленно!
Ваш скрипт тормозит, исправьте!
Хорошо, я воспринимаю это как любой другой отчет о проблемах или «ошибках». Я быстро просматриваю веб-сайт и обнаруживаю, что он работает «быстро» и, как и ожидалось, с моей точки зрения.
Проблема
Поняв, что это прекрасно работает на моей установке (настольный компьютер, ноутбук и мобильный телефон), я решил исключить основную проблему обсуждения вещей без количественных данных (реальных чисел), а также исключить любые аномалии, которые любой человек может иметь в своей собственной системе ( клиент).
Особенно производительность пользовательского интерфейса может быть очень «религиозной» и очень субъективной. Поэтому первая проблема, к которой нужно подойти, — это собрать некоторые данные, чтобы мы могли предпринять некоторые обоснованные действия, вместо того, чтобы пытаться исправить проблемы на старом и медленном телефоне одного человека.
При отладке клиентских проблем нам приходится иметь дело с широким спектром браузеров, компьютеров, операционных систем, сетевых подключений, разрешений экрана, брандмауэров, блокировщиков рекламы, настроек устройств и т. д.
Таким образом, суть проблемы заключается в том, чтобы определить, существует ли на самом деле общая проблема, и если да, то определить, в чем именно заключается проблема.
Решение
Числа! и их много. Если мы собираемся анализировать субъективный опыт, нам будет намного лучше, если у нас будут какие-то фактические данные для обсуждения.
Итак, для предложенной проблемы я решил, что самый простой способ подойти к проблеме — разбить весь процесс «загрузки» на логические шаги и измерить вклад каждого шага в общее «время загрузки».
Ниже приведен конечный «продукт», который должен помочь количественно оценить проблему, указанную ранее. На самом деле, это редко должно быть настолько сложным. Даже быстрая диаграмма в Google Sheets может сделать это.
Приведенные выше диаграммы созданы с использованием AWS Timestream и Grafana (и некоторых других компонентов, которые не имеют отношения к этой статье).
Приведенная выше диаграмма дает вам
- Отправная точка для обсуждения скорости (или любой другой интересующей вас метрики)
- Способ для тех, кто не является разработчиком, получить представление о технических шагах, которые влияют на общую производительность, чтобы они могли принимать решения о будущих областях разработки.
- Создает базовый уровень, который можно сравнить с другими сайтами и/или при оптимизации.
Как повысить производительность в целом
При анализе приведенных выше цифр есть несколько вещей, которые я рассматривал как более общие решения для группы проблем, аналогичных описанной (медленная реклама).
Выполнение реальных улучшений
В некоторых случаях есть реальные технические вещи, которые можно улучшить, что напрямую улучшит производительность. В приведенном выше случае их обычно можно разделить на две группы.
1. Актуальные проблемы/ошибки
Это ошибки или методы реализации, которые можно улучшить, чтобы повысить общую производительность системы. Примером этого может быть, если вы использовали функцию setTimeout с задержкой 500 мс, но на самом деле вы могли бы решить проблему с помощью MutationObserver и, следовательно, не должны всегда ждать 500 мс.
2. Компромиссы
В случае с рекламой вы можете пойти на множество компромиссов, но в большинстве систем есть компромиссы, которые позволят вам настроить производительность системы, если вы пожертвуете чем-то другим. Простым примером распространенного компромисса в сфере рекламных технологий является использование предварительной заявки.
Предварительная ставка — это, как правило, способ увеличить ваш доход от рекламы, но она по своей сути увеличивает время загрузки любой рекламы.
Поэтому, если производительность – ваш единственный показатель успеха, вам не следует использовать предварительную ставку (и вообще не показывать рекламу).
Всегда будут компромиссы, и если вы сможете изложить их для заинтересованных сторон, вы сможете принять их решение, а не свое :)
Притворяться
В случае с вещами в браузере это часто должно переводиться в то, что отображается на экране для конечного пользователя.
Обычный способ создать иллюзию скорости — просто показать что-то еще, пока не будет готова ваша вещь. Это может быть значок загрузки, фиктивная картинка или что-то еще.
Но показать что-то (даже если это не так важно) часто лучше, чем ждать, пока что-то медленно загрузится.
Помните, что все относительно!
Дополнительные материалы на PlainEnglish.io. Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter, LinkedIn, YouTube и Discord . Заинтересованы в хакинге роста? Ознакомьтесь с разделом Схема.
