Javascript/Jquery AJAX call to PHP very slow to even not working at all

by

Summary

This incident documents a severely delayed or non‑functional AJAX request in a PHP/MySQL + jQuery application. The UI appeared to “freeze” with a status indicator stuck on going, even though the backend logic looked simple. The real issue was not the database, not TinyMCE, and not jQuery itself — it was a classic architectural mistake that causes silent failures and long delays in real systems.

Root Cause

The slowdown was caused by a combination of misconfigured AJAX usage and PHP-side issues:

  • Using GET for large payloads (TinyMCE HTML content can easily exceed URL length limits)
  • No error handling on the AJAX request (only success callback defined)
  • No server-side validation of DB connection failures
  • Silent PHP errors (no logging, no error reporting)
  • Blocking MySQL operations without proper escaping or prepared statements
  • Relying on $_REQUEST instead of explicit $_POST or $_GET

The result:
Requests intermittently failed, truncated, or never reached the server, making the UI appear slow or broken.

Why This Happens in Real Systems

These patterns show up frequently in production systems because:

  • GET requests silently truncate large data, especially HTML content
  • Developers assume AJAX failures will throw visible errors, but browsers suppress them
  • PHP errors are hidden by default, especially on shared hosting
  • Database operations block when connections are slow or misconfigured
  • TinyMCE content is large and complex, making it unsuitable for GET

In short: the system was working against itself.

Real-World Impact

When this issue appears in production, teams typically see:

  • Randomly missing or partially saved data
  • Requests that “hang” forever
  • Users clicking Save repeatedly, causing duplicate writes
  • Database locks from repeated failed updates
  • Support tickets claiming “the app is slow”

These symptoms waste engineering time and erode user trust.

Example or Code (if necessary and relevant)

Below is a corrected AJAX call using POST, error handling, and proper content submission:

$.ajax({
  type: 'POST',
  url: 'ajax.php',
  data: {
    id: $('#id_hak').val(),
    name: $('#name_hak').val(),
    content: tinymce.get("content_hak").getContent(),
    tags: $('#tags_hak').val(),
    unique: $('#unique_hak').val()
  }
})
.done(function (result) {
  $('.status').text('done');
})
.fail(function () {
  $('.status').text('failed');
});

And a safer PHP handler:

prepare("UPDATE `-notes` SET name=?, content=?, tags=? WHERE id=?");
$query->bind_param("ssss", $name, $content, $tags, $id);
$query->execute();

echo "true";

How Senior Engineers Fix It

Experienced engineers approach this systematically:

  • Switch GET → POST for any nontrivial payload
  • Add AJAX .fail() handlers to surface network/server errors
  • Enable PHP error logging and disable display_errors in production
  • Use prepared statements to avoid SQL injection and encoding issues
  • Validate request size and reject oversized payloads gracefully
  • Instrument the system (timing logs, DB slow query logs)
  • Test with realistic data, not tiny placeholder strings

The fix is not just code — it’s discipline and observability.

Why Juniors Miss It

This class of bug is extremely common among newer developers because:

  • They trust GET to “just work” without understanding URL limits
  • They assume AJAX errors will be visible, not silent
  • They don’t test with real-world payloads like full TinyMCE HTML
  • They don’t check server logs, relying only on browser output
  • They copy/paste examples that use GET for convenience
  • They don’t yet think in terms of system behavior, only code behavior

The gap is not intelligence — it’s experience with how real systems fail.

Leave a Comment