Pagespeed & Core Web Vitals

I make your website faster and more stable, measurably. Specifically, I analyze your load time and Core Web Vitals, optimize images and media, improve code, scripts, and caching, lift the mobile performance, and reduce disruptive layout shifts. I prove the effect with a before/after measurement, so the progress is visible. Fast pages lose fewer visitors, rank better, and are at the same time captured more reliably by AI crawlers. Speed thus pays into your success several times over, and that is exactly where I start specifically, instead of blindly turning knobs.

I start with a thorough measurement of your load time and Core Web Vitals to find the biggest bottlenecks. Then I prioritize the measures by effect and effort; often a few levers bring the biggest jump. Next, I implement the optimizations cleanly, from images through code to delivery, in the vast majority of cases without a relaunch. Finally, I measure again and present the progress in a direct before/after comparison. This way you see in black and white what has improved, instead of having to rely on a vague “feels faster”.

Core Web Vitals are a group of metrics with which Google evaluates the user experience of a page, above all in terms of load speed, stability, and responsiveness. They consist of three metrics: LCP for the load time of the main content, CLS for the visual stability, and INP for the response speed to inputs. These values factor in as a ranking signal and directly reflect how a page feels for real users. I optimize your page specifically for these three measures, because they make measurable what would otherwise only be a gut feeling.

LCP measures how long it takes until the largest visible content of a page is loaded, usually a large image, a heading, or a central block of text. This value shows when a user has the impression that the page is really there. An LCP of around 2.5 seconds or less counts as good. Common causes of a poor LCP are large, uncompressed images, slow servers, or blocking resources. I improve the LCP by solving exactly these bottlenecks, so the main content appears quickly and visitors do not drop off before the page is even there.

CLS measures the visual stability of a page, that is, whether content jumps unexpectedly while loading. You know it when you want to click something and at the last moment a late-loaded image or an ad shifts everything. Such jumps are annoying and lead to misclicks. A CLS value of at most 0.1 counts as good. Typical causes are images without fixed dimensions, late-loaded elements, or fonts. I eliminate these triggers by assigning fixed placeholders and sizes, so your page loads calmly and stably, instead of jumping around before the user’s eyes.

INP measures how fast a page reacts to user inputs, for example to a click, a tap, or the opening of a menu. The value captures the delay until something visibly happens, and thus stands for the perceived smoothness of operation. INP has replaced the former metric FID and counts as good at around 200 milliseconds or less. High values often arise from too much or inefficient JavaScript that blocks the browser. I improve INP by slimming down and optimizing heavy scripts, so your page feels noticeably responsive.

Speed is both a direct ranking signal and a lever via user behavior. Google factors the Core Web Vitals into the evaluation, so it prefers fast, stable pages. At the same time, users leave slow pages again more often than average, which indirectly also feeds back on visibility. Speed is no panacea here, but a foundation: even the best content gives away potential if the page loads agonizingly. That is why I ensure technology and speed carry your content instead of slowing it down, an often underestimated but worthwhile lever.

Very directly: every additional second of waiting costs visitors and thus potential inquiries. Anyone who hits a slow page is quickly gone again, often before there is even anything to see. Especially on the smartphone and with impatient users, speed decides whether a click becomes an inquiry. A fast, stable page keeps visitors, creates a professional impression, and lowers the hurdle to making contact. Performance optimization is therefore not only a technical topic, but pays directly into your revenue, getting more out of the same visitor stream.

Yes, and that is often overlooked. Fast, technically clean pages are also captured more reliably and completely by AI crawlers. If your page loads slowly or content appears only late via scripts, there is the risk that a crawler does not catch everything, and what is not captured, an AI cannot cite or recommend. Good performance therefore ensures that your content reliably reaches the AI systems in the first place. Speed is thus also a building block of your AI visibility, which I deliberately keep in mind instead of treating it in isolation as a pure SEO topic.

There are freely available options to get a first impression, however most show only lab values and not what your real visitors experience. It only becomes meaningful when you consider lab and field data together and interpret them correctly. Exactly this well-founded measurement and its classification I take on for you.

Lab data arise in a controlled test environment, for example a single test with set conditions. They are good for finding problems and checking measures, but do not represent the whole reality. Field data, by contrast, stem from real visitors with different devices and connections and show how fast your page actually is for the people Google evaluates. Both complement each other: lab data for targeted optimizing, field data as a benchmark for real success. I include both, so we do not just improve a test value, but the real user experience.

The most common bottlenecks are large, uncompressed images and media, too much or inefficient JavaScript, missing or poor caching, a slow server, and many external third-party scripts. Unoptimized fonts and overloaded page templates also cost speed. Often several smaller problems add up to a noticeably slow page. The good thing about it: exactly these causes can be tackled specifically, and usually a few measures bring the biggest jump. In the analysis, I find out which bottlenecks have the strongest effect at your end and solve them in the order of their effect.

Images are often the biggest lever, because they cause a lot of load time. I ensure they are delivered in the right size and in modern, economical formats, compress them without visible loss of quality, and load content only when it is needed. I also handle large background graphics and videos specifically. This way the page stays visually appealing but loads much faster. Unlike content-related image optimization, this is purely about speed and stability, that is, ensuring heavy media do not slow your page down, without the presentation suffering for it.

Caching means that certain content is cached instead of generating or loading it completely anew on every call. As a result, pages appear much faster for returning visitors and for frequently retrieved content, and your server is relieved. There are various levels, from the visitor’s browser through the server to upstream services. Correctly set up caching is one of the most effective and at the same time most invisible speed levers. I configure it to suit your system, so your page loads faster without visitors getting to see outdated content.

Code and scripts strongly decide how fast a page becomes usable. So-called render-blocking is problematic: if the browser first has to load extensive scripts or stylesheets before it displays anything, the user waits unnecessarily. Too much JavaScript also burdens responsiveness. I slim down and prioritize the code, load non-critical scripts with a delay, reduce unnecessary third-party scripts, and ensure the most important things appear first. This way your page becomes not only faster overall, but also feels operable earlier, which directly translates into better values and more satisfied visitors.

It is decisive today, because a large part of visitors come via the smartphone, and Google evaluates pages predominantly in their mobile version. On mobile devices, the conditions are often harder: weaker connections, less computing power, smaller screens. A page that runs briskly on the desktop can still be sluggish on mobile. That is why I check and optimize the performance specifically for mobile devices, from image delivery to script load. Anyone who is slow on mobile loses visitors and rankings exactly where most people search today, and that is exactly what I prevent.

Yes, the server is the basis of every performance. A slow or overloaded server already delays the first response before images or code even come into play, which is felt directly in the LCP. The location of the server and the delivery via upstream networks also play a role. Some speed problems can be solved by better hosting or optimized delivery alone. In the analysis, I check whether your server is a bottleneck and give you a clear assessment of whether optimizations are enough or whether better hosting is worthwhile for you.

No, and I say that openly: speed is an important factor, but only one of many. A lightning-fast page with weak content will not come to the top through speed alone. Conversely, excellent content gives away potential if the page loads agonizingly. Performance therefore works above all as a foundation and in interplay with good content, clean technology, and authority. Anyone who promises you to reach the top through pagespeed optimization alone is exaggerating. That is why I classify speed realistically and combine it with the other levers, instead of overstating it.

As orientation, the thresholds of the Core Web Vitals apply: an LCP of around 2.5 seconds or better, a CLS of at most 0.1, and an INP of about 200 milliseconds or less. These values should be reached for the real visitors if possible, not just in the lab test. More important than a perfect score, however, is that the page feels fast and stable for your users and is better than that of the competitors. That is why I aim for solid values in the green range, without chasing the last point when it no longer brings any real benefit.

Once optimized unfortunately does not mean fast forever. New content, additional images, further plugins, or tracking scripts can worsen the load time again over time, often creeping, without it being noticed immediately. Rebuilds of the page can also undo hard-earned values. That is why it makes sense to check the performance occasionally and to measure again with larger changes. I document the implemented measures so they stay comprehensible, and on request keep an eye on the values, so your page stays permanently fast instead of falling asleep again after months.