Insights by Cortey Agency

Page speed stopped being an engineering vanity metric on 12 March 2024, when Interaction to Next Paint replaced First Input Delay in Google's Core Web Vitals. The new metric measures the entire latency of a click or a tap, from the input event until the browser paints the visual response. Sites that passed comfortably under the old metric started failing, because First Input Delay only counted how long the browser waited before starting work. It never counted how long the work took.

Thesis and method

The argument here stays narrow and testable. Core Web Vitals track revenue closely enough that a performance budget belongs in the commercial plan rather than at the bottom of an engineering backlog. Every figure below comes from either Google's published thresholds or a case study with measured before and after data. Nothing is modelled and no number is an estimate produced for this article.

The thresholds, exactly

Optimising the median leaves a quarter of real visits failing and the verdict unchanged. That single detail explains most of the distance between teams reporting good internal numbers and pages still carrying a failing assessment in Search Console.

What the field data shows

Correlation studies invite argument. Documented before and after cases are harder to wave away, because the same audience met both versions of the same site.

Bounce behaviour moves in the same direction. Google's mobile speed research found the probability of a bounce climbs 32 percent as load time goes from one second to three seconds, and 90 percent as it goes from one second to five seconds.

Where the milliseconds actually go

• Server response. Time to First Byte sets the floor under Largest Contentful Paint. No amount of front end tuning recovers a 1.2 second origin response.
• Render blocking resources. Every synchronous stylesheet and script in the document head delays first paint by its full download and parse time.
• Tag containers. Vendor scripts loaded through a tag manager are the most common cause of failing Interaction to Next Paint in the audits we run, because they occupy the main thread at exactly the moment a visitor is clicking.
• Long tasks. Any single task holding the main thread beyond 50 milliseconds blocks input handling, and four of them in sequence exceed the 200 millisecond limit on their own.
• Images without dimensions. One hero image served with no width and height attributes carries Cumulative Layout Shift past 0.25 with no other contributor.

Lab data and field data disagree for a reason

Lighthouse runs one simulated load on throttled hardware inside a controlled environment. The Chrome User Experience Report aggregates real visits from real devices on real networks. A Lighthouse score of 98 sitting next to a failing field assessment is not a contradiction, it is the difference between a laboratory and a street. Decisions belong to the field data. Lighthouse earns its place as the diagnostic that explains why the field data looks the way it does, and it cannot measure Interaction to Next Paint at all, because nobody clicks anything during a synthetic run.

A performance budget that survives a roadmap

1. Set the budget in field terms. Largest Contentful Paint under 2.0 seconds at the 75th percentile leaves headroom before the 2.5 second cliff.
2. Measure continuously. The web vitals JavaScript library reports real values into your analytics, so a regression surfaces within days instead of at the next quarterly audit.
3. Gate releases on two lab numbers, total JavaScript transferred and total main thread work. Those two predict most Interaction to Next Paint failures before a release reaches production.
4. Audit tags every quarter. Anything nobody reads a report from gets removed, and each removal buys main thread time back at zero engineering cost.
5. Convert the metric into money once. Take the current session count, conversion rate and average order value, then rerun the same arithmetic at the target threshold using the elasticities in the case study table.

Sources: Google Core Web Vitals documentation and the Chrome User Experience Report, web.dev case studies covering Vodafone, Rakuten 24 and The Economic Times, and the Deloitte Digital study Milliseconds Make Millions.

The engineering decisions that make these thresholds reachable are set out in the analysis of CRM and SaaS architecture, and the measurement layer that keeps the resulting revenue attributable is covered in attribution after the third party cookie.

Build against buy is the wrong question. Total cost of ownership across the useful life of the system is the right one, and it returns a different answer at 15 seats than it does at 60. What follows is one explicit model with every input published, plus the point where the two paths cross.

The subscription path

Seat pricing carries one property that never appears in a first year business case. It scales with headcount, so every hire raises the run rate, and a strong year on recruitment lands as a cost increase in a system nobody changed.

One line sits outside that table. Vendors raise list prices, and the increase arrives without a matching change in what the software does. Salesforce lifted list prices across several clouds by an average of 9 percent in 2023, the first broad increase in seven years. Applying a 5 percent annual escalation to the recurring lines adds roughly 52,000 euros to the five year total and moves nothing else.

The build path

Where the two paths cross

Headcount shifts that crossover further than any other input. Rerunning the same model at 22 CRM seats gives a five year subscription total of 370,100 euros against a build total of 369,400 euros, a gap of 0.2 percent and a rounding error in practice. Below 22 seats the subscription path wins on cost for the full five years and keeps winning. Above 40 seats the build repays itself inside two years.

What the model does not price

• Switching cost. Leaving a subscription platform after four years means exporting data shaped by that vendor's schema, and the export almost never carries the automation logic with it.
• Ceiling risk. Record limits, API call caps and workflow builders that cannot express your actual process are the usual reason a subscription platform ends up supplemented by spreadsheets.
• Roadmap risk. A vendor deprecating the feature your operation depends on is a real event with no engineering remedy available on your side.
• Key person risk on custom code. Software written by one contractor who then becomes unreachable costs more than any licence. Documentation, tests and a second pair of hands are line items, not extras.
• Speed to first value. A subscription platform runs on Monday. A custom build runs in five months, and that delay costs whatever the current process is costing.

A decision framework instead of a preference

The architecture behind the build column is described in architecting custom CRM systems and multi tenant SaaS platforms. Where the build replaces manual review rather than a licence, the relevant comparison sits in running AI agents on your own data.

Sources: the Salesforce list price increase announced in 2023 and published vendor seat prices for the tools modelled. Every euro figure in the tables is a model with its inputs shown in the table itself, not an invoice from a past project.

Most companies inherit a CRM that nobody designed for the way the business runs today. A different team configured it years ago, then extended it with workarounds that break under load. Now it sits in the middle of daily operations and quietly slows everyone down. Replacing it well is not a rebuild for its own sake. It is backend refactoring that strips out accumulated friction without disrupting the people who depend on the system every day.

The data model decides everything downstream

Architecture starts with the data model, not the interface. Isolation between client organizations has to hold at the schema and query layer before anyone designs a single screen, because retrofitting those boundaries after launch is where most internal platforms fail. We pair that with microservices that separate billing, permissions and core business logic into independently deployable parts. Change one part and you test one part, instead of the whole platform.

Front end speed decides adoption

On the front end we build with Next.js because internal tools live or die on responsiveness. A CRM that needs three seconds to open a customer record never gets adopted, no matter how correct the data underneath it is. Core Web Vitals matter here just as much as they matter on a public website. That performance discipline usually decides whether your team uses the platform or quietly drifts back to spreadsheets within six months.

The commercial case for building rather than licensing is worked through in the five year cost model, and the performance thresholds referenced above are set out in Core Web Vitals as a revenue metric.

Chrome kept the third party cookie. The announcement in July 2024 reversed four years of deprecation planning, and the April 2025 update confirmed that no separate opt out prompt would ship either. Attribution degraded across the same period anyway, because the mechanisms that actually broke it were never on Chrome's roadmap. Safari's Intelligent Tracking Prevention, consent obligations under European law, and the quiet shift of reporting from counted events to modelled ones did the damage between them.

Thesis and method

Two claims get tested here. First, the reporting gap most teams blame on cookie deprecation comes from cookie lifetime and consent instead, neither of which had anything to do with third party cookies. Second, server side tagging repairs exactly one of those two problems, so buying it as a compliance solution buys the wrong thing. Every mechanism below is documented behaviour published by a browser vendor or by Google, not a pattern observed in one account.

What actually expires, and when

Consent Mode is a data structure, not a banner

The banner collects a decision. Consent Mode transmits it. Four signals travel with every hit and each governs a different downstream use.

Implementation then splits into two shapes. Basic mode blocks the tags entirely until consent arrives, so a declined visit sends nothing at all. Advanced mode loads the tags in a denied state and sends cookieless pings that carry no identifiers, and those pings are precisely what makes modelling possible later. Choosing basic mode and then asking why the modelled conversions never appeared is a common and expensive sequence.

What modelling requires before it starts

Modelled data is not a switch anyone flips. Google publishes volume thresholds, and a property sitting below them simply reports the gap as missing traffic.

• At least 1,000 events per day carrying analytics_storage set to denied, sustained for at least seven days.
• At least 1,000 daily users sending events with analytics_storage set to granted, on at least seven of the previous 28 days.
• Consent Mode implemented in its advanced shape, since basic mode never sends the denied state pings the model trains on.

Small and mid sized properties frequently sit under the first threshold. For them the honest position is a stated coverage rate rather than a modelled total, because a number presented as measured when it is actually absent corrupts every decision built on top of it.

What server side tagging fixes, and what it leaves alone

A measurement stack that holds

1. Implement Consent Mode in its advanced form first. Everything downstream depends on the denied state pings existing.
2. Move tagging to a first party subdomain and set identifiers through an HTTP header, which restores cookie lifetime for Safari traffic.
3. Send server side conversions to advertising platforms through their conversion APIs, so campaign optimization keeps a signal even when the browser sends none.
4. Report a coverage rate next to every conversion figure. A number and its confidence belong on the same slide.
5. Hold one deterministic identifier of your own. A login, an order reference or a hashed email collected with consent outperforms every workaround.
6. Audit quarterly against a controlled purchase you make yourself, then trace it end to end through the reporting. The gap between what you did and what the dashboard says is the real measurement error.

Sources: WebKit Intelligent Tracking Prevention documentation, Mozilla total cookie protection documentation, Google Privacy Sandbox announcements from July 2024 and April 2025, and Google published requirements for Consent Mode and behavioural modelling in GA4.

The front end cost of vendor tags is quantified in Core Web Vitals as a revenue metric, and the organic side of the same growth problem sits in answer engine optimization and programmatic SEO.

Public AI interfaces prototype quickly, but plenty of real workflows rule them out. Contract review, internal knowledge retrieval and customer data handling all involve information you cannot send to an outside vendor. Open source language models such as Llama change that calculation. The model runs inside infrastructure you already control, so sensitive data never crosses a boundary your policies protect.

Where the boundary sits

Deciding between a self hosted model and a hosted API is a per workflow question, not a company wide policy. The split below is the one we implement most often.

Retrieval is the part that makes it useful

The model is rarely the hard part. What makes an internal agent useful is retrieval augmented generation, known as RAG, layered on top of it. We index your real internal documents, policies and knowledge bases into a retrieval system the agent queries before it answers. Responses then rest on your own documentation rather than whatever the model absorbed during training. For the connective work between systems, we write the integration directly against the platforms you already run, so every workflow carries an explicit contract that can be tested and versioned.

1. Extract and normalise the source documents, including the scanned ones nobody has opened since 2019.
2. Chunk on semantic boundaries rather than fixed character counts. Clauses and sections beat every 800 characters.
3. Embed and index, keeping a source reference on every chunk so an answer can point at a page.
4. Retrieve, then rerank. The first pass optimizes recall and the rerank pass optimizes precision.
5. Generate under an instruction to answer only from the retrieved context and to say so when the context is insufficient.
6. Evaluate against a fixed question set on every change, because retrieval quality drifts silently as the corpus grows.

Add a direct OpenAI API integration for the workflows where cloud inference is fine, and you get a practical split. Sensitive processes stay in house. Everything else uses the fastest model available. Privacy becomes a design decision instead of a patch applied later. The agent then absorbs approvals, data extraction and first pass customer replies, and it adds no new compliance risk while doing it.

Where an agent replaces licensed software rather than manual work, the cost comparison belongs in the five year build or subscribe model, and the systems an agent usually plugs into are described in architecting custom CRM systems.

Sources: published documentation for the OpenAI API and Claude, and the licences and model cards of the open source models named for self hosted deployments.

Search behaviour has moved from keywords typed into a box toward answers written by AI assistants. Technical SEO now serves a second audience beyond human readers, namely the language models that compress a page into a few sentences. That changes what good looks like. Structured data, headings that state exactly what follows, and sentences a model can quote without distorting your meaning all matter more than they did.

Two audiences, one page

Answer engines crawl under their own user agents, and each one feeds something different. Blocking the wrong one removes your business from an assistant that would otherwise recommend it.

What makes a page quotable

The GEO study presented at KDD 2024 tested nine content changes against a generative search engine and found that adding quotations, statistics and citations lifted source visibility by up to 40 percent, while keyword stuffing produced no measurable gain. The practical implications are narrow enough to list.

• One claim per heading, stated inside the heading rather than three paragraphs below it.
• A summary block near the answer that resolves the question in under 60 words, roughly the length an assistant lifts.
• Numbers with their unit and their source in the same sentence, because a figure a model cannot attribute tends to get dropped.
• Tables for anything comparative. Structured markup survives extraction far better than a paragraph listing five options.
• Structured data that matches the visible text word for word, since a mismatch invalidates the rich result rather than improving it.

Infrastructure still decides who gets read

At the infrastructure level this starts with pre rendered pages served as static files. Crawlers and answer engines then get your full content on the first request, with no client side rendering delay and no half built DOM. On a business site competing for long tail searches close to a buying decision, that completeness advantage compounds across every indexed page you own.

None of it counts if measurement breaks along the way. Browser privacy defaults keep tightening, so we move tracking to the server through GA4 and keep attribution intact without leaning on cookies from other domains. The traffic you win from answer engines then shows up in the numbers your team actually uses to decide where to invest next.

Sources: the GEO paper presented at KDD 2024, published crawler documentation from OpenAI, Anthropic, Perplexity and Google, and Google guidance on structured data eligibility.

The measurement side of this argument is worked through in attribution after the third party cookie, and the speed requirements behind pre rendering are quantified in Core Web Vitals as a revenue metric.