Игровой Google — идеальный результат на маяке

Я всегда не решался поделиться своим кодом. Дело не в том, что я считаю его некачественным и не страдаю синдромом самозванца. Просто, когда я делюсь кодом, я могу заглянуть в то безумие, которое царит в моей голове, а по отношению ко всем остальным это кажется чем-то жестоким. Позвольте мне направить вас в путешествие, которое чуть не поставило меня на грань здравого смысла. Все началось с обновления Google Lighthouse.

Для тех, кто не занимается поисковой оптимизацией, обновление Google Lighthouse стало существенным изменением поискового рейтинга, зависящим от эффективности веб-сайта и соблюдения лучших практик. Если вы хотите протестировать свой веб-сайт, просто откройте его в Chrome на рабочем столе, нажмите клавишу F12, чтобы открыть инструменты разработчика Chrome, а затем перейдите на вкладку «Lighthouse». Выберите настольный компьютер или мобильное устройство и нажмите «Анализировать». Примерно через минуту вы получите пять баллов (от 0 до 100) за производительность, доступность, лучшие практики, SEO и прогрессивное веб-приложение (PWA).

Прежде чем углубиться в технические подробности, позвольте мне представиться. Меня зовут Джонатан Грэнтэм, и я горжусь тем, что владею небольшой компанией Nexoid, специализирующейся на программном обеспечении ERP и ITSM, занимающейся бизнесом в сфере B2B SaaS. Веб-сайт, о котором я расскажу в этой статье www.nexoid.com. Не стесняйтесь посмотреть, открыть исходный код. Вы также можете подписаться на меня в LinkedIn. Мой профиль www.linkedin.com/in/jonathongrantham/

После выхода обновления Google Chrome Lighthouse я поступил так же, как и любой добросовестный владелец бизнеса: проверил свой веб-сайт. К моему большому огорчению, результаты оказались далеко не удовлетворительными. Получив 21/100 баллов за производительность, 30/100 за доступность, 45/100 за передовую практику, 11/100 за SEO и неудачу за PWA, я был шокирован. Я лично создал веб-сайт, представляющий собой довольно стандартную одностраничную архитектуру с использованием React.js. Результаты оказались сокрушительным ударом.

Несмотря на первоначальную неудачу, я запустил MS Code и начал решать проблемы одну за другой, причем моей главной целью была производительность. Руководства, представленные в инструменте Lighthouse, оказались весьма полезными. Я преобразовал все изображения из JPEG и PNG в современные файлы WebP и обеспечил каждому тегу img свойство ширины и длины, предотвращающее смещение макета. Только эти изменения повысили мою оценку с 21/100 до 60/100. Это было значительное улучшение, но далеко не идеальное. Осталось только одно предложение: «сократить количество неиспользуемого JavaScript», что не особенно помогло. Единственным доступным JavaScript был фреймворк React.js, а все остальное было удалено.

Благодаря Nexoid компания AM Digital смогла распространить преимущества унифицированного ITSM-решения и на операции, ориентированные на клиентов. Клиентский портал, интегрированный с Azure, обеспечил клиентам более интерактивный, динамичный и удобный интерфейс, что привело к повышению степени удовлетворенности и вовлеченности клиентов. Портал позволял синхронизировать данные клиентов в режиме реального времени, обеспечивая актуальность и точность всей информации, тем самым улучшая качество предоставляемых услуг и укрепляя отношения между клиентом и компанией.

Несмотря на мои настойчивые усилия по устранению этой проблемы, я постоянно сталкивался с препятствиями. Я попытался удалить части React.js, изучил «ленивую загрузку» и протестировал различные оптимизаторы и компрессии. Однако проблема возникла из-за самой версии React.js, размер которой составлял примерно полмегабайта.

Я почти слышу, как опытные веб-разработчики кричат: «Не используйте React для веб-сайта! Он предназначен для создания веб-приложений!» Теперь мне это хорошо известно.

То, что начиналось как простая задача по преобразованию нескольких изображений, теперь превратилось в полную реконструкцию веб-сайта с использованием нового фреймворка. Разочаровавшись и произнеся себе под нос несколько слов, я отправился на поиски подходящей замены. Сначала я рассматривал Vue, а затем Angular, которые, возможно, являются крупнейшими конкурентами React.js. Однако у обоих была одна и та же проблема.

Пытаясь упростить ситуацию, я решил изучить старые технологии и попробовал jQuery. Тем не менее, я столкнулся с той же проблемой. Стало совершенно очевидно, что не существует готового фреймворка для одностраничной архитектуры, который мог бы удовлетворить божеств Google.

Казалось, что единственным оставшимся вариантом было прибегнуть к ванильному JavaScript.

Моя серия экспериментов началась с простой HTML-страницы без JavaScript. Затем я попробовал создать HTML-страницу с div, содержимое которой можно было бы заменить. Я быстро понял, что одновременное внесение нескольких изменений в страницу с помощью JavaScript влечет за собой штрафы со стороны Lighthouse. Решение заключалось в том, чтобы обрабатывать содержимое тега body в виде строки, а затем реинтегрировать его, тем самым создавая только одно видимое изменение DOM.

Теперь у меня была минималистичная HTML-страница с пустым тегом body, дополненная небольшой функцией onload в теге head. Эта функция проверила URL-адрес и выполнила запрос HTML GET для получения соответствующего текстового файла, содержащего HTML-код основной части страницы. Можно было бы подумать, что это подходящее решение. К сожалению, когда я попытался динамически загрузить функциональность JavaScript, у меня ничего не вышло.

В отличие от других тегов, если вы добавите тег скрипта с простым предупреждением («yes this fired») в строку body contents, он не будет выполнен. Хотя это и не идеально, один из способов решения этой проблемы заключался в том, чтобы проанализировать основную строку, идентифицировать все содержимое тега скрипта и поместить его в функцию оценки JavaScript. Этот подход оказался довольно эффективным, но при работе с пространствами имен возникали проблемы, а консоль разработчика была переполнена неприглядными предупреждениями. Решение состояло в том, чтобы извлечь теги скрипта из HTML и добавить их в качестве элемента сценария после рендеринга DOM. По какой-то причине Google не оштрафовал это действие.

Был достигнут прогресс, и у меня было базовое решение для одностраничной архитектуры. Но не так быстро. В то время как Google эффективно индексирует страницы с одностраничной архитектурой (они открывают их в браузере, запускают весь JavaScript, а затем сканируют DOM), Bing, Yahoo и другие крупные поисковые системы используют аналогичный, более простой метод. Однако большинство других платформ, таких как Facebook, Reddit, LinkedIn и WhatsApp, загружают только HTML-файл, получая небольшой HTML-файл с пустым текстом. Мое решение оказалось нежизнеспособным. Теперь мне пришлось повторить эту концепцию на каждой странице веб-сайта и включить JavaScript для перехода в режим одностраничной архитектуры при переходе пользователя по ссылке.

Мне нужен был инструмент, способный генерировать HTML для каждой страницы на основе моего решения. Мне пришло в голову, что в моем распоряжении есть идеальный ресурс: моя собственная ERP-система Nexoid. Я создал модель Nexoid, включающую объекты данных веб-сайта и веб-страницы. Запись на сайте облегчила создание типового шаблона веб-страницы, в то время как записи веб-страницы содержали содержимое каждой отдельной страницы. Последним кусочком пазла была функция рабочего процесса или скрипт, который мог считывать записи веб-сайта и все связанные с ним записи веб-страницы для создания HTML-файлов. Через несколько дней он заработал. Я создал базовую систему управления контентом (CMS). На данный момент разработка CMS не слишком сложна; реальная проблема возникает при интеграции других рабочих процессов CMS, согласованиях, локализациях, предварительных просмотрах и т. д.

Ключевым требованием к новому веб-сайту была локализация; мы планировали запустить его на 11 языках. Будучи ИТ-компанией, я, естественно, склонялась к технологическим решениям. Вместо того чтобы нанимать переводчика для каждой страницы, я выбрал AWS Translate. Хотя переводчики с искусственным интеллектом работают достойно, они не идеальны, а ошибки достаточно заметны, чтобы показать, что их происхождение не связано с человеком. Один франкоговорящий сотрудник оценил перевод, написанный искусственным интеллектом, и дал ему оценку 6/10, назвав его «понятным, но ненормальным французским языком».

Однако мы наткнулись на ценный трюк. Мы обнаружили, что вначале, загружая текст на английском языке через ChatGPT, попросив его «привести его в порядок», а затем вставив его, текст переформулируется так, что текст остается английским, но гораздо более совместимым с языковыми моделями. Использование английского языка, переработанного в ChatGPT, в качестве основы для перевода значительно повышает качество перевода, повышая его до 9 или даже 10 баллов из 10.

Разработав прочную технологическую основу для создания сайта, я добился успехов. Однако, когда мы начали создавать более сложные страницы, возникла новая проблема. Согласно новым рекомендациям Lighthouse, возникла необходимость объединить весь JavaScript, CSS и HTML в один файл. Это также относилось к версиям одностраничной архитектуры.

Мы прибегли к вставке всех файлов JavaScript и CSS в виде встроенных тегов. Аналогичная стратегия требовалась для версии Single Page Architecture. Мы создали файл JSON, содержащий все скрипты, стили и HTML.

Следующей проблемой компания Lighthouse определила размер ресурсов; файлы страниц HTML и JSON были слишком большими. Я решил эту проблему с помощью библиотеки Node.js «finity», специально разработанной для сжатия файлов HTML, CSS и JavaScript. Это решение привело к уменьшению размера текстового файла более чем на 40%. Кроме того, у minify появилось дополнительное преимущество в виде обфускации, что затрудняло чтение необработанного кода и повысило безопасность.

Давайте углубимся в тему хостинга. Традиционно система управления контентом (CMS) работает через сервер приложений, который обрабатывает HTML-запрос пользователя. Она интерпретирует запрос страницы с URL-адреса, находит соответствующие ресурсы в базе данных, извлекает запись из базы данных (возможно, вместе с другими), обрабатывает информацию для сборки страницы и, наконец, передает ее конечному пользователю в виде плоского HTML-документа. Это описание в основном относится к первоначальному HTML-запросу при посещении пользователем нового веб-сайта, хотя мне известны AJAX и другие подобные технологии.

Однако эта традиционная модель имеет определенные недостатки в контексте нового мира Lighthouse. Во-первых, обмен данными между сервером приложений и сервером баз данных, а также компиляция страниц приводят к задержкам. Во-вторых, в самом простом виде сервер приложений и сервер баз данных физически доступны только в одном месте. Такая настройка превосходна, если вы находитесь в том же здании или городе, но значительно менее эффективна, если вы пытаетесь зайти на сайт с другого конца света. Например, средняя задержка пинга между Австралией и Великобританией составляет примерно 250 миллисекунд.

Наше решение этих проблем заключается в использовании AWS S3 для размещения статических файлов, созданных вышеупомянутым скриптом публикации, и AWS CloudFront для глобального распространения контента. На момент написания этой статьи AWS CloudFront распространял контент в более чем 90 городах в 47 странах. Для пользователя из Мельбурна (Австралия), заходящего на британский веб-сайт, AWS CloudFront сократил задержку пинга с 250 миллисекунд до 13 миллисекунд (это разница во времени между Мельбурном и периферийными серверами AWS в Сиднее).

Теперь мы подошли к компоненту Progressive Web Application (PWA) в тесте Lighthouse, которому я раньше не уделял особого внимания. Для тех, кто не знаком, в PWA входит сервисный работник JavaScript, который управляет веб-сайтом как веб-приложением. Если это немного сложно, подумайте об этом так: по сути, это инструмент автоматической загрузки и кэширования. Когда пользователь посещает ваш сайт, цель состоит в том, чтобы сделать последующие запросы максимально быстрыми и удобными. Сервисный работник PWA позволяет вам уже загрузить следующие ресурсы на локальный компьютер пользователя, что устраняет необходимость в повторном запросе GET через Интернет.

На момент написания этой статьи веб-сайт Nexoid был относительно небольшим и содержал всего 19 страниц. Однако эти 19 страниц переведены на 11 разных языков, что составляет в общей сложности 209 страниц. Сначала я пытался загрузить все ресурсы сервисному работнику, размер которых составлял около 5 МБ. Этот размер был слишком велик для первоначальной загрузки, и компания Lighthouse оштрафовала меня за это. Я решил загружать только англоязычные файлы JSON со всеми необходимыми CSS, HTML и JavaScript для отображения каждой страницы.

Окончательная структура выглядит следующим образом: в корзине S3 хранятся скомпилированные HTML-файлы с именами без расширения.html. Например, www.nexoid.com/en представляет собой HTML-код английской домашней страницы, www.nexoid.com/de — HTML-код немецкой домашней страницы, а www.nexoid.com/en/platform — HTML английской платформы и так далее. Кроме того, существуют файлы JSON, содержащие части тела и головы, которые изменяются при переходе между страницами, например https://www.nexoid.com/en.json, https://www.nexoid.com/de.json, https://www.nexoid.com/en/platform.json и другие.

В заключение, понимание Lighthouse представляло собой серьезную проблему. Я скептически отношусь к тому, что традиционные готовые продукты CMS могут эффективно решить эту задачу. Опираясь на свой опыт работы с такими платформами, как WordPress и Drupal, мне трудно поверить, что их можно оптимизировать для достижения идеальных результатов Lighthouse. В целом, я считаю, что усилия того стоят, и Google вполне оправданно уделяет больше внимания производительности. Однако этот сдвиг был и будет оставаться серьезной проблемой для веб-дизайнеров и агентств.

Если вы хотите узнать больше о Lighthouse или обсудить продукты и услуги Nexoid, пожалуйста, свяжитесь с нами. Вы можете связаться с нами через LinkedIn или на странице «Свяжитесь с нами» на нашем веб-сайте.