A slow website is a silent cost that never shows up on invoices: a customer from Bydgoszcz clicks on your company in Google, waits a few seconds, goes back to the results and picks a competitor. That is why WordPress site speed in Bydgoszcz is not a matter of developer ambition but of sales and visibility. In this guide we show how to measure it, what usually slows WordPress down and how to fix it step by step.
Google assesses user experience through Core Web Vitals, among other things: three metrics covering how fast the main content loads, how responsive the page is to clicks, and how stable the layout is. A slow site can waste everything you have put into SEO and advertising.
Why a slow site costs a business customers and rankings
There are two mechanisms and both work in parallel. The first is human behaviour: the longer people wait for the first content, the more often they give up, especially on a phone and with a weaker signal. For a clinic in Fordon or a shop in Śródmieście, most visits come from mobile anyway.
The second mechanism is Google. Core Web Vitals are part of the “page experience” assessment. We do not promise specific rankings, because they depend on competition and time, but speed is one of the few factors you fully control. We write more about the ranking process itself in the article on data-driven SEO for websites in Bydgoszcz.
Core Web Vitals: three thresholds worth knowing
Google uses the following thresholds for a “good” rating:
- LCP (Largest Contentful Paint) up to 2.5 s – the time after which the largest element of the first screen is visible, usually a photo or a large heading.
- INP (Interaction to Next Paint) up to 200 ms – how quickly the page reacts to a click, tap or typing. INP replaced the earlier FID metric.
- CLS (Cumulative Layout Shift) up to 0.1 – how many elements “jump” during loading, for example a button pushed down by a late-loading banner.
You will find the metric definitions in the web.dev documentation on Core Web Vitals.
Lab data and field data: why the results differ
The most common surprise for site owners: PageSpeed shows 95 points, yet Search Console says the site has problems. That is not a bug, just two different kinds of data.
Lab data is a one-off test under controlled conditions (Lighthouse in PageSpeed Insights): great for finding causes and “before and after” comparisons, but it is a simulation of a single device. Field data is measurements from real Chrome browsers over several weeks (the CrUX report), visible in Search Console. The lab is for diagnosis, and the field is for judging whether the problem really exists.
Diagnostics step by step
Before you install anything, measure.
- Take a baseline measurement. Run PageSpeed Insights separately for mobile and desktop, for the home page and two or three of the most important subpages (service, contact, a product in a shop). Record LCP, INP, CLS and server response time.
- Check the field data in Search Console, in the “Core Web Vitals” report.
- Find the largest LCP element. PageSpeed points it out directly. Very often it is an unoptimised image in a slider or background.
- Review the “Network” tab in the browser’s developer tools. Look for heavy files, external scripts and a long time to first byte (TTFB).
If you want a quick, free starting point, use our free SEO audit. Among other things, it checks performance based on PageSpeed. A fuller picture (SEO, security, GDPR, accessibility, performance) comes from the Full Website Audit for 150 PLN, with results in a few minutes.
Hosting for a Bydgoszcz business and the PHP version
No plugin will fix a server that responds after a second. If TTFB is high despite caching, the problem lies in the hosting: an overloaded server, a slow disk or too few resources.
What to look for when choosing hosting for a company website in Bydgoszcz and the surrounding area (Toruń, Inowrocław, Nakło, Solec Kujawski):
- a server in Poland or Europe, with SSD/NVMe disks,
- the ability to choose a current, supported PHP version,
- object cache support (Redis or Memcached) if you run a shop,
- automatic backups and easy restoring.
The PHP version matters a lot: newer, supported releases are usually noticeably faster than old ones and receive security patches. Test the site on staging before upgrading the version. More in the guide to WordPress site security.
Cache: page and object
Page cache
By default, WordPress runs PHP and queries the database on every visit. Page cache saves the finished HTML and serves it without that effort, which usually shortens response time considerably. It is the most worthwhile first step (do not enable two cache plugins at once).
Object cache
Redis or Memcached store the results of frequently repeated queries. This helps especially in the admin panel, in search and in WooCommerce, that is, wherever full page cache cannot work.
Images: the most common culprit of poor LCP
Heavy photos uploaded straight from a phone are the most common reason for a slow home page. What to do:
- Match the dimensions to where the image is used.
- Use modern formats – WebP and, where possible, AVIF – which are smaller than JPEG at the same quality. WordPress supports WebP natively.
- Add width and height attributes (or aspect-ratio), so that the browser reserves space and does not cause layout shifts (CLS).
- Enable lazy-load for images below the first screen (loading=”lazy”). Do not apply it to the LCP image, though.
- For the LCP image, apply priority: fetchpriority=”high” or <link rel=”preload”>.
Fonts: local and with font-display
Fonts from external servers add connections and can be a source of text flicker. Host font files locally (WOFF2 format), limit the number of typefaces and weights to those you really use, and add font-display: swap (or optional) to the declaration so that text is visible straight away.
CSS and JavaScript: less, later, smarter
The browser will not paint the page until it has processed render-blocking CSS and scripts. Typical actions:
- Critical CSS – inlining the styles needed for the first screen in the page code, with the rest loaded asynchronously.
- Deferring and delaying scripts (defer, loading after interaction) for elements that are not needed straight away: chat, social widgets, advertising pixels.
- Removing unused code – many plugins load their styles and scripts on every subpage, although they work on only one. It is worth disabling them conditionally.
- Controlling external scripts – every additional one is a cost for INP and LCP.
Plugins and theme: a lightweight custom theme or a page builder
The number of plugins is not a problem in itself; what matters is quality and what each one loads. Remove unused ones and measure the impact of the rest. The theme matters even more: universal themes with page builders load a huge amount of CSS, JavaScript and markup, because they have to handle thousands of scenarios your site will never use.
That is why we build our own lightweight WordPress themes, designed for a specific company rather than a ready-made template with a hundred unnecessary options. In our offer, every subpage is optimised for SEO and Core Web Vitals already at the code level. Content is still edited in the visual WordPress editor, and the code remains your property. See what the scope looks like in the services offer and examples on the page with our case studies.
Database: housekeeping that pays off
Over time the database bloats: revisions, expired transients, spam, leftovers from deleted plugins. Make a backup, limit revisions, clear unnecessary data and check the autoloaded options (autoload), because an excess of them lengthens every request.
WooCommerce: basket and checkout without cache
The basket, checkout and customer account pages are dynamic and unique to each user, so they must be excluded from page cache. Otherwise errors appear, such as an empty basket.
- Check that the “cart fragments” script is not loaded on every subpage if it is not needed.
- Use object cache (Redis) for a larger catalogue.
We write more about running shops in the article on using WooCommerce in online shops, and you can check the state of your shop with the WooCommerce shop health tool.
Mobile-first: measure the way the customer sees it
Google indexes sites primarily in their mobile version, and phones have weaker processors. Test in mobile mode, ideally on an older phone as well. More on local visibility in the text on local SEO for Bydgoszcz businesses.
The most common problems: a table
| Problem | Symptom | Typical fix |
|---|---|---|
| Slow server or outdated PHP | High TTFB, slow admin panel | Better hosting, current PHP version, object cache |
| Heavy images | Poor LCP, long loading of the first screen | WebP/AVIF, correct dimensions, preloading the LCP image |
| Missing image dimensions and late-loading ads | Elements “jump”, high CLS | Width/height attributes, reserved space for banners |
| Fonts from external servers | Flickering or invisible text | Local WOFF2 fonts, font-display: swap, preload |
| Render-blocking CSS and JS | White screen before content appears | Critical CSS, defer, removing unused scripts |
| Heavy external script (chat, pixels) | High INP, delayed reaction to clicks | Delayed loading, fewer tags |
| Elaborate page builder and universal theme | Large DOM, a lot of unused CSS | Slimming down settings or a lightweight custom theme |
| Bloated database | Slow queries, long page generation time | Clearing revisions and transients, autoload control |
| Cache on the WooCommerce basket and checkout | Basket errors, empty checkout | Excluding these pages from cache, checking fragments |
Monitoring after launch
Every new plugin, banner or campaign can make the result worse. That is why, after launch:
- check the Core Web Vitals report in Search Console every month (the data lags by a few weeks),
- test plugin updates on staging first.
With us, after a project starts, the first month of support (updates, minor changes, monitoring) is included in the price, and afterwards you can choose an optional SLA agreement. You will find Google’s search documentation in Google Search Central.
Frequently asked questions
How fast should a WordPress site be for Google to rate it well?
Aim for the Core Web Vitals thresholds: LCP up to 2.5 s, INP up to 200 ms and CLS up to 0.1, measured on field data. More important than a single number in PageSpeed is whether most real users fall within these limits.
Why does PageSpeed give a different result than Search Console?
PageSpeed shows a lab test of a single device, while Search Console shows field data from real visits over several weeks. The lab is for diagnosis, and field data is for assessing the actual state.
Is installing a cache plugin enough to speed up a site?
It is often a good start, but rarely the whole answer. Cache will not fix heavy images, external scripts or slow hosting. The best results come from a combination: a good server, cache, lightweight images and control of scripts.
Does a page builder always slow a site down?
Not always, but it usually adds code that has to be optimised. A lightweight custom theme starts with less code, so it is easier to maintain good metrics.
How can I speed up a WooCommerce shop?
Exclude the basket, checkout and customer account from page cache, take care of good hosting, object cache and lightweight product images. Test changes on staging.
How long does speed optimisation take and how much does it cost?
It depends on the state of the site, theme, plugins and hosting. After a short conversation and a review of the site, we prepare a fixed-price quote. You can also do an indicative calculation in the online calculator.
Let’s talk about your site’s speed
If your website loads slowly or you do not know exactly what is slowing it down, book a free conversation with us (30–60 minutes, no obligation). We will go through the results, point out the biggest problems and propose a fixed-price quote. You can also start with the free SEO audit or write to us via the contact form.
Kreatywna Agencja (Canpol Bis Sp. z o.o.)
ul. Gimnazjalna 2, 85-007 Bydgoszcz
tel. +48 502 811 949
e-mail: biuro@kreatywnaagencja.com.pl
kreatywnaagencja.com.pl
