Defining tasks in Django - Performance & Optimization

Performance: Defining tasks

MEDIUM IMPACT

This affects how background work impacts server responsiveness and page load times.

Running long operations during a web request

Django

from celery import shared_task

@shared_task
def long_task():
    # Long running code here
    pass

def view(request):
    long_task.delay()
    return HttpResponse('Task started')

Runs task asynchronously in background, freeing request to respond immediately.

📈 Performance GainNon-blocking request, reduces INP by avoiding main thread delay.

Running long operations during a web request

Django

def view(request):
    # Long task runs synchronously
    result = long_task()
    return HttpResponse(result)

Blocks the web server process, delaying response and increasing input latency.

📉 Performance CostBlocks rendering and response for duration of task, increasing INP significantly.

Performance Comparison

Pattern	Server Blocking	Response Delay	User Interaction Impact	Verdict
Synchronous task in view	Blocks server thread	Delays response by task duration	High input delay (INP)	[X] Bad
Asynchronous task with Celery	No blocking	Immediate response	Low input delay (INP)	[OK] Good

Rendering Pipeline

When tasks run synchronously, the server delays sending HTML, blocking browser rendering. Asynchronous tasks let the server respond quickly, so browser can start rendering sooner.

→Server Response

→Browser Rendering

→Interaction Responsiveness

⚠️ BottleneckServer Response blocking due to synchronous task execution

Core Web Vital Affected

INP

This affects how background work impacts server responsiveness and page load times.

Optimization Tips

1Never run long tasks synchronously in request handlers.

2Use task queues like Celery to define asynchronous tasks.

3Asynchronous tasks improve server response and reduce input delay.

Performance Quiz - 3 Questions

What is the main performance problem with running long tasks synchronously in a Django view?

A It blocks the server response, increasing input delay.

B It increases CSS rendering time in the browser.

C It causes layout shifts on the page.

D It reduces the bundle size.

DevTools: Network

How to check: Open DevTools Network tab, reload page, and observe time to first byte and total response time.

What to look for: Long server response times indicate blocking synchronous tasks; short times indicate good async handling.

Practice

1. What decorator is commonly used to define a background task in Django with Celery?

easy

A. @task_runner

B. @shared_task

C. @async_task

D. @background_task

Solution

1. Step 1: Understand task definition in Django with Celery

   Celery uses the @shared_task decorator to mark functions as tasks that can run asynchronously.

2. Step 2: Identify the correct decorator

   Among the options, only @shared_task is the correct and standard decorator for defining tasks.

3. Final Answer:

   @shared_task -> Option B

4. Quick Check:

   Task decorator = @shared_task [OK]

Hint: Remember: Celery tasks use @shared_task decorator [OK]

Common Mistakes:

• Using @background_task which is not a Celery decorator
• Confusing @async_task with async/await syntax
• Using @task_runner which is not valid in Django

2. Which of the following is the correct way to call a Celery task asynchronously in Django?

easy

A. my_task.run()

B. my_task.execute()

C. my_task.delay()

D. my_task.start()

Solution

1. Step 1: Recall how to call Celery tasks asynchronously

   Celery tasks are called asynchronously using the delay() method on the task function.

2. Step 2: Identify the correct method

   Only delay() triggers the task asynchronously; other methods like run() execute synchronously or do not exist.

3. Final Answer:

   my_task.delay() -> Option C

4. Quick Check:

   Async call method = delay() [OK]

Hint: Use delay() to run tasks asynchronously [OK]

Common Mistakes:

• Calling run() which runs task synchronously
• Using execute() which is not a Celery method
• Trying start() which does not exist for tasks

3. Given this task definition:

from celery import shared_task

@shared_task
def add(x, y):
    return x + y

result = add.delay(4, 5)

What will result.get() return?

medium

A. 9

B. None

C. An AsyncResult object

D. A syntax error

Solution

1. Step 1: Understand the task and its call

   The add function adds two numbers. Calling add.delay(4, 5) runs it asynchronously and returns an AsyncResult.

2. Step 2: Using result.get() retrieves the task result

   Calling result.get() waits for the task to finish and returns the sum, which is 9.

3. Final Answer:

   9 -> Option A

4. Quick Check:

   Task result = 9 [OK]

Hint: delay() returns AsyncResult; get() fetches the actual result [OK]

Common Mistakes:

• Thinking delay() returns the result immediately
• Confusing AsyncResult object with the actual result
• Expecting None because task runs asynchronously

4. Identify the error in this task definition:

from celery import shared_task

@shared_task
def multiply(x, y):
return x * y

medium

A. Function name is invalid

B. Missing @shared_task decorator

C. Using delay() incorrectly

D. Indentation error in function body

Solution

1. Step 1: Check the function syntax

   The function body must be indented inside the function definition. Here, return x * y is not indented.

2. Step 2: Identify the error type

   Python requires indentation for blocks. Missing indentation causes an IndentationError.

3. Final Answer:

   Indentation error in function body -> Option D

4. Quick Check:

   Python blocks need indentation [OK]

Hint: Check indentation inside function definitions [OK]

Common Mistakes:

• Ignoring indentation errors
• Assuming decorator is missing when it is present
• Confusing function name validity with syntax errors

5. You want to define a task that sends emails but only if the email address is not empty. Which of these task definitions correctly applies this condition?

hard

A. from celery import shared_task

@shared_task
def send_email(email):
if email:
# send email code
return 'Sent'
return 'No email provided'

B. from celery import shared_task

@shared_task
def send_email(email):
if email == None:
return 'No email provided'
# send email code
return 'Sent'

C. from celery import shared_task

@shared_task
def send_email(email):
if not email:
return 'Sent'
# send email code
return 'No email provided'

D. from celery import shared_task

def send_email(email):
if email:
# send email code
return 'Sent'
return 'No email provided'

Solution

1. Step 1: Check for correct task decorator and condition

   from celery import shared_task @shared_task def send_email(email): if email: # send email code return 'Sent' return 'No email provided' uses @shared_task and checks if email: which correctly tests for a non-empty email.

2. Step 2: Verify logic correctness

   from celery import shared_task @shared_task def send_email(email): if email: # send email code return 'Sent' return 'No email provided' returns 'Sent' only if email is truthy (not empty), else returns 'No email provided'. This matches the requirement.

3. Final Answer:

   Option A correctly defines the task with the condition -> Option A

4. Quick Check:

   Use if email: to check non-empty string [OK]

Hint: Use if email: to check non-empty strings in tasks [OK]

Common Mistakes:

• Forgetting @shared_task decorator
• Using if not email: incorrectly reversing logic
• Not indenting task function properly