Bei allem Mehrwert, den Ajax dem Benutzer einer Webanwendung bieten kann, sollen jedoch die Nachteile nicht verschwiegen werden. Folgende Probleme treten im Zusammenhang mit Ajax auf:

• Die Grenzen zwischen URL-Adressen und Seitenzuständen verschwimmen:
  Eine Webseite zeichnet sich dadurch aus, dass sie eine feste URL-Adresse hat. Wenn eine Webseite intensiv mit Ajax arbeitet, kann es jedoch passieren, dass der Benutzer lange Zeit gar keine neue Seite mit eigener URL-Adresse nachfordert. Stattdessen setzt ihm JavaScript neue Inhalte und Seitenzustände direkt in den bestehenden HTML-Code ein. Da so erzeugte Inhalte und Seitenzustände aber keine eigene URL-Adresse haben, lassen sie sich nicht als Bookmark/Favorit abspreichern, und andere Webseiten können keine direkten Links („Deeplinks“) auf solche Inhalte setzen. Die Vor- und Zurück-Funktion des Browsers, die das Bewegen in der Historie besuchter Seiten ermöglicht, funktioniert ebenfalls nicht mehr wie erwartet. Denn diese Funktion springt immer nur zum Anfangszustand einer Seite. Auch Suchmaschinen-Robots werden in aller Regel nur den Anfangszustand einer Seite indexieren und weitere, über Ajax ermittelbare Seiteninhalte ignorieren.

• Ajax ist nur mit aktiviertem JavaScript verfügbar:
  Per Voreinstellung ist JavaScript in allen modernen Browsern aktiviert. Weil JavaScript jedoch nach dem Boom der Anfangsjahre etwas in Verruf geraten war, nutzten viele Anwender die Möglichkeit, JavaScript zu deaktivieren. Viele nervige Popup-Fenster, hinderliche Effekten und sonstiges Blendwerk ließen sich auf diese Weise unterdrücken. Wer das auch heute noch tut, wird von Inhalten, die nur über Ajax ermittelt werden, erst gar nichts sehen. Gleiches gilt für Anwender, die aus technischen oder körperlichen Gründen Browser-Lösungen in reinen Textumgebungen verwenden. Solche Browser unterstützen in aller Regel auch kein JavaScript. Inhalte, die nur über Ajax ermittelbar sind, bleiben also unzugänglich.

• Die Server-Belastung kann sehr hoch werden:
  Wenn Anwenderaktionen wie Mausklicks oder gar Mouseover-Ereignisse jedesmal eine HTTP-Kommunikation auslösen, entsteht viel zusätzliche HTTP-Kommunikation zwischen Client und Server. Der Client, also der Browser des Anwenders, wird dadurch nicht nennenswert belastet, um so mehr jedoch der Webserver, der möglicherweise für viele gleichzeitige Benutzer die Ajax-bedingte HTTP-Kommunikation abwickeln muss. Eine Ajax-intensive Webanwendung, die von vielen Besuchern gleichzeitig genutzt wird, kann einen Webserver durchaus in die Knie zwingen. Das gilt insbesondere für Anwendungen, bei denen eigentlich ein Server-Push, also eine vom Server gestartete Kommunikation sinnvoll wäre, wie etwa bei einem Chat. Da es im HTTP-Protokoll jedoch keinen Server-Push gibt, muss der Client, also JavaScript, in kurzen Zeitintervallen immer wieder beim Server nachfragen.

• Wartezeit bis HTTP-Antwort kann Anwendungen lahm erscheinen lassen:
  Wenn ein Anwender in seinem Browser eine neue Webseite aufruft, weiß er, dass es einen oder ein paar Momente dauern kann, bis alle Daten angezeigt werden können. Eine Webanwendung, die mit Ajax Daten „nachlädt“, muss ebenfalls einen oder ein paar Momente auf Antwort warten. Ein Anwender, der nichts von Ajax weiß (und welcher Normalanwender muss das schon wissen?), bekommt in solchen Fällen den Eindruck, als ob die Webanwendung sehr zäh reagiert. Er klickt auf einen Button und muss möglicherweise mehrere Sekunden warten, bis das Ergebnis des ausgelösten Ereignisses sichtbar wird. Dies widerspricht seiner Erfahrung, wonach einmal geladene Webseiten sich im Speicher des eigenen Browsers befinden und sehr schnell reagieren.

Einige dieser Probleme sind allerdings durchaus lösbar. Eine Webanwendung kann beispielsweise so konzipiert werden, um GET-Parameter zu erkennen, über die sich direkt Inhalte und Seitenzustände ansprechen lassen, die sonst erst durch Ajax-Aktionen zustande kommen. Bei Wartezeiten, verursacht durch Ajax-HTTP-Anforderungen im Hintergrund, kann dem Anwender ein bekanntes Warte-Symbol (z.B. eine Sanduhr) angezeigt werden.

Was die Verfügbarkeit von JavaScript betrifft, so müssen Webentwickler eine Grundsatzentscheidung treffen. Entweder man macht die Aktivierung von JavaScript einfach zur Bedingung, oder man versucht, Ajax nur für Mehrwert-Funktionen eingesetzt werden (z.B. Tabellensortierung), wobei eine Grundfunktionionalität (z.B. Tabelle, die nicht sortierbar ist) gewährleistet ist. Vor allem Websites, die den Charakter einer Web­anwendung haben, mit der Benutzer etwas bearbeiten können, haben durchaus das Recht, die Aktivierung von JavaScript zur Bedingung zu machen. Bei gewöhnlichen Webseiten ist dagegen eher die Lösung angebracht, Ajax nur für Mehrwert-Funktionalität einzusetzen.