Как это Amazon.in/com или Flipkart.com сверхбыстрый?

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

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

Обычно происходит то, что весь полноформатный HTML-код страницы создается сервером и доставляется в браузер, после чего браузер начинает отображать и отображать страницу. Только на этом этапе ресурсы могут загружаться, поэтому изображения, JS, CSS и т. Д. В качестве URL-адресов для этих ресурсов, конечно, содержатся в этом HTML.

Таким образом, браузер начнет отображать содержимое страницы только после того, как сервер отправит ему некоторый HTML-код для фактического отображения. В такой сложной системе, как магазин Magento, создание HTML-кода для страницы занимает у сервера довольно много времени, так как необходимо выполнить много тысяч строк кода и выполнить множество запросов к базе данных. Это займет у сервера разное количество времени в зависимости от хостинга и спецификации сервера, но это никогда не будет "сверхбыстрым".

Но что, если бы мы могли просто быстро создайте часть страницы и сначала отправьте ее в браузер, чтобы страница начала отображаться в этот момент, а затем отправьте остальные части страницы, как только они будут созданы? Ну, это именно то, что делает BigPipe, и что используют такие сайты, как Amazon и Facebook, чтобы их страницы начинали очень быстро отображаться в браузере.

Посмотрите на время "ожидания" и "получения" для этого запроса (скриншот из firebug, статистика для первого запроса вверху, игнорируйте отдых):

Время "ожидания" - это время, необходимое серверу для создания HTML-кода и отправки его в браузер, чтобы браузер мог начать визуализацию страницы. В этом случае время "ожидания" очень короткое, всего 49 мс. Таким образом, время отправки первого байта данных на сервер (TTFB) проходит очень быстро. Время "получения" - это время, необходимое браузеру для получения всех данных для этого запроса с сервера. Как ни странно, вы заметите, что он намного длиннее чем время ожидания в 1,29 с. Таким образом, несмотря на то, что сервер впервые начинает отправлять данные всего через 49 мс, для отправки всего HTML-кода на страницу требуется еще 1,29 секунды. Такой профиль запроса является признаком использования подхода BigPipe, который сбрасывает часть страницы вниз по соединению с браузером для достижения хорошего TTFB, затем сохраняет соединение открытым до тех пор, пока не будет создана остальная часть страницы, а также сбрасывает соединение.

Сравните этот запрос с этим из демонстрационный сайт Magento:

Вы можете сразу увидеть полную противоположность пропорциональных временных интервалов для "ожидания" и "получения". Здесь время ожидания намного больше по сравнению с очень коротким временем "приема". Это указывает на то, что сервер генерирует целые страницы HTML, прежде чем отправлять их в браузер. Поэтому мы можем сделать вывод, что TTFB намного медленнее, так как страница начнет отображаться в браузере через гораздо более длительный период времени - 299 мс против всего 49 мс для Amazon. Время приема очень короткое - всего 2 мс, так как на данный момент все, что нужно сделать серверу, это доставить HTML в виде текста в браузер, поскольку страница полностью построена. Интересно, что вы можете заметить, что для создания всего HTML-кода страниц на Amazon требуется около 1,3 секунды, но только около 300 мс в демо-версии Magento - так что Magento на самом деле быстрее, именно из-за BigPipe он выглядит наоборот.

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

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

Проще говоря, полное кэширование страниц сохранит весь HTML-код страницы для запроса, а затем будет обслуживать этот кэшированный HTML при следующем поступлении запроса на эту страницу. Большинство решений извлекают полный HTML-код страницы, заполняют его динамическим контентом (например, мини-корзиной, ссылками на заголовки и т. Д.), А затем доставляют полный HTML-код в браузер. Это дает приличный TTFB, но эволюционировавшее кэширование вместо этого извлекает кэшированный полный HTML-код страницы, немедленно доставляет его в браузер, а затем заполняет страницу динамическим контентом либо через BigPipe, либо через AJAX. Это дает отличный TTFB, поскольку вы предоставляете полный HTML-код страницы в браузер полностью за пределами платформы Magento (которая медленно внедряется).

Таким образом, как BigPipe, так и полностраничное кэширование - это оба подхода, которые вы, возможно, захотите рассмотреть (хотя BigPipe без использования развитого кэширования, скорее всего, потребуется пользовательская сборка).

В любом случае, все вышеперечисленные сделки просто с первым запросом к серверу, который генерирует HTML для страницы, после этого все дальнейшие запросы направляются после ресурсов на странице, таких как изображения, JS и CSS или для внешних служб. Выполнение каждого из этих запросов занимает определенное время, поэтому чем больше запросов делает страница, тем больше времени требуется для полной загрузки страницы. вы должны постараться свести к минимуму количество ресурсов на своих страницах настолько, насколько это реально, и CDN поможет распределить запросы по нескольким доменам (это означает, что браузер может запрашивать больше ресурсов одновременно в качестве ограничения запроса для каждого домена).

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

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

Надеюсь, некоторые моменты для рассмотрения. Позвольте мне знайте, хотите ли вы получить более подробную информацию о чем-либо (хотя кто-то другой был бы более квалифицирован, чем я, чтобы ответить на вопросы, связанные с хостингом).