What I learned about page speed from customising AFFINGER5

Customising AFFINGER5 taught me that page speed is rarely improved by one dramatic change. The bigger gains came from understanding how the theme loaded stylesheets, JavaScript, web fonts, widgets and advertising scripts, then removing the parts that were not earning their place. A page can look polished in the WordPress editor while still making visitors wait for the main content.

This matters especially for readers in Australia. Someone browsing on a busy train in Sydney, a shared connection in a regional town, or mobile data in Perth does not experience a website in the same way as someone using fast fibre at home. My experiments with AFFINGER5 made performance less abstract: every unnecessary rule and script became another delay between a visitor and the information they came to read.

What changed when I edited the theme files

AFFINGER5 is flexible because it offers many visual controls, but flexibility can create layers of CSS. A setting for button colours, a widget design, a social panel and a responsive layout may each add rules to the final page. Some selectors affect only one small component, while others load across the entire site even when that component is not being used.

I began by comparing the source code on a simple article with a page containing tables, banners and related posts. The heavier page had more markup and more style dependencies, but the difference was not always obvious from the file size alone. Render-blocking resources, unused declarations and the order in which assets arrived had a greater effect on what visitors saw first.

The first lesson was to avoid editing blindly. AFFINGER5 updates can overwrite changes made directly inside the parent theme, and a small syntax error can affect every page. I kept a backup, recorded each change and made one adjustment at a time so that a visual improvement could be linked to a measurable result.

Why unused CSS slowed the first view

My early CSS edits focused on reducing repeated declarations and removing styles for features I had disabled. I also combined a few small custom rules instead of adding separate snippets for each article. This did not magically make every page fast, but it reduced the amount of work the browser had to parse before displaying the layout.

The important distinction was between total page weight and perceived speed. A page might lose only a few kilobytes, yet appear faster because the browser could construct the header, text column and first image sooner. On a blog, that first view is crucial. Readers usually want to scan the heading and opening paragraphs before deciding whether to stay.

CSS signals worth checking

I also learned to be careful with aggressive CSS compression. Minification can reduce transfer size, but it does not fix poor structure. A compressed stylesheet still contains unnecessary rules, and a badly combined file can cause layout problems that are harder to diagnose. Keeping the CSS organised was more useful than chasing the smallest possible number.

JavaScript timing mattered more than file size

JavaScript caused more surprises than CSS. Some scripts were small but ran early and interrupted rendering. Others were larger but harmless because they loaded after the main content. AFFINGER5 can support sliders, menus, social buttons, tracking, related content and advertising integrations, so it is easy to accumulate scripts that compete for attention during the first few seconds.

I tested whether scripts could be deferred, loaded asynchronously or moved closer to the end of the document. The correct choice depended on the script. A menu required careful testing because moving it too late could make the navigation feel broken. A sharing widget could wait. Analytics and advertising tags also needed checking, since changing their loading order can affect measurement or revenue reporting.

The useful target was not “remove all JavaScript”. It was to delay non-essential work until the visitor could see and use the article. I checked menu buttons, accordion panels, internal search, affiliate links and forms after every change. A faster page that quietly breaks its mobile navigation is not a successful optimisation.

Australian connections made performance clearer

Australian browsing conditions helped me set more realistic priorities. NBN performance varies between homes and regions, and many people switch to mobile data when commuting, travelling or dealing with a patchy household connection. A blog aimed at readers in Melbourne or Brisbane still needs to behave well for someone visiting from a smaller town or from a regional area with higher latency.

The local market also shaped how I assessed monetisation. Australian readers may see local retailers, travel offers, finance services and affiliate links alongside global advertising networks. Each external provider can add DNS lookups, scripts and tracking requests. A few extra partners may seem harmless, but the combined effect becomes visible on a mobile connection in Adelaide, Hobart or outside the major metropolitan areas.

Performance checks that reflected real visitors

The way people talk about websites also influenced my judgement. A reader saying, “That page is taking ages to load,” is describing an experience, not a laboratory metric. Core Web Vitals such as Largest Contentful Paint and Interaction to Next Paint helped explain the problem, but I still opened pages as a normal visitor would. If the article felt sluggish, a green-looking score did not settle the matter.

A safer workflow for theme customisation

I used browser developer tools, PageSpeed Insights and waterfall views to identify which resources arrived first and which ones delayed the main content. I compared a clean article, a post with affiliate boxes and a page containing several images. This showed whether an improvement applied across the site or only helped one special template.

Caching created some misleading results. After changing CSS or JavaScript, an old cached version could make the test appear unchanged. I cleared local caches, checked the WordPress cache settings and used version numbers for modified assets where appropriate. I also tested in an incognito window and repeated measurements at different times instead of trusting a single score.

A staging copy was particularly valuable. There, I could disable one plugin, alter a loading attribute or remove a theme feature without risking the live blog. When the result was stable, I moved the change carefully and checked real pages. This process took longer than pasting a performance snippet into a settings box, but it prevented the sort of rushed fix that creates a new problem.

What I would preserve on a working blog

The biggest lesson was that design and speed are not enemies. AFFINGER5 made it possible to keep useful navigation, readable typography and clear affiliate disclosures while removing decorative features that added little value. The goal was a page that felt calm and responsive, rather than a bare page that had sacrificed every helpful element for a benchmark.

I also stopped treating the homepage as the only important test. Search visitors often arrive directly on an older article, a review, or a guide with several images. Those pages need the same attention as the front page. Before publishing a new feature, I now consider its JavaScript cost, image dimensions, font requirements and effect on the first screen.

For practical WordPress notes and related experiments, I keep the wider context on Rico’s blogging blog. The experience reinforced that technical choices should serve the reader and the business together: faster content can improve engagement, but removing a useful affiliate comparison or making a form unusable can damage the site in a different way.

Finally, I learned to value repeatable habits over one-off optimisation. A theme file may be tidy today, then become heavy after months of plugins, campaigns and custom snippets. Regular checks, cautious updates and a record of why each rule exists help keep performance under control as the blog grows.