Публикация SPA

Хочу поделиться опытом публикации SPA, где под публикацией подразумеваю более-менее готовый сайт, который нужно разместить на хостинге. Расскажу о базовых моментах, связанных с настройкой сервера, добавлении в поисковые системы и немного про то, как сделать сайт дружелюбнее с поисковиками.

В целом есть несколько способов, чтобы опубликовать сайт. Есть как более простые способы, например, хостинг с предустановленным ПО, но менее гибкие как раз из-за ограниченного набора приложений, так и способы, где нужно больше действий для настройки сервера, например, VPS/VDS или выделенный физический сервер а не виртуальный.

При выборе сервера также нельзя забывать, что потребуется операционная система, и тут можно сэкономить, выбрав одну из бесплатных ОС семейства Unix, конечно, это может подойти не всем, Windows, как мне кажется, пока еще более привычная операционка.

Перед тем как арендовать что-либо, подумайте, что подходит для вас лучше всего. В моем случае, кроме самого SPA, мне нужно запустить несколько приложений на сервере, хранить файлы и иметь возможность поставить любое freeware ПО, поэтому был арендован один небольшой VPS c Ubuntu 18.04. Еще, конечно, потому что в ней есть systemctl, очень похожа на Windows Services — можно добавлять свои приложения как сервисы.

В первую очередь, если у вас уже есть доменное имя, сопоставьте его с IP-адресом VPS в настройках DNS, потому что Whois будет обновлятся примерно 24 часа. Далее нужен клиент для доступа к серверу, выбрал классический Putty.

Устанавливаем соединение с сервером и авторизуемся. Сразу же создаем отдельную учетку с правами администратора, и это правда очень важно на любой ОС, потратьте немного времени чтобы ее создать.

После можно сменить пользователя командой su <username> или попробуйте перезайти на сервер под новым пользователем. Когда залогинитесь под новой учетной записью, нужно сначала установить Firewall - ufw и настроить его. Более подробно про настройку можно найти по ссылке ниже.

С помощью этих команд устанавливаем Firewall, открываем порты: 22, 80, 443 для доступа извне, и включаем его.

И перед тем как делать что-то дальше, появился вопрос, как перенести build приложения (сам сайт) на удаленный сервер. Есть несколько вариантов: через утилиту pscp поставляемую с putty, то есть через SSH-соединение, расшарить директорию на своей машине или на удаленной. Мне приглянулся вариант с созданием «общей» папки на VPS. Для этого можно установить приложение Samba. Опять же, более подробно почитайте тут:

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

И добавляем пользователя в базу Samba.

Открываем файл конфигурации.

В конец файла конфигурации Samba копируем следующие строки, где <samba user> — это пользователь, которого вы создали специально для работы с этой расшаренной папкой:

И перезапускаем приложение.

После, в зависимости от вашей ОС, подключаемся к общей папке. В Windows открываем проводник и прописываем в адресной строке:

Вводим логин и пароль пользователя, и теперь можно скопировать сайт на сервер в расшаренную папку. А на самом сервере переносим приложение в стандартную директорию для сайтов.

Теперь можно установить прокси сервер, к примеру Nginx. С помощью него будем отдавать сайт по указанному адресу.

Можно использовать файл default, изменив конфигурацию по умолчанию, но лучше создать отдельный файл конфигурации для сайта с его именем.

И скопировать настройки, написанные ниже, заменив <domain name> на свой домен.

В настройках три секции server.

Первая для того, чтобы перенаправить все запросы с 80 порта на 443. Вторая секция, чтобы перенаправить все запросы с 443 порта с www в начале на сокращенное доменное имя. В последней секции server все настройки соединения с несколькими location.

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

Остальные два локейшена: в первом записано местоположения сайта, и изначально вместо try_files $uri @prerenderбыл try_files $uri $uri/ /index.html, во втором переадресация на API-сервис, поэтому и соответствующие условия можно прочитать, как ~ ^/api — содержащее /api в адресной строке, и ~ ^/(?!(api)) — не содержащее /api в адресной строке. Да, помимо сайта есть ещё Web API, но здесь я не буду о нем говорить.

Важным в этих настройках является активация сжатия gzip, чтобы весь контент до пользователя доставлялся быстрее, ну и в Chrome Audits получить более высокий рейтинг. 🙃

Для активации всех настроек, создаем ссылку для Nginx на этот файл.

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

В завершение настройки перезапускаем Nginx.

При условии того, что все DNS обновились, можно заглянуть на сайт по доменному имени и убедиться, что все работает. Следующим шагом, хотя его лучше проделать заранее, но я сделал уже потом, воспользоваться средствами Chrome браузера для проверки работы сайта утилитой Audits. Открываем Chrome в режиме инкогнито (чтобы не было влияния расширений браузера и всего остального), нажимаем F12 и выбираем Audits.

На этой вкладке генерируем отчет для выбранного устройства, мобильного или настольного ПК. В отчете можно будет посмотреть ключевые параметры, зависящие от вас, которые вы могли бы изменить в лучшую сторону. Например, как раз размер передаваемых данных (не забыли ли вы включить сжатие на сервере gzip) или, допустим, объемные изображения.

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

Так как можно сжимать PNG с прозрачным задним слоем, но, конечно, существует и ограничения — без платного аккаунта максимальный размер файла в 5 МБ. Суммарно позволило снизить вес картинок на ~50–70%.

Еще из отчета понял, что мои шрифты могут не отображаться какое-то время при загрузке странице, так как не использовал функцию swap, чтобы если шрифт не успел загрузиться, был отображен шрифт системы по умолчанию. В общем, полезная штука, но по поводу Yandex.Metrica/Google Analytics, которые все время попадают в отчет, лучше не заморачиваться.

Вообще я использовал только 3 поисковые консоли (вебмастеры): это Google, Bing и Yandex. Чтобы видеть информацию по сайту в различных поисковиках, нужно создать для каждого поисковика свой аккаунт или по крайней мере зарегистрировать только один в Google, тем самым снизив число аккаунтов.

В них можно привязать сайт к аккаунту, добавив meta тег с ключом, или добавив XML-файл в корневой каталог (public) сайта, или же можно добавить ключ в файл конфигурации DNS.

Перед тем как привязывать сайт к аккаунту, я решил немного подождать и посмотреть, будет ли проиндексирован сайт в этих поисковиках. В общем, только Google проиндексировал все страницы SPA и нашел sitemap.xml который указан в robots.txt.

Bing добавил в индекс только главную страницу. Индексация произошла спустя примерно 1 неделю для Google, чуть больше недели для Bing после сопоставления доменного имени и IP-адреса. Yandex так и не проиндексировал сайт спустя две недели, может, было недостаточно времени.

Следующим этапом привязал сайт и добавил sitemap на обход. И через 3–4 дня я осознал, что только Google может обходить и индексировать SPA со всеми страницами. Yandex пометил все страницы, кроме основной, как дубликаты и не добавил в поисковую базу.

Почитав немного про эту проблему, понял, что лучше делать пререндеринг страниц локально или же с помощью какого-то сервиса. Ну и так как арендованная VPS не с самой лучшей конфигураций, воспользовался сервисом от prerender.io.

Необходимым и достаточным в этом случае оказалось: создание бесплатного аккаунта, чтобы получить токен, добавление условия маршрутизации для Nginx и добавление необходимых URL для кэширования на сервисе. Сама конфигурация любезно предоставлена в документации и выложена на Github.

В ней прописаны все известные user agents, то есть боты, а также файлы, которые будут запрошены с вашего сервера (location @prerender). При использовании бесплатного аккаунта есть ограничение в количестве кэшируемых страниц, равное 250. В целом для маленьких сайтов, я думаю, подходит.

Да, и еще важный момент, необходимо вернуть правильный статус-код страницы, если ее не существует. Для этого в приложении должна быть реализована отдельная страница «404», при рендеринге которой должен добавляться тег

в заголовок страницы. Таким образом prerender.io вернет правильный статус код для робота.

После проделанных изменений запустил все страницы на пере обход в «Яндекс.Вебмастера», правда, так и не понял до конца, есть ли в этом смысл, потому что переобходятся они почти сразу, а вот обновляются спустя примерно 5 дней.

Помимо этой проблемы, была еще проблема с favicon, точнее с тем, чтобы она не отображалась при выдаче в поисковиках. В «Яндексе» и Google разное описание того, какие должны быть характеристики у иконки, ну да ладно. Воспользовался еще одним сервисом, чтобы сгенерировать множество разных иконок, так же сервис генерирует все нужный теги с атрибутами для вставки на сайт.

Обновил и подумал, что теперь точно должно все заработать, но эта была неудачная попытка. Тогда решил, что просто посмотрю теги сайта, у которого точно есть иконка как в «Яндексе», так и в Google, выбрал YouTube (можно конечно и у vc.ru взять, у них хотя бы паук в разметке есть 🕷). Немного изменил свои теги:

И спустя пару дней иконка наконец появилась в результатах выдачи поисковиков.

P.S. В конце захотел посмотреть, обходит ли Mail.ru сайты, спойлер — нет. И создавать аккаунт нужно именно мейловский.