To make a news site faster, you work down a fixed order: measure the real experience, find where the seconds actually go, cut image bytes, defer third-party scripts, fix caching and server response, then protect the gains. Most newsroom speed problems trace back to two things — oversized media and ad, analytics and tag-manager scripts that nobody owns.
It is a technical job, but it is not a mystery, and most of it does not require a rewrite. A regional daily on a ten-year-old WordPress install can lose several seconds per page by changing how images are served and how tags load.
The uncomfortable part is that speed keeps slipping. Publisher operators describe the same pattern: a quiet month, then a marketing colleague adds a tag, and the article template gets slower. This guide covers the seven steps that actually move the numbers, plus what to check before you start and the mistakes that undo the work.
What You Need
You need access and data before you change anything. Without a baseline, you cannot tell whether a change helped, and on a news site the temptation to guess is strong because the reader experience varies so much by device and connection.
- A staging environment. A copy of the live site where you can deploy template changes. Speed work that goes straight to production is how you break the homepage during a busy morning.
- Field data. Chrome UX Report data in Search Console, or real user monitoring installed on the site. This is what your readers actually experience, not a synthetic test.
- Lab tools. PageSpeed Insights for a quick read, Chrome DevTools for tracing, and WebPageTest for a repeatable before-and-after comparison.
- Server and CDN access. Response headers, compression settings, cache rules, and the ability to purge a cache at a specific moment.
- A shortlist of your heaviest pages. The homepage, the section front, the most-read article, and one breaking-news template. Fixing a page nobody visits is wasted work.
- An owner for performance. Someone who can say yes or no when a vendor asks to install a tag. This is the item teams skip, and it is the one that decides whether the gains last.
Step-by-Step: How to Make a News Site Faster
Measure the Current Experience
Start by measuring LCP, INP and CLS on the pages you listed, because they are the metrics Google treats as page experience signals and they describe what a reader perceives.
| Metric | What it measures | Good | Needs work | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | When the main headline image or text block appears | 2.5s or less | 2.5s to 4.0s | Over 4.0s |
| INP (Interaction to Next Paint) | How quickly the page responds when a reader taps something | 200ms or less | 200ms to 500ms | Over 500ms |
| CLS (Cumulative Layout Shift) | How much content jumps around while loading | 0.1 or less | 0.1 to 0.25 | Over 0.25 |
| TTFB (Time to First Byte) | How long the server takes to answer | Under 800ms | 800ms to 1.8s | Over 1.8s |
INP replaced the older FID metric in March 2024. A lot of guidance still circulating is written against FID, and much of the search ranking for this topic is dated — if you are optimising against old thresholds you are working from the wrong target.
Test at least four templates and run them on a throttled mobile connection, because desktop scores flatter nearly every news site. The number that matters is the field median for your article template on mobile, not the score you get on office fibre.
How you verify this step: you can state a baseline LCP in seconds for the homepage and for an article page, and you know which one is worse.
Find the Main Sources of Delay
A news page is slow for reasons a brochure site never has, so measuring it as though it were one is how teams waste a sprint optimizing the wrong file.
| Cause | Typical weight on a news page | Why it is different here |
|---|---|---|
| Third-party ad, analytics and consent scripts | Largest single contributor on most publisher pages | Added by several teams, owned by none |
| Lead and inline article images | Often half the page weight | Editorial workflows push large files straight from a camera or agency feed |
| Embedded video and social posts | Thousands of milliseconds when autoplaying | Loaded by template, not by editor intent |
| Tag manager containers | Varies wildly by site | Growth compounds, removals do not |
| Server response and uncached pages | Consistent drag on every request | Constant publishing breaks full-page cache assumptions |
| Web fonts | Render blocking | Brand typography is rarely negotiable for editors |
In Chrome DevTools, open the Network panel and sort by transfer size and by blocking time. Then check the Coverage tab for unused JavaScript and CSS. What you are looking for is one or two big causes, not thirty small ones — publishers who treat it as a hundred-item cleanup never finish.
Watch for long tasks in the performance trace. A 400ms task from an analytics bundle will fail INP on a mid-range phone even though it looks instant on your laptop.
How you verify this step: you can name the top three costs on the page in order, and each one has a person attached to it.
Optimize Images and Video
Images are where news sites win the biggest, safest seconds. News pages are image-first by definition, so this is not optional work.
- Serve modern formats. Convert JPEG and PNG to WebP or AVIF at upload. Most CMS plugins do this automatically now, which means your 2MB photo becomes roughly 200KB with no visible difference on a phone screen.
- Use responsive srcset. A 400px-wide phone should never download a 2000px lead image. Set explicit width and height attributes on every image so the browser reserves space and CLS stays low.
- Resize at upload, not in the template. The theme cannot undo the cost of shipping a full-resolution agency photo through the CDN.
- Preload the one above-the-fold image. Lazy loading the lead image is a common and costly mistake — it delays the very element that defines LCP.
- Lazy load everything below the fold. Including inline images halfway down an article and every widget further down.
- Treat embeds carefully. Never autoplay a video or social post above the fold. Use a poster image as a click-to-play placeholder, which loads a fraction of the weight and keeps INP healthy.
How you verify this step: the transferred image bytes on your article template drop by half or more, and the LCP element is still the lead image, loaded eagerly.
Reduce JavaScript, CSS, and Third-Party Work
Third-party scripts are usually the slowest code on the page, and they are the hardest to remove because revenue and audience data depend on them.
Audit what actually loads, then triage in this order. First, anything no one will admit owning. Second, duplicate tags firing the same event through different containers. Third, marketing heatmaps and session-record tools, which are enormous and rarely checked. Fourth, chat widgets and newsletter pop-ups that sit permanently in the sidebar.
For what survives, control when it runs. Load analytics and ad scripts after the main content with defer or async, gate consent and tag-manager code behind the consent state, and reserve space for ad slots so they cannot shift the layout.
On CSS, ship one stylesheet, inline the above-the-fold rules, and delete the stylesheets that came with plugins nobody uses any more. Self-host a subset of your fonts with font-display: swap so text renders immediately rather than waiting on a font file.
How you verify this step: total JavaScript transfer on the article template falls by at least 30 percent, and every remaining vendor tag has a named owner and a documented reason to exist.
Improve Caching, Delivery, and Server Response
Server response time is the floor under every other metric, and it is the one most publishers leave longest before investigating. If TTFB is over 800ms on mobile, image work will not rescue the page.
Turn on Brotli compression for text responses, and confirm it is actually being served rather than falling back to gzip. Put a CDN in front of the site so static assets are served from an edge close to the reader, and set long-lived cache headers on images, CSS and JavaScript with versioned filenames so you can change a file without a purge.
Cache HTML carefully on a news site. Full-page caching works well for article pages, which rarely change after publication, but a homepage with live modules needs a short TTL or a targeted purge. Editors who cannot publish quickly will route around your caching, so design for the purge button before you argue about TTLs.
Then check the boring causes: redirect chains from old CMS URL schemes, an unindexed staging host, and database queries that scan instead of use an index.
How you verify this step: TTFB on a cold cache is under 800ms, and repeat views to the same story render from cache with no origin request.
Use Faster News Templates and Publishing Workflows
On a site that publishes all day, performance is a template decision, not a one-off fix. Most article weight lives in shared components — the lead image, the byline block, the related-stories rail, the ad slots, the newsletter module.
Optimize those once and every story inherits the gain. Keep homepage modules to a fixed number of images, since a flexible “up to 20 cards” module is how homepages get heavy. Give live blogs their own lighter template, because a rolling page with twenty entries and live ads is a different performance problem from an article.
Add a publishing step that resizes and converts images on upload, so a 6MB photo from a reporter’s phone never reaches the public page. Write a short rule about embeds — no autoplay above the fold, click-to-play for video, a defined limit per page.
For breaking news, decide the plan before the spike: pre-warm the CDN cache on the story template, raise page caching for static assets, and agree in advance who can trigger a purge. Publisher operators report that spike-related degradation is exactly the failure mode their regular audits never surface, because nobody lab-tests at 50x normal traffic.
How you verify this step: a newly published story loads with the same weight and timings as a story from six months ago.
Verify the Improvements and Prevent Regressions
Retest the same four pages under the same conditions you used for the baseline. Lab scores are noisy between runs, so look for meaningful movement in the field data over two to four weeks rather than a five-point jump in one PageSpeed Insights run.
Check mobile separately from desktop, and check returning visitors with a warm cache against first-time visitors on a cold one. Cold-cache performance is what your biggest traffic spike will look like.
Then make the gains stick. Set a performance budget — a maximum total page weight, a maximum script count, an LCP target — and enforce it in continuous integration so a template change that breaks the budget fails the build. Give one person ownership, and require any new tag request to show its transfer size and a reason.
How you verify this step: the budget is enforced in CI, a monthly field-data review is on the calendar, and every vendor tag has an owner.
Common Mistakes
- Optimizing only the homepage. Most readers land on articles from search and social, so a fast homepage with a slow article template changes nothing for traffic.
- Lazy loading the lead image. This pushes the LCP element later and usually makes the score worse. Only the image above the fold stays eager.
- Caching personalized pages unsafely. Caching a page that renders a paywall state, a subscription prompt or a live ad slot by mistake can show the wrong reader the wrong version. Purge deliberately instead.
- Treating AMP as the answer. AMP is still used by some publishers, but it is no longer the default shortcut it once was, and it does not fix ad-driven slowness on its own. If your AMP pages are still fast, fine — just do not expect it to solve the template.
- Adding heavy embeds mid-article. A single autoplaying video or a social widget above the fold can undo an entire day of image optimisation.
- Trusting a single test run. One PageSpeed Insights result is a sample, not a verdict. Compare runs and confirm with field data.
- Changing code without monitoring. If nothing measures performance after release, the site quietly returns to where it started within a few months.
- Waiting for a rewrite. Template-level fixes on an existing CMS capture most of the available gain. A rebuild is a decision about features and cost, not a speed strategy.
Frequently Asked Questions
Why is my news website so slow?
News pages combine many large images with many third-party scripts, which is a heavier combination than most sites carry. Ad, analytics, consent and tag-manager code is usually the biggest single contributor, followed by oversized images pushed straight from camera or agency feeds, and then server response time on a CMS that was not designed for constant publishing. A waterfall trace on your own article template will rank your causes in seconds.
Does page speed affect news site SEO?
Core Web Vitals are a confirmed Google page-experience signal, so a slow page is a ranking disadvantage rather than a neutral detail. The larger effect is usually indirect: readers on phones abandon slow stories, and every lost visit is lost ad impressions and a lost chance at subscription conversion. Treat speed as an audience and revenue metric first, and an SEO benefit alongside it.
What are good Core Web Vitals scores?
Aim for LCP at 2.5 seconds or less, INP at 200 milliseconds or less, and CLS at 0.1 or less. Those are the good thresholds; anything between those values and the next tier needs work. INP replaced FID as a Core Web Vital in March 2024, so ignore any guidance still built around the older metric. Judge yourself on the 75th percentile of real user data, not a single lab run.
How do I lazy load ads without losing revenue?
Reserve the ad slot’s exact dimensions in the layout, then load the ad code only when that slot approaches the viewport. Because the space is already reserved, ads still land where they did before, so viewability and fill rate stay close to their previous level. Keep anything above the fold loaded normally, and test on a real article with real ad demand before rolling it out sitewide.
Is AMP still worth it for news publishers?
AMP is no longer the default answer it once was, and publishers report mixed results on pages that stay ad-supported. If your AMP templates load fast and your measurement confirms it, there is no reason to remove them. For most sites the same engineering effort spent on the normal template, images and third-party scripts now produces more benefit, because AMP does not address ad latency or your base page weight.
Should I rebuild my news CMS or optimize what I have?
Optimize what you have first. On a legacy WordPress newsroom, cutting image bytes, deferring tags, fixing caching and trimming unused plugins regularly removes several seconds without a migration. Rebuild only when the CMS itself cannot meet functional needs, when a plugin has no maintained path forward, or when the server and hosting cost more than a managed platform would. Judge it on features and operating cost, not on speed alone.
Conclusion
Start where the reading happens, not where the team worries. Measure the homepage, the article template and the mobile experience for real users, then look at the heaviest third-party scripts and the largest images on that article page. Those two lists contain most of what you can recover, and both can be tested in a staging environment before anything goes live.
If you do only one thing this week, run a waterfall trace on your most-read story. It takes ten minutes and it usually ends the argument about what to fix first.
