Most people talk about speed in terms of new builds. They load a fresh framework and brag about 90 plus Lighthouse scores. But those of us managing old blogs or corporate sites with thousands of legacy pages face a different problem. We have a mountain of HTML from 2014, nested tables, and outdated scripts that make the browser choke. Fixing this is not about installing a new plugin. It is about deciding what to kill and what to keep.
The trap of automated optimization
Many admins even try to use bulk tools to minify everything. That often breaks the layout on older pages. I once tried an automated CSS compressor on a five year old archive and ruined every single table layout. The mistake was trusting the tool over the manual audit. Instead, I started using coodoo.org to analyze how different elements actually affect the load time without risking a site wide crash. You need to see where the bloat lives before you start deleting lines of code.
Why scripts slow down old pages
Legacy sites usually have script creep. You add a tracking pixel in 2016, then a chat widget in 2018, then a fancy slider in 2020. By 2024, the footer is a graveyard of dead JS calls. The browser still tries to fetch these files even if they do nothing. I spent three hours last month removing an old heatmap tool that no one used but still added 200 milliseconds to the time to first byte.
Dealing with image bloat
Before WebP existed, we just uploaded huge JPEGs and hoped for the best. Now those files sit on the server like lead weights. Modern lazy loading helps, but it does not solve the size issue. I suggest focusing on images in your top twenty most visited legacy pages first.
- Convert old PNGs to WebP format manually
- Set explicit width and height attributes to stop layout shifts
- Remove hidden images from old slider plugins
- Compress archives that are rarely accessed
- Use a CDN to cache static assets from old directories
Cleaning up CSS selectors
Old CSS files are often full of overrides upon overrides. You find styles like .content .main .article p { color: #333 !important; }. This specificity makes it impossible to update the design without breaking something else. I prefer to find these redundant blocks and delete them entirely. If you are scared of breaking the page, save a local copy of the HTML first.
The role of strategic caching
Caching is not a magic fix but it masks bad code effectively. For legacy content, long TTL values work best because that content rarely changes. I set my archive pages to cache for a week instead of an hour. This reduces server load and gives users a snappy experience even if the underlying code is messy.
Choosing between refactoring and deleting
Sometimes fixing an old page takes more time than rewriting it from scratch. I usually run a traffic report for the last twelve months. If a page has zero visits and takes five seconds to load, I delete it or redirect it to a updated version. There is no reason to optimize code that no one reads. Keeping the site lean is better than keeping every single post ever written since 2010.