В чем целесообразность использования SPA, если контент в них не индексируется?
Не могу какой смысл использовать различные клиентские фреймворки, которые полностью отвечают за вывод контента (ангуляр, реакт), если он не индексируется поисковиками и вообще не SEO дружелюбный, получается сайт в таком случае бесполезен, если его никто не найдёт? Например, тот же конструктор сайтов wix.com, контент генерируется на реакте, и в итоге, исходный сайт такого сайта, то увидем что никакой информации нет, весь контент загружается динамически.
Наткнулся на термин "изоморфный js", т.е. это как раз-таки решает проблему с контентом, что поисковики будут видеть такой сайт? Т.е. мне как бы хочется попробовать что-то новое, но смысл делать сайт, информация которого будет недоступна пользователям через поисковики, не лучше тогда "по старинке" рендерить всё на сервере, в чем проявляются преимущества SPA в таком случае?
Изоморфный фреймворк - это как раз то что нужно для индексации. Благодаря рендерингу страниц на стороне сервера, поисковики увидят все что нужно. Кроме того, современные поисковики вполне себе учатся понимать SPA-сайты, вот, например тот же Яндекс рассказывает как это сделать. Google предпочитает Progressive enhancement
Зачем вообще нужно? Затем чтобы сайт работал как приложение (точно так же, как на смартфонах и прочих девайсах). В ситуациях, когда ваш продукт это не только веб-сайт, но еще и куча других устройств, это позволит вам сильно упростить серверную часть. 1 сервер и Rest API для всех, вместо того, чтобы делать отдельно сайт со своим собственным сервером, и отдельно инфраструктуру под мобильные приложения.
ASP чаще всего и используются в приложениях, которым не нужно индексировать контент, например:
Gmail - он реализован как SPA, согласны, что содержимое мыльников никто искать не будет, так?
Admin Panel - согласны что индексировать админ панель незачем?
REST api - визуальный интерфейс, согласны, что индексация страниц не нужна?
Какой-то закрытый ресурс компании, тоже не индексируется.
В чем плюс использования. SPA приложение на том же Angular сделать быстрее и проще, чем расширять большой и громоздкий функционал на сервере через PHP, Java, C#.
Во вторых это работа с разными устройствами и под разными устройствами это не только моб. планшеты и компы, а и инженерные программные модули(покрайней мере так пишут в вики).
Значительно меньше нагрузка на серв и больше на клиент т.к. грузит оно все разом и чаще всего работает асинхронно. Обновляя исключительно контент, а не все страницы целиком.
Сделать SPA приложение на Angular намного сложнее, чем использовать PHP сервере. Не говоря о том, что от сервера вы всё равно не избавитесь. В итоге часть изменений на сервере потянут за собой изменения на клиенте и наоборот.
Владимир Козловский: на чем проще и сложнее, сугубо индивидуальная тема. Если тебя окружают PHPисты и ты один в JS/C# смог, то да, сложнее. Если ситуация противоположная и отдел чаще работает с SPA, то они сделают быстрее, не говоря уже о скилах коллег. Можно сделать одинаково плохо как на Angular так и на Php. Есть корпоративные наработки и привычки ведения разработки ПО. И я не сравниваю языки, если что. Они используются по разному и диапазон их возможностей разный и завист от проекта - это ключевое.
spotifi: я всего-лишь говорю о том что штуки типа запрос фрагментов страниц (то что вы предложили погуглить) является устаревшей фичей поисковиков, и не рекомендуется к использованию.
Метод с Хешбенгом реализован много раз, полно примеров. И до сих пор работает хорошо.
Пререндер, который вы рекомендуете - поисковики не видят что ты делаешь внутри сайта.
Если вы действительно что то можете сказать по делу - как именно сделать одностраничники видимыми поисковикам - я с удовольствием тоже почитаю.
Q: My site currently follows your recommendation and supports _escaped_fragment_. Would my site stop getting indexed now that you've deprecated your recommendation? A: No, the site would still be indexed. In general, however, we recommend you implement industry best practices when you're making the next update for your site. Instead of the _escaped_fragment_ URLs, we'll generally crawl, render, and index the #! URLs.
Гугль просто-напросто расширил понятие Хешбенга на все прямые ссылки.
spotifi: Прямо в вашей цитате сказано "лучше не юзать _escaped_fragment_". А hasbang нужен был испольчительно для этого ну и как fallback для history api, который не нужен уже довольно давно.
Так что повторюсь - используем history api, никаких hash bang.
spotifi: все же уточню почему я категорически против hashbang.
Плюсы hashbang:
- легко организовывать маршрутизацию на сервере и на клиенте, одно отдельно - другое отдельно. Идеально для сайтов, где "маршрутизация" нужна для примитивных вещей.
- работает во всех браузерах где работает onHashChange
Минусы hashbang
- Плохо масштабируется - приходится выдумывать кастыли для аналога query string, например если вы пилите каталог товаров, или у вас более сложная система маршрутизации.
- Нельзя организовать серверный пререндеринг - поскольку якори не попадают в http запрос, мы никак не можем организовать server-side пререндеринг. А он нужен не только для поисковиков, но и что бы пользователю не нужно было ждать лишние секунды пока загрузится приложение, отработает роутинг, пойдут запросы на сервер... А необходимость в server-side пререндеринге будет только увеличиваться с распространением SPA
Во-первых, если это веб-приложение (скажем, онлайн видео-редактор), то нет смысла индексировать ничего, кроме лендинга на его главной страницы.
Во-вторых, с чего вы взяли, что современные поисковые боты работают только с HTTP и HTML и не умеют выполнять JS?
Особенно бот от Гугла, который вообще-то разработал свой браузер, едва ли не лучший в мире, и "движок" V8, это вас тоже не смущает?
Проведите эксперимент, сделайте простейшую страницу с AJAX, добавьте ссылку в поисковики и посмотрите, сравните с версией без JS.
В-третьих, если браузер не поддерживает JS, то можно отдавать клиенту версию без JS.
