In-depth practical guides

Clean a web project without breaking the site

Separate served files, required data and working artifacts: reduce a project while preserving useful pages, languages and media.

Updated :

Reading room of the John Rylands Library in Manchester, photographed in 2016.

Reading room of the John Rylands Library in Manchester, photographed in 2016. Documentary context photograph; it does not depict an Alexis Roux ZG assignment or equipment. © Michael D Beckwith · Source · CC0. Resized and converted to WebP; cropped display.

What evidence makes a file safe to remove?

An old name, large size or missing text reference is insufficient. A catalog key may select an image, CSS may load a font, and a shared function may read JSON. Begin with actual uses and retain a recovery path. Define the file scope explicitly and leave secrets, access details and sensitive configuration untouched.

  1. Classify uses

    Separate public routes, shared code, data, served media, production sources and temporary output. Record file counts and bytes by group. A public article about an audit remains website content; a local test report may be an artifact. Classify by function rather than filename.

  2. Trace dependencies

    Inspect includes, imports, CSS URLs, scripts, metadata and manifests. Reconstruct dynamically assembled names using page keys, languages, image suffixes or profile identifiers. Test variants, error pages and empty states. Include social sharing resources and exports, beyond visible images.

  3. Define candidates

    Record location, size, reason, searched references and possible dependencies for each candidate. Compare originals with optimized variants: an original may support production even when it is not served. Decide what stays in the project and what can be retained separately before removal.

  4. Prepare recovery

    Keep a recoverable copy of the relevant items in suitable storage outside the public directory. Identify the matching website version. A file ignored by Git is not automatically backed up or excluded from deployment. Check version tracking, published package and recovery archive separately.

  5. Remove in batches

    Start with identified artifacts, then replaced libraries and media with established dependencies. Verify absolute paths and remain within the announced scope. Repeat the same tasks after each batch. Do not remove data or security files simply because they are not public.

  6. Check the result

    Repeat routes and languages, search, filters, tools, forms and error states. Check srcset, preloads, CSS and resources loaded after interaction. Compare project bytes before and after. Disk savings are not necessarily transfer savings: an unused file was not being downloaded by the browser.

Situations and decisions

Typical situations for preparing a check. They do not describe completed assignments or actual observations.

A font appears abandoned

The replacement icon system no longer uses a font. Check every loaded stylesheet, pseudo-element and menu state. Remove the old library only once its functions have been replaced and the affected checks pass.

A photograph has four sizes

The small variant has no exact PHP reference, but a manifest supplies it to the browser. Read the manifest and inspect currentSrc at relevant widths. Keep used variants; failure to select one in a single screenshot is not evidence that it is unnecessary.

Screenshots sit beside content

Reports, captures and measurement files support testing work. Remove them from the published project after retaining needed evidence elsewhere. Keep photographic credits and editorial data displayed to readers.

Record to retain

  • Candidate inventory: path, size, role and removal reason.
  • Direct and dynamic dependencies inspected, with covered routes and languages.
  • Recoverable version, storage location and exact removed-file list.
  • Before-and-after results, any missing resources and actual removed volume.

Official references

Related protocols

Checks before reaching a conclusion

  • Is lack of use established in code, rendered pages and dynamically built paths, rather than just a filename search?
  • Are responsive variants, preloads, sharing images and sitemap declarations considered before removing media?
  • Does removal preserve data used by search, translations and recovery functions while leaving access information untouched?

Frequently asked questions

Can everything absent from the sitemap be removed?

No. A sitemap describes URLs; it does not list the includes, data, media or operations needed to serve them.

Does gitignore prevent publication?

Not necessarily. Git ignore concerns tracking untracked files. Deployment rules determine what gets published.

Should original photographs be kept?

Retain a quality source and licensing information when future variants may be needed. They can live outside the public directory while the website serves optimized files.

Does cleanup automatically improve performance?

It reduces storage and may simplify delivery. Page loading improves when transferred resources, processing or executed dependencies actually decrease.