Reading and writing settings in Wordpress - Performance & Optimization

Performance: Reading and writing settings

MEDIUM IMPACT

This concept affects page load speed and interaction responsiveness by how settings are accessed and saved in WordPress.

Accessing and updating plugin or theme settings on page load

Wordpress

<?php
// Read once and cache in variable
$setting = get_option('my_plugin_setting');
// Use $setting multiple times without extra calls

// Write once after all changes
update_option('my_plugin_setting', $final_value);
?>

Reduces database queries and writes to a minimum, lowering blocking time and improving interaction responsiveness.

📈 Performance GainSingle database query and write, reducing blocking by 50-100ms and improving INP.

Accessing and updating plugin or theme settings on page load

Wordpress

<?php
// Reading settings multiple times in a single request
$setting1 = get_option('my_plugin_setting');
// ... some code ...
$setting2 = get_option('my_plugin_setting');

// Writing settings multiple times
update_option('my_plugin_setting', $new_value);
update_option('my_plugin_setting', $new_value2);
?>

Multiple calls to get_option and update_option cause repeated database queries and writes, increasing load time and blocking rendering.

📉 Performance CostTriggers multiple database queries and writes, blocking rendering and increasing INP by 50-100ms depending on server.

Performance Comparison

Pattern	Database Queries	Writes	Blocking Time	Verdict
Multiple get_option/update_option calls	Multiple queries	Multiple writes	Blocks rendering 50-100ms	[X] Bad
Single get_option and one update_option	Single query	Single write	Minimal blocking	[OK] Good

Rendering Pipeline

Reading and writing settings in WordPress involves PHP server-side processing that affects the time before HTML is sent to the browser. Multiple database calls increase server response time, delaying the browser's critical rendering path and user interaction readiness.

→Server Processing

→Network Transfer

→First Paint

→Interaction Readiness

⚠️ BottleneckServer Processing due to repeated database queries and writes

Core Web Vital Affected

INP

This concept affects page load speed and interaction responsiveness by how settings are accessed and saved in WordPress.

Optimization Tips

1Read settings once per request and reuse the value.

2Batch updates to settings to a single update_option call.

3Avoid reading or writing settings inside loops or repeated code paths.

Performance Quiz - 3 Questions

What is the main performance issue with calling get_option multiple times in one request?

A It increases CSS rendering time in the browser.

B It causes multiple database queries, increasing server response time.

C It causes layout shifts on the page.

D It blocks JavaScript execution on the client.

DevTools: Network and Performance panels

How to check: Use Network panel to check server response time; use Performance panel to record page load and interaction delays.

What to look for: Look for long server response times and delayed first input responsiveness indicating slow server-side processing.

Practice

1. Which WordPress function is used to read a saved setting from the database?

easy

A. get_option

B. save_option

C. set_option

D. read_option

Solution

1. Step 1: Understand the purpose of each function

   get_option is the WordPress function designed to retrieve saved settings. The others are not valid WordPress functions.

2. Step 2: Confirm the correct function for reading settings

   Since get_option reads the saved option value, it is the correct choice.

3. Final Answer:

   get_option -> Option A

4. Quick Check:

   Read settings = get_option [OK]

Hint: Remember: get_option reads, update_option writes [OK]

Common Mistakes:

• Confusing get_option with update_option
• Using non-existent functions like save_option
• Thinking set_option reads settings

2. Which of the following is the correct syntax to update a setting named 'site_color' to 'blue'?

easy

A. update_option('site_color', 'blue');

B. update_option('site_color' => 'blue');

C. get_option('site_color', 'blue');

D. set_option('site_color', 'blue');

Solution

1. Step 1: Identify the correct function and syntax for updating

   The function to update a setting is update_option, which takes two parameters: the option name and the new value.

2. Step 2: Check the syntax of each option

   update_option('site_color', 'blue'); correctly uses update_option('site_color', 'blue');. update_option('site_color' => 'blue'); uses an incorrect array syntax. get_option('site_color', 'blue'); uses get_option which reads, not writes. set_option('site_color', 'blue'); uses a non-existent function.

3. Final Answer:

   update_option('site_color', 'blue'); -> Option A

4. Quick Check:

   Update syntax = update_option(name, value) [OK]

Hint: update_option needs two arguments: name and value [OK]

Common Mistakes:

• Using get_option to update values
• Passing arguments as an array instead of separate parameters
• Using non-existent set_option function

3. What will be the output of this code snippet?

$color = get_option('site_color', 'red');
echo $color;

Assuming 'site_color' is not set in the database.

medium

A. site_color

B. null

C. '' (empty string)

D. red

Solution

1. Step 1: Understand get_option default value behavior

   If the option 'site_color' does not exist, get_option returns the default value provided as the second argument, here 'red'.

2. Step 2: Determine the output of echo

   Since 'site_color' is not set, $color will be 'red', so echo outputs 'red'.

3. Final Answer:

   red -> Option D

4. Quick Check:

   Missing option returns default value [OK]

Hint: get_option returns default if option missing [OK]

Common Mistakes:

• Assuming get_option returns empty string if missing
• Confusing option name with value
• Expecting null instead of default

4. Identify the error in this code snippet:

update_option('background_color');

medium

A. Function name should be get_option to update

B. update_option cannot update 'background_color'

C. Missing the new value parameter in update_option

D. update_option requires three parameters

Solution

1. Step 1: Check update_option function parameters

   update_option requires two parameters: the option name and the new value to set.

2. Step 2: Identify the missing parameter

   The code only passes the option name, missing the new value, causing an error.

3. Final Answer:

   Missing the new value parameter in update_option -> Option C

4. Quick Check:

   update_option needs name and value [OK]

Hint: update_option always needs two arguments [OK]

Common Mistakes:

• Passing only one argument to update_option
• Confusing get_option with update_option
• Thinking update_option needs three parameters

5. You want to save a user preference 'font_size' only if it is a positive integer. Which code snippet correctly updates the setting safely?

hard

A. update_option('font_size', $_POST['font_size']);

B. $size = intval($_POST['font_size']);
if ($size > 0) {
update_option('font_size', $size);
}

C. if ($_POST['font_size']) {
update_option('font_size', $_POST['font_size']);
}

D. $size = $_POST['font_size'];
update_option('font_size', $size > 0 ? $size : 12);

Solution

1. Step 1: Validate and sanitize the input

   $size = intval($_POST['font_size']);
   if ($size > 0) {
     update_option('font_size', $size);
   }

   uses intval to convert input to integer and checks if it is positive before saving.

2. Step 2: Confirm safe update of option

   Only if the value is positive does it call update_option, preventing invalid data.

3. Final Answer:

   $size = intval($_POST['font_size']);
   if ($size > 0) {
   update_option('font_size', $size);
   } -> Option B

4. Quick Check:

   Validate input before update_option [OK]

Hint: Always validate input before update_option [OK]

Common Mistakes:

• Saving raw user input without validation
• Using update_option without checking value
• Assuming non-empty input is always valid