Request and response handling in Wordpress - Performance & Optimization

Performance: Request and response handling

HIGH IMPACT

This affects how quickly the server processes user requests and sends back responses, impacting page load speed and interactivity.

Handling user requests in WordPress to serve page content

Wordpress

<?php
// In functions.php
add_action('init', function() {
  global $wpdb;
  if (isset($_GET['action']) && $_GET['action'] === 'load_data') {
    $cache_key = 'load_data_cache';
    $data = get_transient($cache_key);
    if (!$data) {
      $data = $wpdb->get_results("SELECT * FROM wp_posts WHERE post_status = 'publish'");
      set_transient($cache_key, $data, 3600); // Cache for 1 hour
    }
    echo json_encode($data);
    exit;
  }
});

Uses WordPress transient caching to avoid repeated heavy queries, reducing server processing time.

📈 Performance GainReduces server processing time by 80%, improving LCP and lowering CPU load

Handling user requests in WordPress to serve page content

Wordpress

<?php
// In functions.php
add_action('init', function() {
  global $wpdb;
  if (isset($_GET['action']) && $_GET['action'] === 'load_data') {
    // Heavy database query without caching
    $data = $wpdb->get_results("SELECT * FROM wp_posts WHERE post_status = 'publish'");
    echo json_encode($data);
    exit;
  }
});

This runs a heavy database query on every request without caching, causing slow response times and high server load.

📉 Performance CostBlocks rendering for 200+ ms on each request, increasing LCP and server CPU usage

Performance Comparison

Pattern	DOM Operations	Reflows	Paint Cost	Verdict
Heavy uncached DB query on every request	N/A (server-side)	N/A	Delays initial paint	[X] Bad
Cached DB query with transients	N/A (server-side)	N/A	Faster initial paint	[OK] Good

Rendering Pipeline

The request hits the server, WordPress processes PHP code including database queries, then generates HTML or JSON response sent to the browser. The browser parses and paints the content.

→Server Processing

→Network Transfer

→Browser Parsing

→Paint

⚠️ BottleneckServer Processing due to heavy or uncached database queries

Core Web Vital Affected

LCP

This affects how quickly the server processes user requests and sends back responses, impacting page load speed and interactivity.

Optimization Tips

1Cache expensive database queries to reduce server processing time.

2Avoid running heavy queries on every request without caching.

3Use DevTools Network panel to monitor server response times.

Performance Quiz - 3 Questions

What is the main performance benefit of caching database query results in WordPress request handling?

A Makes the browser do more work

B Increases the number of database queries

C Reduces server processing time and speeds up response

D Adds extra network requests

DevTools: Network

How to check: Open DevTools, go to Network tab, reload page, and check the Time column for server response time (TTFB).

What to look for: Look for long TTFB (Time To First Byte) indicating slow server response; shorter times mean better request handling.

Practice

1. In WordPress, which superglobal variable is commonly used to access data sent via an HTTP POST request?

easy

A. $_REQUEST

B. $_POST

C. $_GET

D. $GLOBALS

Solution

1. Step 1: Understand HTTP POST data handling

   Data sent by users through a POST request is stored in the $_POST superglobal in PHP.

2. Step 2: Differentiate from other superglobals

   $_GET holds URL query parameters, $_REQUEST combines GET, POST, and COOKIE but is less specific, and $GLOBALS holds all global variables.

3. Final Answer:

   $_POST -> Option B

4. Quick Check:

   POST data = $_POST [OK]

Hint: POST data is always in $_POST superglobal [OK]

Common Mistakes:

• Confusing $_GET with $_POST
• Using $_REQUEST without knowing its mixed content
• Assuming $GLOBALS holds request data

2. Which of the following is the correct way to send a JSON response in a WordPress REST API callback function?

easy

A. wp_send_json($data);

B. header('Content-Type: text/plain'); echo $data;

C. echo json_encode($data);

D. return new WP_REST_Response($data, 200);

Solution

1. Step 1: Understand WordPress REST API callback requirements

   REST API callbacks should return a WP_REST_Response, array, or WP_Error. The framework handles headers, JSON encoding, and status.

2. Step 2: Compare other options

   wp_send_json($data); sends JSON and exits with wp_die(), suitable for AJAX but bypasses REST processing/filters. echo json_encode($data); outputs JSON without headers or exit. header('Content-Type: text/plain'); echo $data; wrong type.

3. Final Answer:

   return new WP_REST_Response($data, 200); -> Option D

4. Quick Check:

   Return WP_REST_Response [OK]

Hint: Return WP_REST_Response for REST API JSON response [OK]

Common Mistakes:

• Using wp_send_json() (intended for AJAX handlers)
• Using echo without proper headers and exit
• Sending wrong content type header

3. Consider this WordPress REST API callback function:

function get_custom_data(\WP_REST_Request $request) {
  $param = $request->get_param('id');
  if ($param === '42') {
    return ['message' => 'Found'];
  }
  return new WP_Error('not_found', 'ID not found', ['status' => 404]);
}

What will be the HTTP status code if the request URL includes ?id=42?

medium

A. 200

B. 404

C. 500

D. 302

Solution

1. Step 1: Analyze the parameter check

   The function checks if id equals '42'. If yes, it returns an array with message 'Found'.

2. Step 2: Understand default REST API response codes

   Returning an array results in a 200 OK status. Returning WP_Error sets the error status (404 here).

3. Final Answer:

   200 -> Option A

4. Quick Check:

   Valid data returns 200 OK [OK]

Hint: Array return = 200 OK; WP_Error return = error code [OK]

Common Mistakes:

• Assuming WP_Error always returns 200
• Confusing string '42' with integer 42
• Ignoring default REST API status codes

4. You wrote this WordPress REST API endpoint callback:

function my_callback(\WP_REST_Request $request) {
  $data = $request->get_param('data');
  wp_send_json_success($data);
  echo 'Done';
}

What is the problem with this code?

medium

A. The echo statement after wp_send_json_success() will never run

B. wp_send_json_success() does not send JSON

C. get_param() cannot retrieve 'data' parameter

D. Missing return statement causes error

Solution

1. Step 1: Understand wp_send_json_success behavior

   This function sends JSON response and calls exit(), stopping further code execution.

2. Step 2: Analyze code after wp_send_json_success

   The echo 'Done'; line is unreachable because the script exits before it.

3. Final Answer:

   The echo statement after wp_send_json_success() will never run -> Option A

4. Quick Check:

   wp_send_json_success() exits script [OK]

Hint: Code after wp_send_json_success() is unreachable [OK]

Common Mistakes:

• Expecting code after wp_send_json_success() to run
• Confusing get_param() usage
• Thinking wp_send_json_success() returns data instead of exiting

5. You want to create a WordPress REST API endpoint that accepts a POST request with a JSON body containing a 'name' field. Which sequence correctly handles the request and sends a JSON response with a greeting message?

hard

A. Use $request->get_body_params()['name'] to get 'name', then return ['greeting' => 'Hello ' . $name].

B. Use $_POST['name'] directly, then echo JSON encoded greeting and exit.

C. Use $request->get_json_params()['name'] to get 'name', then return new WP_REST_Response(['greeting' => 'Hello ' . $name], 200).

D. Use file_get_contents('php://input') to read JSON body, then use wp_send_json() to send response.

Solution

1. Step 1: Retrieve JSON body parameters properly

   In WordPress REST API, $request->get_json_params() safely parses JSON body data.

2. Step 2: Return a proper REST response object

   Returning WP_REST_Response with data and status code is the recommended way to send structured responses.

3. Step 3: Evaluate other options

   A uses get_body_params() which checks form data ($_POST), empty for JSON body POSTs. C uses $_POST['name'] directly, same issue. D manually reads input bypassing framework helpers and uses wp_send_json() which exits.

4. Final Answer:

   Use $request->get_json_params()['name'] and return WP_REST_Response -> Option C

5. Quick Check:

   Use get_json_params() + WP_REST_Response for JSON POST [OK]

Hint: Use get_json_params() for JSON body in REST API [OK]

Common Mistakes:

• Using $_POST or get_body_params for JSON body data
• Not decoding JSON body properly
• Returning raw arrays instead of WP_REST_Response