Весь сайт без перезагрузки на jquery

По идее, сделать можно всё.

Но стоит отметить, что jQuery - это всего лишь весьма удобная библиотека для взаимодействия с DOM. Она вообще никак не помогает в реализации SPA. Ну ладно, есть метод load, но он всего лишь подменяет содержимое элемента на то, что пришло в ответе на ajax-запрос. Если же передаются данные, а не html-разметка, то всё построентие страницы должно быть на клиенте и jQuery для этого бесполезна (хотя можно подключить какой-нибудь шаблонизатор).

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

Ещё один вариант - оставить всю логику на сервере и просто подменять разметку куска страницы. Это проще и это легко реализуемо на jQuery. Из плюсов - немного другое восприятие пользователем, можно сделать какую-то анимацию перехода. Из минусов - объём передаваемых данных практически не меняется. Потенциальные грабли - если необходимо динамическое подключение разных скриптов на разных страницах, то могут получиться конфликты между различными скриптами, которые вообще не должны были подключаться одновременно, либо начали выполняться в неправильном порядке. К тому же событие ready уже произошло, и его обработчики будут вызываться немедленно.

Если нужно именно нормальное SPA в production-целях, рекомендую взять что-нибудь непосредственно предназначенное для разработки SPA, а не jQuery. С современными фреймвёрками jQuery используется крайне редко, поскольку они сами покрывают основное её использование, а в неосновном и сама jQuery обычно не помогает.

У меня были проблеми с:

1. типами данных.
2. видимостью переменных
3. разной скоростью вызова функций

Заморачиваться стоит, но также стоит помнить, что для таких дел нужен хороший сервер.

Определенно стоит сделать, если позволяет время.

JQuery

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

Более высокие требования к качеству кода

Если переводите проект на AJAX-загрузку, то имейте ввиду, что потребуется более тщательно проводить разработку и тестирование. Особенно что касается динамически подключаемых файлов с js-скриптами, глобальными переменными, потребуются собственные обработчики событий (например, вместо DOMContentLoaded в аналогичном случае нужно будет вызывать собственный код после получения ajax-данных).

Производительность и нагрузка

Если нормально напишите код, то в плане нагрузки на сервер не сильно все поменяется. Просто те запросы, которые шли синхронно будут идти в асинхронном режиме. Плюс немного уменьшится объем передаваемых данных (серверу уже будет не нужно каждый раз отправлять всю страницу целиком).

Быстрая стартовая загрузка страницы

Также имейте ввиду, если хотите сделать быструю первоначальную загрузку страницы (например, как в vk, где все работает без загрузки пустого фрейма и последующего ajax-запроса/вставки данных, а сразу все выводится с одного запроса к серверу), то придется по сути делать 2 версии страницы - одну, которая сразу выдается в ответе сервера, а вторая через ajax-загрузку данных.

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

Сделать конечно можно любым способом, но стоит подумать о целесообразности. Задача стандартная и правильным решением будет разделение приложения на фронтенд и бэкенд. Т.е для бэкенда пишем REST приложение на серверном языке, а для фронта используйте JS фреймворк: React, Angular и т.д.

Конечно можно городить свой велосипед:

1. Разрабатывать схему запросов ajax с помощью jquery - и если все получится, то у Вас выйдет свой костыльный js-фреймворк.
2. В бэкенд врейворках есть инструменты для реализации обмена данными ajax с использованием pushHistory. Это тоже не самый лучший вариант, возможности этих инструментов ограничены, их стоит использовать для локальных задач.