Время загрузки, генераторы статических узлов и SEO: Как мы снизили время загрузки собственного сайта на 74%

Предстоящий переход Google к индексированию мобильных устройств в сочетании с повышенным ожиданием производительности мобильного сайта должен убедить владельцев сайтов рассматривать статичное создание сайтов. Участник Chris Liversidge объясняет.В течение последнего десятилетия Google постоянно повышала планку загрузки сайтов, и предстоящий переход к индексированию мобильных устройств в сочетании с растущими ожиданиями производительности мобильных сайтов должен быть явным предупреждающим знаком для владельцев сайтов. Однако владельцы сайтов, похоже, не слушают. К сожалению, на основании нашего анализа 10 000 + мобильных веб-доменов мы обнаружили, что большинство мобильных сайтов не соответствуют этому бару: среднее время загрузки для мобильных сайтов составляет 19 секунд по сравнению с 3G-соединениями. Исследование DoubleClick, опубликованное в сентябре 2016 года В нашей компании мы экспериментировали в прошлом году со статическим созданием сайта. Наши тесты на нашем собственном сайте нацелены на то, чтобы дать нам возможность оценить проблемы, с которыми сталкиваются владельцы сайтов, понять возможности и возможности для повышения эффективности, а также изучить практические ограничения в управлении контентом - одна из ключевых критических замечаний статического сайта поколение. Наш сайт QueryClick.com был небольшим, достаточно оптимизированным B2B-сайтом, но в среднем за период до начала загрузки статического сайта (июль 2016 года) он составлял ~ 6,99 секунд, а в месяц - до 1,8 секунды следующий. Это означало сокращение времени загрузки на 74,29 процента, несмотря на некоторые проблемы с ответом на сервер, возникшие в период активного развития сайта. За месяц до и после перехода на статическую инфраструктуру генерации сайтов. Мы улучшили оптимизацию сервера за год, достигнув нашей целевой цели на одну секунду, даже при тестировании влияния менее эффективных элементов, основанных на JavaScript. Да мы знаем! Мы даже не использовали спрайты, gzipping или другие подобные методы, что подчеркивает влияние подхода, основанного на платформе, на решение проблемы скорости страницы.

Первый подход к скорости страницы на платформе

Я уже писал о различных уровнях важности различных аспектов скорости страницы в SEO и о том, как алгоритм Google использует данные о результатах отказов SERP (когда пользователи возвращаются к своим SERPs после потери терпения с сайта с медленной загрузкой) , Но стоит снова обратиться к первому миру: время отклика сервера и критическое событие пути переноса (точка, в которой все визуализируется в окне просмотра исходного устройства) являются ключевыми для предоставления высокопроизводительных SEO, особенно для сайтов корпоративного уровня. Любой разработчик, заслуживающий своей соли, будет смотреть на запросы загрузки ресурсов на сайте QueryClick, показанные на приведенном выше изображении, и качать головой во всех неоптимизированных элементах. Но в этом суть. Высокая производительность была достигнута, несмотря на отсутствие строгой оптимизации в развертывании кода и активов. Это было обусловлено платформой и решениями архитектуры на высоком уровне. Google хотел бы, чтобы мы улучшались дальше - и мы это сделаем, но реальные изменения производительности уже были выполнены. Итак, какую архитектуру мы использовали? Как евангелисты Python и Django, мы пишем копию в Markdown и нажимаем ее на наш сервер промежуточного сервера через Github, где мы можем проверить, чтобы все было в порядке. Затем мы используем Celery, чтобы установить время для копирования промежуточного сервера в живой репозиторий Git. Затем Cactus восстанавливает страницы, и, voila, живой сервер заполняется статическими страницами. Конечно, для вашего среднего производителя контента эта инфраструктура не так проста в создании или обслуживании как стандартная CMS без каких-либо технических ноу-хау. Это наиболее распространенная критика статических развертываний сайтов, и многие корпоративные клиенты рассматривают ее как выключатель, когда ищут решения статического сайта. Разумеется, если вы управляете инвентаризацией продукта, которая динамически изменяется на десятки тысяч в день, что делает один из наших клиентов, тогда необходим надежный задний конец управления. Вот почему любой, кто развертывает решение производительности статического сайта на предприятии, должен использовать Oracle ATG или тому подобное, что может легко создавать и обрабатывать статические веб-страницы с использованием его API. Когда вы думаете об этом, динамическое управление сайтом требует значительно большей аппаратной инфраструктуры, чем статический. Если вам нужно больше убедить, взгляните на множество статических кодовых баз, уже находящихся в полете. Они используют различные языки программирования, и многие из них полностью способны встраиваться в корпоративную среду. Когда вы также используете сеть доставки контента (CDN) в производстве, вы можете предложить надежное решение, которое обеспечивает как высокую скорость (для даже плохих мобильных сетей 3G), так и общую избыточность и устранение проблем с отказом сервера. Динамическое статическое обеспечение активов и современные средства кэширования на статических генераторах обеспечивают чистую, живую настройку контента, которая в точности сопоставима с динамическим созданием сайта на долю аппаратного спроса. Для общей сети может потребоваться годы, чтобы догнать новаторский толчок Google для современных, быстрых и простых в использовании веб-приложений. Но если вы хотите воспользоваться коэффициентом конверсии и опытом вашего бренда, а также ощутите значительный успех в SEO-производительности благодаря быстрой критичной производительности рендеринга и положительному результату отскакивания SERP, тогда вам нужно, чтобы ваша команда разработчиков расследовала и обнаружила архитектуру, которая работает для вашего сайт сегодня. Мнения, выраженные в этой статье, принадлежат авторам гостевых изданий, а не обязательно поисковым системам. Здесь перечислены авторы работ.