Сайт спроектирован таким образом, чтобы синхронный запрос (типа /controller/action?param1=value) не отличался от такого же асинхронного. Т.е. если выключить pjax на всём сайте - сайт должен работать, как работал. Ссылки не меняются и послушно отдают контент, загружая заново всю страницу со всем леяутом.
К примеру, пользователь кликает на главное меню - перегружаю блок меню и основной блок контента. Ссылки меню - обычные, как будто сайт асинхронный, но PJAX добавляет параметр _pjax=#some-block, сервер по этому ориентируется, нужно отдать только нужный блок, или весь сайт.
Настроил всё так, чтоб работало с ЧПУ. Настроил так, чтобы можно было указать зависимости блоков и перегружать сразу несколько (к примеру, при отправке комментария обновить форму, список комментов и блок оповещений).
Система работает в разы быстрее и оптимизированней, чем при синхронных запросах. По идее сайт может нормально индексироваться, т.к. ссылки такие, как у обычного синхронного сайта/блога. Но это только предположение.
Собственно в этом и вопрос. Правильно ли я предполагаю, что за счёт такого подхода получится сделать не только хороший, быстрый и удобный сайт для пользователя, но и не просесть в поисковых системах?
Нужно ли перегружать с асинхронным запросом мета-теги? Или боты будут ходить синхронно по ссылкам?
Будет ли поисковик воспринимать ссылки, которые в href="..." (они работают в синхронном режиме, по прямому запросу. В этом и фишка).
Или поисковик будет копать глубже - отследит события, повешенные на PJAX блок и воспримет ссылку не как /sefurl-ssilka, а как /sefurl-ssilka?_pjax=#some-block ?
Просто если поисковик не поймёт моих стараний, то тогда имеет смысл определиться - делать синхронный сайт и не морочить голову, или забить вообще на поисковик и сделать SPA. В общем то и то и другое уже делал и как то не интересно, хотелось бы поэкспериментировать с новым подходом, но не в ущерб своему проекту.
Очень мало инфы, все пишут что прикольная технология этот PJAX, но у всех кто пробует - куча проблем из-за него. И, очевидно, на каком то этапе забивают. Но это не решение проблемы. Кто работал с таким? Или может поделиться источниками инфы? Или может подсказать специфику работы поисковых движков в этом плане?
А че гадать зарегистриуйтесь на google search console, там есть пункт просмотреть страницу как google bot введите туда свою pjax ссылку и посмотрите что выйдет (там будет два окна как видит пользователь и как видит бот)
Но мне кажется может возникнуть спорная ситуация... даже если бот без js перейдет по ссылке а пользователь останется на старой но сновым контентом, тогда могут не совпасть хедер разные метатеги какие нибудь изображения и гугл может посчитать что вы пытаетесь обмануть бота и отдаете разный контент пользователю и боту а в не редких случаях это бан. Правда проблема аяксовых сайтов уже лет 10 стоит может гугл относится к этому уже лояльней
pushState меня обнадёживает в плане описанной проблемы. Т.е. ссылку то мы поменяем. А вот что делать с метатегами - вопрос непонятный. Есть идеи? search console ответит на этот вопрос? Кстати, спасибо за совет.
А что прикольного? Отдавать куски контента - это как минимум заморочки в будущем, когда решите дизайн поменять. Верстальщик у вас по коду будет лазать? Хотя это можно предусмотреть на ранней стадии, наплодив файлов в шаблонизаторе (ага, и не забывая их поддерживать). На фронте тоже потенциальные заморочки с отслеживанием событий, вдруг надо нажатие на кнопочки отслеживать, которые находятся внутри загруженного блока? Конструкции вида $('body').on('click', 'some-element-inside-loaded-block') работают медленнее, чем $('some-element').on('click'), плюс, я понятия не имею, как вы сможете в этом случае прикрутить адекватный фреймворк и заставить его работать. А если у вас плагин вида datatables в загружаемом куске кода нужно будет активировать или нечто, что будет сжирать память, если его не выгружать перед удалением html блоков? Вы в конечном итоге придете к тому, что кроме html вам придется еще и js отдавать с тем же pjax и на этом моменте поймете, что дико встряли. Хотя справедливости ради замечу, что ssr для js-фреймворков я на практике не использовал пока (нет надобности, так как фреймворки в моих задачах отвечали о сих пор за в принципе неиндексируемые страницы типа личных кабинетов) и там тоже не в два клика все делается, но из этих двух вариантов я бы предпочел про ssr почитать, чем внедрять pjax.
Разве pjax не попадает под ssr? Server Side Rendering имеете ввиду? Именно на сервере у меня и происходит рендеринг блока с учотом состояния. Или сср - обязательно рендеринг всего сайта на сервере? В любом случае, почитаю по теме, спасибо.
Подскажите, что делать с обновлением метатегов при ajax\pjax запросе? Есть опыт решения такой проблемы?
olijen, технически под определение SSR сейчас относят реализацию на сервере верстки, которая по-умолчанию делается js-фреймворками на клиенте, а не верстку, изначально сделанную на php (хотя она является ssr по-умолчанию).
В рамках pjax ваша задача с метатегами не решается. вам нужно получать от сервера не кусок верстки, а упорядоченные данные. То есть объект json вида
{
metatags:[...],
content:[...]
}
и обрабатывать каждый блок этого объекта на клиенте. В content к примеру лежит необходимая вам верстка, если вы так сильно не хотите генерировать ее на клиенте, а метатеги в массиве metatags. Если в ответе присутствует metatags, правите их с помощью jquery примерно так: jQuery("meta[name='keywords']").attr('content','тут кейворды'); но это вы, думаю, сами видели в поиске.
olijen, я тут перечитал свой ответ и хотел бы отредактировать его, а то наехать на pjax наехал, а сути послания не передал. Используйте вместо pjax отдачу контента в виде json, с ним куда легче работать на клиенте, также вместо дополнительного get параметра можно использовать заголовок content-type, чтобы сервер мог определить, отдавать страницу целиком или только кусок (это вопрос удобства вашего на самом деле, да и в будущем если потребуется фильтровать входящие get параметры, не нужно будет держать в голове, что этот может с чем-то совпасть, с каким-то полем в базе, например, по которому вы ищете). Это облегчит вам как будущие возможные доработки (та же работа с метаегами или обновление данных не ломая скрипты на фронте), так и не потребует от вас содержать две копии верстки (одна в pjax, другая в самих страницах).
Если сайт нацелен и на пользователей и на seo, то именно таким он и должен быть - быстрым для пользователей, доступным для поисковых систем.
Реализовал подобную систему и считаю это единственная возможность не создавать тормоза у пользователя из-за требований seo-специалистов.
Но нужно понимать, что поисковые системы не стоят на месте и у них уже должен быть робот который умеет js. Поэтому главное правило, что в пределах одного урла и боту и браузеру с js должен отдаваться абсолютно одинаковый контент. Тогда проблем быть не должно.
Особенности, которые были выработаны в ходе разработки:
1. Перезагружать совсем уж мелкими кусками не стоит, т.к. это добавляет нагрузку на клиент в виде сложной логики. Чем проще js на клиенте тем лучше. В итоге от мелких кусков пришли к 2м кускам: Статическая часть и динамическая часть.
2. Html формировать на сервере. Самый удобный вариант для клиента.
3. Шаблон одной и той же части должен быть один как для бота так и для браузера с js. Легче поддерживать. А благодаря пункту 2 это становится проще простого.
У поисковиков есть range brain, который больше людей понимает. Но это не значит, что поверх него не используются некоторые фильтры, которые... Ну, всякое могут. Я просто не осведомлён в деталях.
Похвастайтесь системой, которую Вы реализовали. Буду признателен.
Классная. Вот только это не значит, что она предназначена для Вашей затеи. Ее задача, просто и однотипно грузить блоки. Это мега удобно при разработке админки например или отправке формы ajax-ом. Делать весь сайт (front) на нем не самая лучшая затея. Есть смысл взять какой-то js framework. Однако и сильно серьезных проблем Вы не получите, с точки зрения seo. Ведь если Вы все правильно сделали, то get запросы по ссылкам должны возвращать валидный html, а что еще боту надо для счастья?
Наверное pjax это первое решение такого плана, которое Вы встретили. Поэтому советую обратить внимание на другие js технологии. Так как pjax это скорее хак, чем технология.
Спасибо за Ваш ответ и участие, но мне в нём не хватило ... почти всего. Не лучшая идея - почему? Конкретно почему? Есть доказательства? Или не пробовал никто? Может и не лучшая, а вдруг лучшая? =) Первое решение "такого" плана - какого? Из фронта писал на backbone\marionette, view.js, angular1 немного, angular2 - много, react - немного, свой вело-фреймворк создавал дважды. (ключевое слово - вело). Ну а так, по мелочи - пожалуй почти на всех популярных решениях писал немного. Так что не знаю, вроде бы не первое решение такого плана, если речь о ajax и SPA.
Каждая технология создается с определенной целью и удобна для ограниченного спектра решений. Попытки сделать универсальное решение - порождают плохие решения. Попытки натянуть нишевое решение на все что угодно - приводят к плохому продукту. Сложно поддерживать, сложно разрабатывать и т.д.
Звучит, как какая-то реклама. "У тебя проблемы с самооценкой? Тебя не уважают поисковики? Боишься параметра?- Избавься от него раз и навсегда! С нашим новым средством profesor08 возможно всё! Через GET загружай все, через POST только часть. Скажи НЕТ страху параметров!"
А вообще, я не понял - к чему это. Я как раз решаю проблему, как через GET загружать часть. Как то переборю страх.
Ну раз столько времени занимает этот примитивный вопрос, то ты похоже реально чего-то недопонимаешь. Попробую разжевать. Оставляешь все ссылки обычными, без доп параметров. При клике на ссылку, скриптом загружаешь данные по этой ссылке через POST. Тем самым на сервере смотришь, если через пост, то отдаешь нужную часть контента. Если через GET, то отдаешь всю страницу, как если бы по ссылке перешел поисковик или пользователь вставил ссылку в строку браузера.
Да понял я, что ты имеешь ввиду. НЕ понял - как это связано с моим вопросом. Как это поможет? Ну, загрузил я через POST. Это хоть на один из моих вопросов отвечает? В любом случае, спасибо тебе, что участвуешь. Это без сарказма.
olijen, боты будут ходить по ссылкам по GET и получать контент всей страницы, со всеми тегами, заголовками и мета-тегами. Проблема с ботами решена. В результате у тебя быстрый SPA который дружит с поисковиками. Все счастливы.
А откуда ты это знаешь, что боты так будут ходить? В смысле, может так оно и есть, но мне очень помогут доказательства. Что мешает ботам отследить onclick и сделать POST? НА сколько я знаю, они так умеют, по крайней мере у гугла JS хавают. А если не хавают - то тогда и моя версия с pjax будет работать, т.к. синхронно отдаётся такой контент, как при прямом GET запросе ссылки, а при onclick добавляется параметр _pjax и по той же ссылки уже только нужный контент грузится. За идею отличать pjax запрос через метод - спасибо. Но я вот подумал... Если только ради отличия типа запроса - нет смысла, т.к. можно проверять на XHR. Смысл имеется только с условием, что боты принципиально игнорят POST. Хотя, коментарии же боты не отправляют... Может ты и прав тогда. Но в любом случае получить бы пруфы, что боты нормально отнесутся к тому, что я им один метод сую, а юзеру - другой.
Ну, я не люблю вещи из серии "просто работает". Оверхед или нет - это уже мой головняк. Я готов переплатить\переработать, но разобраться. Кроме того, следующему человеку, кто будет копать в эту сторону, я смогу дать ясный ответ.
profesor08, вам вы сперва ознакомиться с общепринятыми практиками, а потом отвечать. Post запросы принято использовать для изменения данных на сервере, а get - для их получения, а не для того, чтобы изголяться вкривь и вкось. Сами говнокодите, так хоть других не учите тому же самому.
Дмитрий Евграфович, тогда почему при 99.99% post запросах, возвращаются какие-то данные? Выходит все кто так делают - говнокодеры. И api сервисы, которые используют подобный подход, включая некоторые от гугла, амазон и пайпал - тоже говнокодеры писали.
profesor08,
- тогда почему при 99.99% post запросах, возвращаются какие-то данные?
А в чем проблема? При создании новой сущности апи часто возвращает ее в ответе.
- И api сервисы, которые используют подобный подход, включая некоторые от гугла, амазон и пайпал - тоже говнокодеры писали.
Какие конкретно сервисы вы имеете в виду? Можете кинуть ссылки на конкретные методы в документации? А то сейчас окажется, что вы про поиск по картинке говорите или иной метод, подразумевающий принятие большого куска данных, которую get запросом передать невозможно. Либо просто протоколы, которые к html не имеют отношения.
- Более того, на get и post свет клином не сошелся
В html формах сошёлся.
Дмитрий Евграфович, более того, там используются дополнительные http заголовки, например для авторизации, идентификации и тд. А всякие платежные системы предоставляют выбор между типами запросов. Как говорится, добро пожаловать в реальность.
profesor08, вас вообще несет не в ту степь, я говорю, что вы нарушаете общепринятые rest принципы без видимой причины и изобретаете какие-то велосипеды, а вы в ответ ссылаетесь на сферические гугли в вакууме. Я прошу вас ссылки привести как примеры ваших слов, вы в ответ про платежные системы и авторизацию. Вы вообще читали про rest? Использовали хоть один фреймворк современный с rest апи? Я бы понял, если задача стояла нетривиальная какая-то, где rest неуместен но топикстартер не пишет интеграцию с банковскими системами, не собирается использовать soapы и xmlы, не спрашивает про авторизации, ему только данные со своего сервера на страницу вывести, зачем тут велосипеды, которые не имеют отношения к вопросу топикстартера, а в перспективе (хотя почему в перспективе, прямо во время реализации) ведут к говнокоду, если уже 10-15 лет как придумано элегантное решение?
Средний
