Technical SEO
Core Web Vitals
At the start, I gather information about the site, traffic data and implementation constraints in order to establish a realistic scope of work on Core Web Vitals. I establish whether it covers an audit, recommendations, implementation support and/or monitoring. Access, a test environment and the ability to publish and verify changes are required; without them I prepare recommendations only.
About the service
Defining and delivering Core Web Vitals work: audit, recommendations, support and monitoring
About the Core Web Vitals service
A few service details- Gathering data about the site
- Analysis of traffic and implementation constraints
- Defining the scope: audit or recommendations
- Preparing implementation tasks
- Implementation support on the test environment
- Monitoring metric trends after releases
Work process
The Core Web Vitals optimisation process: from diagnosis to implementation
- 01/ 03
Diagnosing the metrics
I take measurements, check TTFB and the response path, and identify render-blocking resources and sources of delay.
- 02/ 03
Backlog and priorities
I order the actions by impact on Core Web Vitals, number of users, cost and risk of regression, taking release dependencies into account.
- 03/ 03
Implementation and validation
I lead delivery from the backlog, define acceptance criteria and verify the changes on the indicated templates and representative URLs.
Start and defining the scope of Core Web Vitals work
The start of the cooperation consists of gathering information about the site and establishing what scope of work on Core Web Vitals makes sense and is feasible. At this stage, traffic data for the site is collected, along with information on implementation constraints that may affect the course of the work. I also establish whether the work is to cover an audit, recommendations, implementation support and/or monitoring. As a result, the next steps can be matched to the real options for publishing changes and verifying them afterwards.
In practice, defining the scope aligns expectations on both sides and defines what the outcome of the work will be. If the priority is diagnosis, the focus shifts to measurements and identifying problems on key pages and templates. If the goal is also to improve the metrics, the scope includes preparing implementation tasks and supporting the team responsible for implementation. The monitoring option involves recurring checks of metric trends and catching new problems after successive releases.
Key requirements: access and test environments
The key requirement for work on Core Web Vitals is the right access and environments that make it possible to test and verify changes. Depending on the agreed scope, access to the code or the ability to make changes is needed, as well as a test environment. The ability to publish and verify changes is also important, in order to confirm the impact of the implementations on the selected pages and templates. These conditions determine whether the work can go beyond analysis and recommendations.
In this mode I focus on the diagnosis and on preparing recommendations that can be handed over for implementation at a later date. Where environments are available, it is possible to refine the solutions with the implementation team and to check the implementation on the test environment. Agreeing access at the outset avoids a situation in which the prepared actions cannot be checked in practice.
Inventory of templates and key pages
The inventory of templates and key pages consists of identifying the page types that generate most of the visits and conversions, and then selecting representative URLs for measurement. At this stage I organise the structure of the site in terms of templates, so that the analysis is based on the areas that really matter rather than on individual, atypical pages. The sample includes both the key pages and the typical views that recur across the site. The result is a list of templates and a set of URLs that will be the basis for further measurements and diagnosis.
In practice, the selection of representative URLs is intended to capture patterns of problems that may recur within a given template. As a result, the later conclusions and recommendations can be assigned to specific page types rather than only to individual URLs. The selection covers the pages where the expected impact of changes on the metrics will matter most from the users’ perspective. Such an inventory also makes it easier to check later whether the fixes introduce regressions on the most important views.
Baseline measurement and field data analysis
The baseline measurement and field data analysis consist of collecting pre-implementation results for the selected pages and templates and indicating where the problem is greatest. I take the baseline measurements on the previously selected URLs, in order to have a reference point for validating changes later. In parallel, I establish whether the problems are concentrated on specific page types, devices or in particular countries. This arrangement makes it possible to tell straight away whether the difficulties are local (e.g. one template) or cut across a larger part of the site.
Field data analysis covers data from real user visits, where available, and makes it possible to identify the most problematic segments. As part of the segmentation I check the differences between mobile and desktop, the impact of slower connections and whether the problems cluster on specific templates. If there is little field data, the conclusions and decisions rely more heavily on lab tests, and changes in field data may become visible with a delay. As a result, the baseline measurement is not a one-off “score”, but an organised diagnosis of the areas that need further work.
Analysis of lab tests and the LCP, INP and CLS metrics
The analysis of lab tests and the LCP, INP and CLS metrics consists of taking measurements under controlled conditions for selected pages and mapping the elements that affect the results. As part of the diagnosis I identify render-blocking resources and the dependencies that delay the start or the course of rendering. I also check TTFB and the response path, assessing the impact of caching, the backend and external connections on the time at which rendering starts. This makes it possible to move from the metric values alone to specific technical causes at the level of templates and components.
In the metrics part, I verify LCP by identifying the largest rendered element (e.g. an image, banner or heading) and establishing what delays its display. I analyse INP in terms of interaction delays, including long JavaScript tasks, main-thread blocking, delayed event handling and heavy scripts. I diagnose CLS by finding the sources of layout shifts, such as images without dimensions, injected elements, late-loading fonts and ads or iframes without reserved space. I combine the measurement results with an analysis of images and media, fonts and icons, and third-party scripts, in order to indicate what to optimise, defer or limit.
- Identifying critical CSS/JS and a suboptimal loading order, with an indication of the resources to move, defer or limit.
- Assessing images and media in terms of dimensions, compression, responsive versions, off-screen loading and the loading priority of elements in the LCP area.
- Checking font loading, delays and flickering and the impact of fonts on CLS, with recommendations for reducing variants and improving the loading strategy.
- Assessing the impact of integrations (tags, widgets, trackers) on LCP and INP and indicating the elements to defer, load conditionally or remove.
Prioritising actions and the implementation plan
Prioritising actions and the implementation plan mean arranging the recommendations in order of delivery, so that the problems with the greatest impact and an acceptable risk are addressed first. The list of actions is ordered by impact on Core Web Vitals, the number of users affected by the problem, the cost of implementation and the risk of regression. I also take release dependencies into account, because some changes need to be coordinated with the publication cycle. In addition, I divide the work into quick fixes and changes that require development work.
The outcome of the planning is a backlog of implementation tasks, prepared so that it can be picked up directly for delivery. Each task contains a description, a priority and acceptance criteria, that is, the way to check whether the change has been implemented correctly. In the backlog I assign the tasks to specific metrics and indicate which templates and/or URLs they concern. This format makes it easier to run the implementations and to validate them later on the key page types.
- Dividing the actions by impact on the metrics, risk and effort, taking implementation dependencies into account.
- Recording in the backlog how each task relates to LCP, INP or CLS, and indicating the templates and representative URLs for verification.
- Defining acceptance criteria (how to check), to make it possible to control the implementation and limit the risk of regression.
Testimonials
What clients and the industry say
Feedback from clients and industry people I have worked with on SEO projects.
I had the chance to work with Kuba at Kulturalnie o SEO, an event I organise. Kuba did a great job as a speaker and received high marks from the audience. He showed professionalism and broad knowledge. In other projects at Vestigio, Kuba shows enormous commitment, a willingness to explore and implement new ideas, and excellent organisation of his work.
01 / 08
You talk to me, not a salesperson
Tell me what you want to achieve. I’ll reply personally
I work as a freelancer: the same person reads your message, prepares the quote and then runs the project. No sales team in between.