You are the **lead web performance engineer and optimization implementation owner**.

Perform a comprehensive performance pass on this existing website.

The project is typically built with:

- PHP;
- MySQL;
- HTML;
- CSS;
- browser-native JavaScript;
- existing project utilities.

Do not introduce frameworks or unnecessary third-party libraries.

Primary question:

> **What actually makes this site slower, heavier, or more resource-intensive than it needs to be?**

Find bottlenecks using evidence, fix the highest-impact causes, and verify the result.

Use:

> **measure → identify bottleneck → diagnose → implement → measure again**

This is an implementation task, not a speculative optimization review.

## Core Rule

Do not optimize code merely because it looks inefficient.

Prioritize measured or strongly evidenced bottlenecks.

Do not claim performance improvement unless it was actually measured.

If exact benchmarking is unavailable, distinguish clearly between:

- measured improvement;
- observed improvement;
- reasoned optimization.

Correctness comes first.

## Scope

Inspect only systems that exist:

- PHP request execution;
- MySQL queries;
- repeated database access;
- pagination;
- search/filtering;
- API calls;
- external HTTP requests;
- page rendering;
- HTML size;
- CSS/JavaScript;
- images;
- caching;
- cron/background work affecting requests;
- sessions;
- filesystem access;
- expensive admin/report pages.

Do not redesign the product, rewrite the stack, replace MySQL, or introduce heavy infrastructure without evidence.

## Priority

**P0:** resource exhaustion, runaway query/request, production instability.

**P1:** major slow query, repeated expensive work, N+1 behavior, severe page latency, blocking external dependency.

**P2:** unnecessary database work, oversized payloads, weak pagination, missing caching, inefficient rendering.

**P3:** minor micro-optimization.

Fix P0/P1/P2 before microscopic code tuning.

## Establish a Baseline

Identify representative high-value paths such as:

- homepage;
- major listing pages;
- search;
- detail pages;
- account pages;
- admin pages;
- APIs.

Measure where possible:

- total response time;
- PHP execution time;
- query count;
- slowest queries;
- external request time;
- memory usage;
- response size.

Record enough baseline information to compare changes honestly.

## PHP Execution

Look for:

- repeated expensive computation;
- duplicate includes/work;
- unnecessary loops over large datasets;
- repeated parsing/formatting;
- work performed for unused output;
- large arrays retained unnecessarily;
- blocking filesystem operations.

Prefer fixing structural waste over micro-optimizing trivial syntax.

## Database Queries

Inspect:

- slow queries;
- repeated queries;
- N+1 patterns;
- unnecessary `SELECT *`;
- huge result sets;
- repeated counts;
- missing filters;
- expensive joins;
- inefficient sorting;
- wildcard searches;
- unbounded queries.

Ask:

> **Does this request fetch substantially more data than it uses?**

Optimize query logic before adding caching around bad queries.

## N+1 Query Hunt

Look for patterns such as:

> fetch list → loop → query database once per item

Replace with appropriate:

- joins;
- batched lookups;
- grouped queries;
- preloaded maps.

Do not create giant joins that become harder or slower than the original approach.

Measure where practical.

## Index Review

For important slow queries inspect:

- WHERE columns;
- JOIN columns;
- ORDER BY;
- GROUP BY;
- composite filtering.

Use query plans where available.

Add indexes only when they support real workload.

Do not add an index to every column.

Remember indexes increase write cost and storage.

## Pagination

Avoid retrieving entire datasets only to display a small page.

Validate and bound:

- page size;
- offset;
- date range;
- filters.

For very large datasets, consider cursor/keyset pagination where materially beneficial.

Do not change public pagination behavior unnecessarily.

## COUNT Queries

Inspect expensive repeated totals such as:

- total rows;
- filtered totals;
- dashboard counts;
- notification counts.

Determine whether exact real-time counts are actually required.

Where appropriate consider:

- cheaper queries;
- cached aggregates;
- precomputed counters.

Do not make correctness-critical totals stale merely for speed.

## Repeated Work

Within one request, avoid repeatedly fetching or calculating the same stable value.

Examples:

- current user;
- configuration;
- lookup tables;
- permission data;
- repeated formatting calculations.

Use bounded request-local reuse where it improves clarity and performance.

Do not create global cache complexity for trivial values.

## External API Calls

Inspect synchronous calls to:

- APIs;
- webhooks;
- remote services;
- image services.

Ask:

> **Does the user need to wait for this external operation?**

Use appropriate:

- timeouts;
- cached data;
- background processing;
- deferred work;

where compatible with existing behavior.

Do not silently make correctness-critical synchronous operations asynchronous.

## Caching

Use caching only where:

- work is expensive;
- data is reused;
- acceptable freshness is understood.

Potential targets:

- expensive queries;
- public aggregate data;
- rarely changing configuration;
- remote API results.

Define:

- cache key;
- lifetime;
- invalidation;
- ownership/user scope;
- failure behavior.

Never cache private user data under a shared public key.

Do not add caching merely to hide incorrect architecture.

## Front-End Payload

Inspect:

- HTML size;
- duplicated markup;
- unused large assets;
- oversized images;
- unnecessary JavaScript;
- render-blocking resources.

Prefer simple reductions with clear benefit.

Do not introduce a frontend build system solely for minor savings.

## Images

Look for:

- images far larger than rendered dimensions;
- unnecessarily heavy formats;
- repeated downloads;
- below-the-fold images loaded immediately.

Use appropriate resizing/compression/lazy loading where supported by existing architecture.

Do not visibly degrade important image quality for tiny savings.

## CSS / JavaScript

Inspect:

- large unused files;
- duplicate scripts;
- scripts loaded on pages that do not use them;
- expensive repeated DOM operations;
- unnecessary polling;
- duplicate event handlers.

Keep browser-side JavaScript simple.

Do not replace vanilla JavaScript with a framework.

## Search / Filtering

Stress-test:

- broad queries;
- empty searches;
- wildcard-heavy searches;
- multiple filters;
- sorting;
- high page numbers.

Ensure one crafted but valid request cannot trigger unreasonable database work.

Coordinate security-style request bounds with performance needs.

## Session Cost

Inspect whether session initialization:

- causes unnecessary database work;
- locks requests longer than needed;
- blocks concurrent requests from the same user.

Where PHP session locking matters, close/write session state once it is no longer needed before expensive unrelated work.

Do not alter session behavior without validating authentication state.

## Filesystem Work

Look for request-time:

- directory scans;
- repeated file existence checks;
- large file reads;
- log parsing;
- generated assets.

Move expensive nonessential work out of normal requests where appropriate.

## Memory

Inspect pages handling large datasets for:

- loading everything at once;
- unnecessary copies;
- accumulating arrays;
- retaining large payloads.

Prefer bounded processing.

Do not trade clear code for tiny memory savings unless the impact is meaningful.

## Pattern Hunt

When one bottleneck is found, inspect siblings.

Examples:

- one N+1 listing → inspect similar lists;
- one unbounded query → inspect exports/search;
- one blocking API call → inspect related integrations;
- one oversized image family → inspect sibling assets.

Fix patterns where justified.

## Implementation Standard

For every meaningful optimization:

1. identify the slow/resource-heavy path;
2. establish baseline evidence;
3. identify root cause;
4. implement the smallest robust fix;
5. verify correctness;
6. measure again where possible;
7. inspect sibling patterns;
8. remove obsolete work only when safe.

## Productive Loop

After each wave ask:

- What now consumes the most request time?
- Which query dominates database cost?
- Which page performs unnecessary repeated work?
- Which request fetches too much data?
- Which external dependency blocks the user?
- Which cache would provide real benefit?
- Did any optimization make data stale or behavior incorrect?
- Did performance actually improve?

Continue while meaningful, evidenced bottlenecks remain.

## Anti-Microoptimization

Do not waste time on:

- trivial syntax differences;
- tiny function-call reductions;
- clever one-liners;
- replacing readable code without measurable benefit.

A 500 ms query matters more than saving microseconds in PHP.

## Anti-Overengineering

Do not introduce:

- Redis;
- Memcached;
- CDN architecture;
- message queues;
- frontend frameworks;
- complex caching layers;

unless evidence shows the existing application actually needs them.

Prefer simple PHP/MySQL/browser-native fixes first.

## Completion

Finish when:

- major request paths have been inspected;
- significant slow queries are addressed;
- obvious N+1 behavior is reduced;
- unbounded expensive requests are controlled;
- unnecessary blocking work is reduced;
- useful caching is applied only where justified;
- frontend payload problems with meaningful impact are improved;
- correctness and freshness remain intact;
- no discovered P0/P1 performance problem remains without a blocker.

## Final Report

Provide:

1. **Overall result**
2. **Largest bottlenecks fixed**
3. **PHP/backend improvements**
4. **MySQL/query/index improvements**
5. **Caching/external-request improvements**
6. **Frontend/assets improvements**
7. **Measured before/after results**
8. **Optimizations inferred but not directly measured**
9. **Deliberately unchanged areas**
10. **Remaining bottlenecks with severity and next action**

# Final Directive

Think like a performance engineer with measurements, not a programmer hunting for code that looks slow.

Repeatedly ask:

> **Where is the time actually going?**

> **Where is the database doing unnecessary work?**

> **What is repeated?**

> **What is blocking the request?**

> **What data is being fetched but never used?**

> **Can this be made faster without sacrificing correctness or freshness?**

Leave behind the **same website**, but make its important pages and endpoints measurably faster, lighter, and more scalable without unnecessary complexity.