Technical SEO and Site Speed Optimization: A Complete Guide to Meeting Google's Performance Standards

If your Google PageSpeed Insights report is flashing red warnings or your Search Console's "Not Indexed" section keeps growing, you're not alone. The majority of SME websites in Turkey run on server infrastructure not optimised for mobile network speeds — uncompressed images, render-blocking resources and oversized JavaScript bundles are the norm. The consequence: Google's crawler flags pages as slow, organic rankings fall, and visitors hit the back button before the page finishes loading. This guide walks through every measurable layer of technical SEO — from Core Web Vitals thresholds and server response times to JavaScript rendering pitfalls and structured data — with concrete, actionable fixes at each step.

What Are Core Web Vitals and What Are the Threshold Values?

Google officially added Core Web Vitals as a ranking signal in 2021. These metrics quantify real user experience and are measured using field data — actual visitor sessions — rather than controlled lab tests. The three metrics are LCP (Largest Contentful Paint), INP (Interaction to Next Paint) and CLS (Cumulative Layout Shift). As of March 2024, INP permanently replaced FID (First Input Delay). Teams whose dashboards still reference FID are tracking an obsolete metric and should update their monitoring.

LCP measures how long it takes for the largest visible content block — typically a hero image or a large heading — to render on screen. Google's "Good" threshold is under 2.5 seconds; anything above 4 seconds falls into the "Poor" category. INP measures the delay between a user interaction (click, tap, keypress) and the browser's next visible response, with 200 milliseconds as the "Good" ceiling. CLS measures how much page elements shift unexpectedly during load; a score below 0.1 is "Good", above 0.25 is "Poor".

• LCP — Good: <2.5 s / Needs Improvement: 2.5–4.0 s / Poor: >4.0 s
• INP — Good: <200 ms / Needs Improvement: 200–500 ms / Poor: >500 ms
• CLS — Good: <0.1 / Needs Improvement: 0.1–0.25 / Poor: >0.25

Image Optimisation: The Highest-Impact First Step

Images typically account for more than sixty percent of total page weight. That makes image optimisation the quickest win for most sites. Modern web formats WebP and AVIF deliver roughly 25–35% and 50% smaller file sizes respectively compared with JPEG at equivalent quality, according to web.dev benchmarks. Sites built on Next.js, Gatsby or similar frameworks can automate this conversion natively; WordPress-based sites have equivalent plugins such as Imagify or ShortPixel.

Correctly sizing images is equally important. Serving a 1920-pixel-wide product photo inside a 400-pixel container wastes data on every load. Adding srcset and sizes attributes lets the browser choose the appropriate resolution for the current viewport. The loading="lazy" attribute defers off-screen images so they don't block the initial render. However, the LCP image — the largest element visible on page open — must never be lazy-loaded; instead, mark it with fetchpriority="high" and add a preload link element in the document head.

• Convert JPEG/PNG assets to WebP or AVIF
• Set explicit width and height attributes on every image to prevent CLS
• Add loading="lazy" to all below-the-fold images
• Add fetchpriority="high" and a preload link tag to the LCP image
• Match the maximum rendered size with srcset/sizes descriptors

Render-Blocking Resources, Critical CSS and Font Loading

Before a browser can paint anything, it must download and parse every CSS file and every synchronous script declared in the document head. This is render-blocking, and it directly delays LCP. The first layer of the fix is to load JavaScript with async or defer: async tells the browser to download the script opportunistically and execute it as soon as it arrives; defer guarantees execution in order after the DOM is ready. Third-party scripts that aren't critical to first paint — chat widgets, secondary analytics — can be further deferred using a facade pattern or loaded via type="module".

On the CSS side, the concept of "critical CSS" matters: inline the styles needed to render the above-the-fold content directly in the HTML head, then load the remaining stylesheet asynchronously so it no longer blocks rendering. For web fonts — especially Google Fonts — font-display: swap prevents invisible text (FOIT) and minimises the flash of unstyled text (FOUT). Self-hosting fonts eliminates the DNS resolution latency for external font domains and almost always results in faster delivery.

Poor INP scores typically trace back to long tasks: JavaScript blocks that occupy the main thread for more than 50 milliseconds delay every user interaction. The Chrome DevTools Performance panel visualises long tasks with a red corner marker. On React or Vue sites, unnecessary re-renders, large synchronous state updates and unoptimised event handlers are the primary suspects. Code splitting and route-based lazy imports reduce the amount of JavaScript parsed and executed on initial load, which directly lowers interaction latency.

CDN, Caching and Improving Server Response Time (TTFB)

TTFB (Time to First Byte) is the interval between the browser's initial HTTP request and the server's first byte in response. Google recommends keeping it under 800 milliseconds. High TTFB typically has three root causes: an overloaded or geographically distant server, slow database queries, or dynamically generated pages served without caching. A substantial portion of SME websites in Turkey are hosted on overseas servers, which alone can add 200–400 ms of round-trip latency.

A Content Delivery Network (CDN) caches static assets — images, CSS, JavaScript, fonts — on servers geographically close to users, reducing both TTFB and total load time. Cloudflare, BunnyCDN and similar services operate Points of Presence (PoPs) in or near Turkey. On the server, enabling HTTP/2 or HTTP/3 allows multiple requests to be multiplexed over a single connection. For browser caching, pair long Cache-Control durations (for example, one year) on static files with URL fingerprinting (for example, main.abc123.js) so cached files are invalidated precisely when content changes.

• Choose a server or CDN with a Turkey or European PoP for Turkish traffic
• Implement page-level caching (Redis, Varnish, edge caching) to cut TTFB
• Apply Cache-Control: max-age=31536000, immutable to versioned static assets
• Verify HTTP/2 or HTTP/3 is enabled on your hosting stack
• Use Chrome DevTools > Network > Timing to isolate the TTFB component

Would You Like a Free Technical Analysis of Your Site?

ADWEBX has been delivering digital projects from Istanbul since 2009. We offer a free site analysis that maps your Core Web Vitals scores, render-blocking bottlenecks and technical SEO blockers in one structured report. You can submit a request in a few steps through our /analysis page. If you prefer a faster conversation, our WhatsApp consultation line is open — just send your question and we'll get back to you directly.

Technical SEO Fundamentals: Crawlability and Indexability

Even if your speed metrics are strong, organic rankings won't improve if Googlebot can't crawl and index your pages correctly. Crawlability and indexability are distinct concepts: Google may be able to reach a page (crawlable) but still choose not to include it in search results (not indexable). The robots.txt file signals which areas of the site crawlers should access; the XML sitemap provides a full list of URLs you want indexed. Both files need regular maintenance and should be validated through Search Console.

The canonical tag (rel="canonical") resolves duplicate content: on e-commerce sites where filter parameters generate dozens of URL variants for the same product (e.g. ?colour=red&size=M), Google without canonical guidance splits authority signals across all variants and the primary listing's ranking weakens. The hreflang attribute tells Google which page serves which language and region on multilingual sites, preventing cross-language duplicate content penalties. HTTPS is no longer optional; mixed content warnings (HTTP resources on an HTTPS page) cause resource blocking in modern browsers and erode trust signals.

• Validate robots.txt with the Robots.txt Tester in Search Console
• Submit your XML sitemap to Search Console and keep it up to date
• Ensure each canonical tag points to the correct canonical URL
• Implement hreflang for every language variant on every multilingual page
• After migrating to HTTPS, verify HTTP to HTTPS 301 redirects are in place
• Monitor 4xx errors and redirect chains in the Search Console Coverage report

Structured Data (Schema), Mobile-First and JavaScript Rendering Issues

Structured data (Schema.org markup) enables Google to understand your page content at a semantic level and unlocks rich results: star ratings, product prices, FAQ boxes, recipes, events. These directly influence click-through rate. JSON-LD is the preferred implementation format because it sits in the document head without touching the HTML body structure. Validate your markup with Google's Rich Results Test and the schema.org validator before deployment.

Google indexes the web using mobile-first indexing: regardless of how rich a page's desktop version is, if the mobile version is absent or serves different content, Google's index will reflect the mobile version's gaps. The majority of web traffic in Turkey arrives from mobile devices, making responsive design and mobile performance a higher priority for local SMEs than desktop optimisation.

JavaScript-rendered content is a serious risk factor. If your site generates content client-side (CSR), Googlebot sees empty HTML on its first visit and must schedule a second rendering pass — which may happen hours or days later. This delay slows indexing and some content may never be indexed. Server-side rendering (SSR) or static site generation (SSG) ensures Googlebot receives complete HTML on the first visit, providing a clear advantage for both indexing speed and ranking signals.

Measurement Tools: PageSpeed Insights, Lighthouse, Search Console and CrUX

PageSpeed Insights (PSI) is Google's free tool that provides both lab data and real-world field data. Lab data runs in a controlled virtual environment each time, giving fast and consistent feedback. Field data is sourced from the Chrome User Experience Report (CrUX): an aggregation of real Chrome users' experiences over the preceding 28 days. Field data is the metric Google uses as a ranking signal — a site scoring 100 in the lab can still have poor CWV in the field if real-world conditions differ substantially.

The Core Web Vitals report in Google Search Console shows which URL groups on your site are classified as Poor or Needs Improvement. After fixing the flagged issues, use the "Validate Fix" button to request Google's reassessment. Lighthouse can be run via Chrome DevTools or the Node CLI and audits performance, accessibility, an SEO checklist and best practices in one go. Running Lighthouse as part of your deployment pipeline is an effective way to catch performance regressions before they reach production.

• Run PageSpeed Insights separately for mobile and desktop
• Review the Search Console Core Web Vitals report weekly
• Run Lighthouse before every significant feature deployment
• Use the CrUX Dashboard Looker Studio template for site-wide trend monitoring
• Investigate large gaps between lab and field scores — third-party scripts and A/B testing are common causes

Where to Start: An Impact-Effort Prioritisation Framework

As the technical SEO checklist grows longer, it becomes harder to act on. In practice, the most efficient approach is to score each fix against two axes: expected ranking or speed impact, and implementation time and cost. For most sites, the highest impact-to-effort fixes are: converting images to WebP or AVIF, preloading the LCP image, eliminating render-blocking JavaScript and enabling server-side caching. These four steps applied together consistently produce measurable LCP improvements.

Medium-priority work — critical CSS extraction, font self-hosting, code splitting, canonical and hreflang audits — typically fits within a single developer sprint. Lower priority but not to be ignored: structured data enrichment, CLS fine-tuning and a third-party script audit. Misjudging priorities means the team spends time on changes that can't be measured. The measure-fix-validate loop is the only reliable way to move the needle consistently.

Running a full technical SEO audit in-house is time-consuming and carries a high risk of missed issues. ADWEBX offers a free site analysis that maps your complete technical picture — you can start from our /analysis page and receive a structured report identifying the specific blockers behind your ranking losses. For quicker conversations, our WhatsApp line is always open. Write us your question and we'll respond directly.

Frequently Asked Questions

My Core Web Vitals scores are poor but my rankings are holding — why should I bother?

Your current rankings may be sustained by strong offsetting signals such as authoritative backlinks and high-quality content. However, as competitors improve their technical performance, CWV scores act as a tiebreaker. More immediately, slow speed increases your bounce rate, meaning you're already losing conversions from traffic you've already won. In short: rankings can hold while revenue still leaks.

My LCP image is optimised but my score is still poor — what else should I check?

LCP is not solely determined by image file size. If TTFB is high, if render-blocking CSS or JS occupies the main thread before the image can load, or if the LCP image is discovered late (set via CSS background-image or injected by JavaScript rather than in the HTML), even an optimised image will load late. Use the Chrome DevTools Performance recorder to break down LCP into its component sub-parts: TTFB, resource load delay, resource load duration and element render delay.

Does Googlebot render JavaScript, and does that affect my site?

Yes, Googlebot can render modern JavaScript — but this rendering happens in a second wave that may arrive hours or days after the initial crawl. This delay meaningfully slows down the indexing of new content. If your site relies heavily on client-side rendering (React or Vue SPA), ensuring that critical content — the title, meta tags, main text — is present in the initial HTML response via SSR or prerendering directly improves both indexing speed and ranking performance.

Where should I start to improve my INP score?

Most INP problems originate from long JavaScript tasks. Record a performance trace in Chrome DevTools with Long Tasks enabled and identify any function taking more than 50 ms. On React-based sites, unnecessary re-renders, large synchronous state updates and blocking event handlers are the primary culprits. Practical solutions include task chunking via setTimeout, moving heavy computation to a Web Worker, and using the React Transition API to deprioritise non-urgent updates.

Which tools should I prioritise for a technical SEO audit?

For a starting point, Google Search Console (free, field data plus indexing status) and PageSpeed Insights (free, lab data plus CrUX) cover the fundamentals. For a broader site crawl, Screaming Frog SEO Spider (free up to 500 URLs) surfaces broken links, redirect chains, canonical errors and meta tag issues in one pass. If you'd rather run the audit with an experienced team, ADWEBX's free site analysis at /analysis delivers all of these checks in a structured, prioritised report.