Покупка продуктов утомительна и занимает много времени. В поисках более удобного опыта я решил попробовать Instacart. К сожалению, использование их сайта также утомительно и требует много времени.
Общие действия занимают слишком много времени
В видео вы увидите, как я пытаюсь посетить целевую страницу своего местного продуктового магазина и после ее загрузки выполнить поиск по запросу йогурт.
Посещение домашней страницы продуктового магазина и поиск товаров.
Более 25 секунд для выполнения одной загрузки и поиска. Только загрузка страницы «витрина» Cub Foods заняла 14 секунд и 154 запросов.
Положительным моментом было несколько очень приятных графических заполнителей, которые создавали настроение, пока я ждал.
Когда это не ошибка JavaScript
Обычно, когда я смотрю на «современные» веб-сайты, основным виновником производительности является JavaScript. Слишком много скриптов делают слишком много рендеринга. Хотя в Instacart действительно слишком много JavaScript, у них есть более серьезная проблема: сервер.
Начальная загрузка страницы медленная
Instacart использует некоторую комбинацию серверного и клиентского рендеринга. С одной стороны, здорово, что они не просто загружают пустую страницу с большим счетчиком посередине и ждут, пока загрузится 20 МБ JavaScript.
С другой стороны, потребовалось 3 секунды, чтобы вернуть скелет одностраничного макета.
Изображения для заполнения шаблона-заполнителя заняли еще несколько секунд:
Если вы заметили, что первый сегмент URL-адреса после домена Cloudfront — /156x/. Эти конечные точки будут возвращать изображения нестандартного размера, и этот первый сегмент будет запрошенными размерами. Например, вы можете изменить этот сегмент на /300x/, и вы получите увеличенное изображение с сохранением соотношения сторон (оно будет иметь ширину 300 пикселей при любой высоте, которая должна быть, чтобы сохранить соотношение). Вы также можете указать высоту, если хотите другой эффект:
Круто, но это почти наверняка одна из причин, по которой загрузка некешированных изображений такая медленная. Разработчики Cloudfront проделали большую работу, чтобы создать собственное изображение и отправить его по сети по запросу.
Справедливости ради, эти изображения имеют правильные заголовки ответов кэша, поэтому при последующих загрузках страниц изображения будут обслуживаться из кэша памяти браузера. Но этот первый удар очень медленный.
API слишком медленный
Медленная загрузка не только страницы и изображений. Серверы, отвечающие на запросы API, тоже не торопятся. Некоторые вызовы для заполнения данных на странице заняли 5 секунд!
Одна из показанных здесь конечных точек извлекает информацию о купоне. В видео начальной загрузки вы можете увидеть, что раздел купонов отображается особенно медленно. Несмотря на то, что в нижней части страницы загружен контент, пользователь понятия не имеет, поскольку заполнители все еще отображаются для раздела купонов до тех пор, пока этот вызов не вернется.
Заполнители хороши, но чем быстрее конечные точки, тем лучше
Здесь гибридная модель рендеринга немного разваливается. После загрузки страницы отображается много динамического контента. А поскольку API работает медленно, пользователь получает еще больше заполнителей.
Когда пользователь прокручивает страницу вниз, по запросу выполняются вызовы API для отображения продуктов из каждого продуктового отдела. Эти вызовы могут занимать более 2 секунд каждый. И их много.
Для каждого из них мы получаем дополнительную графику-заполнитель, пока сервер не вернет ответ:
Заполнители хорошо справляются с минимизацией мусора или кумулятивного смещения макета, но они плохая замена фактическому контенту. Как это ни парадоксально, я обнаружил, что они также могут замедлить работу сайта, поскольку пользовательский интерфейс так часто меняется из-под пользователя.
Может быть, Instacart не думает, что у него проблемы с производительностью?
В инженерном блоге Instacart есть несколько статей, в которых обсуждается внутренняя техническая реализация сайта. В обеих связанных статьях они обсуждают улучшенную производительность и существующую здоровую производительность сайта. Возможно, основная проблема в том, что они не думают, что есть проблемы с производительностью, которые нужно исправить?
Большинство современных технических стеков способны обслуживать страницы и вызовы API менее чем за секунду, если это является целью компании. Подозреваю, в данном случае у них ограниченные ресурсы и другие приоритеты. Возможно, в телефонном приложении дела обстоят лучше, но я думаю, что пока ограничусь походом в продуктовый магазин, так быстрее.
Первоначально опубликовано на https://requestmetrics.com.
