Mobile-First Website KMU: Was 2026 wirklich zähltMobile-First Website for SMEs: What Counts in 2026
Google bewertet Ihre Website aus Sicht des Smartphones. Hier steht, welche Werte 2026 gelten und was Sie am Handy konkret prüfen und verbessern können.Google judges your website from the smartphone's point of view. Here is which targets apply in 2026 and what you can check and improve on mobile.
Viele KMU-Websites sehen auf dem Laptop des Inhabers gut aus und am Handy der Kundschaft mittelmäßig. Das ist kein Schönheitsfehler: Google beurteilt die Seite aus Sicht des Smartphones, und dort entscheidet sich auch, ob jemand anruft oder wieder wegwischt. Dieser Artikel zeigt, was 2026 für „Mobile-First Website KMU“ tatsächlich zählt, was Sie selbst prüfen können und wo es sich lohnt, jemanden dranzulassen.
Was Mobile-First-Indexing konkret bedeutet
Laut Google Search Central verwendet Google „die mobile Version der Inhalte einer Website, gecrawlt mit dem Smartphone-Agenten, für Indexierung und Ranking“. Die Desktop-Version ist dafür nicht mehr die Referenz. Eine eigene Mobilversion ist zwar nicht Pflicht, wird aber ausdrücklich dringend empfohlen. Googles Leitfaden zum Mobile-First-Indexing nennt die Punkte, an denen KMU-Seiten am häufigsten scheitern:
- Gleicher Inhalt: Die Mobilversion soll dieselben Inhalte enthalten wie die Desktop-Version. Wer mobil Texte kürzt oder Abschnitte weglässt, riskiert laut Google Traffic-Verluste. Inhalte hinter Tabs oder Akkordeons sind in Ordnung, solange sie vorhanden sind.
- Nichts, was erst nach einer Geste lädt: Google lädt keine Inhalte, die erst durch Wischen, Klicken oder Tippen nachgeladen werden. Wichtige Texte und Bilder müssen ohne Interaktion im Code stehen.
- Gleiche strukturierte Daten und gleiche robots-Angaben: Schema-Markup und Meta-Robots müssen auf beiden Versionen übereinstimmen, sonst wird falsch indexiert.
Das ist auch für lokale Anbieter relevant, die über ihr Google-Profil und ihre Website gefunden werden wollen. Wie beides zusammenspielt, beschreibt unser Guide zu lokalem SEO im DACH-Raum.
Wie viele Ihrer Kundinnen und Kunden mobil unterwegs sind
Eine saubere Zahl für den Anteil „mobiler Suchanfragen“ in Österreich haben wir nicht gefunden, und die oft zitierte Pauschale von 70 Prozent lässt sich nicht belegen. Belegt ist dagegen, wie verbreitet das Smartphone als Zugang ist. Eurostat weist in der Erhebung zur IKT-Nutzung für 2025 aus, wie viel Prozent der Personen das Internet auf einem Handy oder Smartphone nutzten.
Anders gesagt: Für fast alle Menschen in Österreich ist das Smartphone ein normaler Zugang zum Netz, und nur rund 1,9 Prozent nutzten ausschließlich Desktop oder Laptop (Deutschland: 4,8 Prozent). Die Erhebung sagt nichts darüber, auf welchem Gerät jemand Ihre Branche sucht oder Ihr Formular ausfüllt. Das zeigt Ihnen Google Analytics, getrennt nach Gerätekategorie. Schauen Sie dort einmal nach, bevor Sie Prioritäten setzen.
Die Statistik Austria hat ihre IKT-Erhebung für 2025 am 23. Oktober 2025 veröffentlicht. In der Pressemitteilung steht unter anderem, dass 97 Prozent der 16- bis 64-Jährigen das Internet nutzen. Zahlen zur Smartphone-Nutzung enthält diese Veröffentlichung nicht, deshalb stützen wir uns für den Gerätezugang auf Eurostat.
Core Web Vitals 2026: Schwellenwerte und was dahinter steckt
Die drei Kennzahlen messen, wie Besucher Ihre Seite tatsächlich erleben. Laut web.dev gilt die Seite als „gut“, wenn mindestens 75 Prozent der Seitenaufrufe die Zielwerte erreichen, getrennt nach Mobil und Desktop. Google empfiehlt den Bericht in der Search Console, um das zu überwachen, und betont in seiner Dokumentation zur Seiten-Erfahrung zugleich: Gute Werte garantieren keine Spitzenplätze, Relevanz der Inhalte bleibt entscheidend.
| Kennzahl | Zielwert „gut“ | Typische Ursache bei KMU-Seiten | Erste Maßnahme |
|---|---|---|---|
| LCP | höchstens 2,5 Sekunden | Großes Hero-Bild, langsamer Server, Bild wird verzögert geladen | Bild komprimieren, nicht „lazy“ laden, mit fetchpriority hoch priorisieren |
| INP | höchstens 200 Millisekunden | Schwere Skripte, Chat-Widgets, Tracking-Tags, Slider | Skripte entrümpeln, nur laden, was gebraucht wird |
| CLS | höchstens 0,1 | Bilder ohne Größenangabe, Cookie-Banner, nachladende Schriften | Breite und Höhe angeben, Platz reservieren |
INP misst laut web.dev die Zeit von der Interaktion, also Tippen, Klicken oder Tastendruck, bis zum nächsten gezeichneten Bild, und zwar über die gesamte Verweildauer auf der Seite. INP ist seit März 2024 offizieller Bestandteil der Core Web Vitals. Für INP nennt web.dev die Stufen gut bis 200 Millisekunden, verbesserungswürdig bis 500 und schlecht darüber.
Touch-Ziele und der Telefon-Button
Am Handy bedient niemand mit einem Mauszeiger. web.dev empfiehlt in den Hinweisen zu Tippflächen eine Größe von etwa 48 geräteunabhängigen Pixeln mit rund 8 Pixeln Abstand dazwischen. Das gilt auch, wenn das sichtbare Symbol kleiner ist: Mit Padding wird die Fläche größer, ohne dass das Design plump wirkt. Die WCAG 2.2 verlangen als Mindestmaß (Stufe AA) 24 mal 24 CSS-Pixel, mit Ausnahmen für ausreichend Abstand, und empfehlen 44 mal 44 Pixel als strengere Variante.
Für Dienstleister mit Telefon- oder Terminanfragen ist ein Element besonders wichtig:
- Die Telefonnummer ist ein klickbarer
tel:-Link, nicht nur Text. - Der Button ist ohne Scrollen sichtbar und bleibt beim Scrollen erreichbar, etwa als schmale Leiste am unteren Rand. Das ist gut mit dem Daumen zu treffen.
- Er ist ein Button mit Beschriftung („Jetzt anrufen“), nicht ein Symbol ohne Text.
- Ein zweiter Weg (Kontaktformular oder Terminbuchung) steht daneben, für alle, die nicht telefonieren möchten.
Messen Sie die Klicks auf den Telefon-Button als eigenes Ereignis. Nur so sehen Sie später, ob eine Änderung etwas gebracht hat. Welche Hebel darüber hinaus Besucher zu Anfragen machen, haben wir in Conversion-Optimierung: die wichtigsten Hebel zusammengefasst.
Formulare, die am Handy funktionieren
Ein Formular ist der Ort, an dem mobile Besucher am häufigsten aufgeben. Die Hinweise aus den Formular-Empfehlungen von web.dev lassen sich auf Kontaktformulare übertragen:
- Passende Feldtypen verwenden:
type="email"undtype="tel"öffnen die richtige Tastatur. - Das Attribut
autocompletesetzen, damit der Browser Name und Adresse selbst einträgt. - Jedes Feld mit einem sichtbaren
<label>versehen. Ein Platzhalter allein verschwindet beim Tippen, und man vergisst, wofür das Feld war. - So wenige Pflichtfelder wie möglich. Name, Erreichbarkeit und Anliegen genügen meist für die erste Anfrage.
- Auf einem echten Gerät testen, nicht nur im verkleinerten Browserfenster.
Prüfen Sie außerdem, ob die Bestätigung nach dem Absenden eindeutig ist. Eine Seite, die nur „Danke“ sagt und nicht erklärt, wann Sie sich melden, erzeugt Nachfragen.
Bilder und Schriften: wo Sekunden verloren gehen
Bei den meisten KMU-Seiten bestimmt ein einzelnes großes Bild den LCP-Wert. web.dev zerlegt die LCP-Zeit in vier Teile: Server-Antwort (rund 40 Prozent), Ladeverzögerung der Ressource (unter 10 Prozent), Ladedauer der Ressource (rund 40 Prozent) und Darstellungsverzögerung (unter 10 Prozent). Der Großteil entfällt also auf den Server und auf das Bild selbst.
Bilder
- Moderne Formate wie WebP oder AVIF verwenden und Bilder in der angezeigten Größe ausliefern.
- Das Hero-Bild nie mit
loading="lazy"versehen. Für Bilder im sichtbaren Bereich empfiehlt web.dev das Standardverhalten, damit sie sofort geladen werden. Bei wahrscheinlichen LCP-Bildern hilftfetchpriority="high". - Allen Bildern
widthundheightmitgeben, damit das Layout beim Laden nicht springt. Dort, wo das Bild unterhalb des Sichtbereichs liegt, istloading="lazy"sinnvoll.
Schriften
- Nur WOFF2 einbinden und die Zahl der Schriftschnitte klein halten. Systemschriften oder eine variable Schrift sparen Dateien.
- Mit
font-displaybewusst festlegen, was bis zum Laden angezeigt wird, und eine ähnliche Ersatzschrift definieren, damit der Text nicht umspringt. - Mindestens 16 Pixel Fließtext. Das ist eine übliche Praxisregel, keine Google-Vorgabe; kleinere Schrift ist am Handy schlicht anstrengend zu lesen.
Pop-ups sind der vierte Klassiker. Google zählt aufdringliche Interstitials zu den Dingen, die man bei der Seiten-Erfahrung vermeiden sollte. Ein Cookie-Hinweis, der den halben Bildschirm blockiert, schadet der Nutzung und kann den CLS-Wert verschlechtern.
So testen Sie: PageSpeed Insights und Search Console
PageSpeed Insights arbeitet mit zwei Datenquellen, die man nicht verwechseln sollte. Feldwerte stammen aus dem Chrome-UX-Report und beschreiben echte Besucher der letzten 28 Tage. Laborwerte stammen aus Lighthouse und simulieren ein Mittelklasse-Smartphone im Mobilfunknetz. Beide können laut Google voneinander abweichen, auch bei unveränderter Seite.
- PageSpeed Insights öffnen und die Startseite sowie eine wichtige Leistungsseite einzeln eingeben. Oben stehen die Felddaten (falls genug Daten vorliegen), darunter die Lighthouse-Diagnose.
- Auf „Mobil“ stellen und zuerst LCP, INP und CLS gegen die Zielwerte halten. Gibt es für die URL zu wenig Daten, fällt PSI auf die ganze Domain zurück. Gibt es auch dort keine, sehen Sie nur Laborwerte.
- Search Console: Bericht „Core Web Vitals“ (Anleitung von Google) ansehen. Er gruppiert ähnliche URLs, trennt Mobil und Desktop und zeigt „Gut“, „Verbesserungswürdig“ oder „Schlecht“. Der schlechteste Wert einer Kennzahl bestimmt den Status der Gruppe.
- Eine Sache ändern, dann warten. Weil die Felddaten über 28 Tage laufen, zeigt sich eine Verbesserung erst verzögert. Prüfen Sie zwischendurch mit den Laborwerten, ob die Änderung wirkt.
- Am echten Gerät klicken. Rufen Sie die Seite am Smartphone auf, tippen Sie den Telefon-Button, füllen Sie das Formular aus. Kein Messwert ersetzt das.
Wenn Sie diese Prüfung nicht selbst machen möchten: Mit dem kostenlosen Website-Check für KMU bekommen Sie eine erste Einschätzung Ihrer Seite.
Wann das nicht passt und wo die Grenzen liegen
- Gute Werte sind kein Ranking-Garantiebrief. Google schreibt selbst, dass Relevanz der Inhalte Vorrang hat und die Seiten-Erfahrung vor allem dann den Unterschied macht, wenn viele hilfreiche Ergebnisse zur Auswahl stehen.
- Zu wenig Daten: Neue oder kleine Websites haben oft keine Felddaten in der Search Console. Dann bleiben Laborwerte und der Test am Gerät.
- Schnell, aber nicht überzeugend: Eine Seite mit grünen Werten und unklarem Angebot bringt trotzdem keine Anfragen. Warum das so oft passiert, steht in Warum KMU-Websites keine Anfragen generieren.
- Baukasten und Plugins: Wenn Theme oder Seitenbaukasten selbst die Bremse sind, bringt Feintuning wenig. Dann ist ein Neubau oder Teil-Umbau ehrlicher als weitere Patches.
- Werte schwanken: Laborwerte unterscheiden sich von Messung zu Messung. Entscheiden Sie nach dem Trend, nicht nach einem Lauf.
Bei TRIUM sind Websites handgemacht und mobile-first angelegt, und jedes Webdesign-Projekt beginnt mit einem Audit und einer Demo. Wenn Sie wissen möchten, was bei Ihrer Seite zuerst zu tun ist, besprechen wir das gern im kostenlosen Erstgespräch. Laufende Kontrolle der Werte nach dem Launch gehört zur Betreuung über Care & Growth.
Häufige Fragen
Brauche ich eine eigene mobile Website?
Nein. Google nennt eine Mobilversion nicht verpflichtend, aber sehr empfehlenswert. In der Praxis genügt eine responsive Website, die auf allen Geräten denselben Inhalt ausliefert.
Welche Schwellenwerte gelten 2026 für die Core Web Vitals?
LCP höchstens 2,5 Sekunden, INP höchstens 200 Millisekunden und CLS höchstens 0,1, bewertet am 75. Perzentil der Seitenaufrufe und getrennt nach Mobil und Desktop.
Beeinflussen Core Web Vitals mein Google-Ranking?
Google nennt sie als Teil der Seiten-Erfahrung und empfiehlt gute Werte. Es gibt aber kein einzelnes Ranking-Signal dafür, und gute Werte garantieren keine Spitzenposition. Relevante Inhalte haben Vorrang.
Warum zeigt PageSpeed Insights für meine Seite keine Felddaten?
Dafür liegen im Chrome-UX-Report nicht genug Daten vor. PSI versucht dann den Wert für die gesamte Domain und zeigt, wenn auch das nicht reicht, nur Laborwerte.
Wie groß sollte ein Button am Handy mindestens sein?
web.dev empfiehlt etwa 48 Pixel mit rund 8 Pixel Abstand. Die WCAG 2.2 verlangen mindestens 24 mal 24 CSS-Pixel (Stufe AA) und nennen 44 mal 44 Pixel als strengere Variante.
Wie lange dauert es, bis sich Verbesserungen in der Search Console zeigen?
Der Bericht basiert auf Felddaten der letzten 28 Tage. Rechnen Sie deshalb mit einigen Wochen, bevor eine Änderung vollständig sichtbar ist.
Quellen
- Google Search Central: „Mobile-First-Indexierung: Best Practices“ (Mobile sites and mobile-first indexing). developers.google.com, abgerufen 3.10.2026.
- web.dev (Google): „Web Vitals“, Stand 31.10.2024. web.dev/articles/vitals
- web.dev (Google): „Interaction to Next Paint (INP)“, Stand 2.9.2025. web.dev/articles/inp
- Google Search Central: „Understanding Core Web Vitals and Google Search results“, Stand 10.12.2025. developers.google.com
- Google Search Central: „Understanding page experience in Google Search results“, Stand 22.9.2026. developers.google.com
- Eurostat: „Individuals - devices used to access the internet“ (isoc_ci_dev_i), Daten 2025, Aktualisierung 17.4.2026. ec.europa.eu/eurostat
- Statistik Austria: Pressemitteilung „IKT-Einsatz in Haushalten 2025“, 23.10.2025. statistik.at
- Google for Developers: „About PageSpeed Insights“. developers.google.com/speed
- Google Search Console Help: „Core Web Vitals report“. support.google.com
- web.dev (Google): „Accessible tap targets“, Stand 31.3.2020. web.dev
- W3C: „Understanding SC 2.5.8 Target Size (Minimum)“, WCAG 2.2. w3.org
- web.dev (Google): „Payment and address form best practices“. web.dev
- web.dev (Google): „Optimize Largest Contentful Paint“. web.dev
- web.dev (Google): „Optimize Cumulative Layout Shift“; „Best practices for fonts“; „Browser-level image lazy loading“. web.dev
Many SME websites look good on the owner's laptop and mediocre on the customer's phone. That is more than a cosmetic flaw: Google judges your page from the smartphone's point of view, and the phone is also where someone decides to call or swipe away. This article covers what really matters in 2026 for a mobile-first website for SMEs, what you can check yourself, and where it pays to get help.
What mobile-first indexing actually means
According to Google Search Central, Google uses "the mobile version of a site's content, crawled with the smartphone agent, for indexing and ranking." The desktop version is no longer the reference. A dedicated mobile version is not required, but it is strongly recommended. Google's mobile-first indexing guide names the points where SME sites most often go wrong:
- Same content: The mobile version should contain the same content as the desktop version. If you shorten text or drop sections on mobile, Google warns of traffic loss. Content inside tabs or accordions is fine as long as it is there.
- Nothing that loads only after a gesture: Google does not load content that requires swiping, clicking or typing. Important text and images must be in the page without any interaction.
- Same structured data and robots directives: Schema markup and meta robots tags must match on both versions, otherwise indexing goes wrong.
This matters for local businesses too, who are found through their Google profile and their website. How the two work together is covered in our guide to local SEO in the DACH region.
How many of your customers are on a phone
We could not find a reliable figure for the share of mobile searches in Austria, and the often-quoted flat 70 percent cannot be verified. What is documented is how common the smartphone is as a way online. In its ICT usage survey for 2025, Eurostat reports the percentage of people who used the internet on a mobile phone or smartphone.
In other words, the smartphone is a normal way online for almost everyone in Austria, and only about 1.9 percent used a desktop or laptop exclusively (Germany: 4.8 percent). The survey does not tell you which device someone uses to search your industry or fill in your form. Google Analytics does, split by device category.
Statistik Austria published its 2025 ICT survey on 23 October 2025. The release states, among other things, that 97 percent of 16 to 64 year olds use the internet. It contains no smartphone figures, which is why we rely on Eurostat for device access.
Core Web Vitals in 2026: thresholds and what is behind them
The three metrics measure how visitors actually experience your page. According to web.dev, a page counts as "good" when at least 75 percent of page views reach the targets, assessed separately for mobile and desktop. Google recommends the Search Console report for monitoring this, and states in its page experience documentation that good scores do not guarantee top rankings: relevance of the content still comes first.
| Metric | Target for "good" | Typical cause on SME sites | First fix |
|---|---|---|---|
| LCP | at most 2.5 seconds | Large hero image, slow server, image loaded lazily | Compress the image, do not lazy-load it, raise its priority with fetchpriority |
| INP | at most 200 milliseconds | Heavy scripts, chat widgets, tracking tags, sliders | Clear out scripts, load only what is needed |
| CLS | at most 0.1 | Images without dimensions, cookie banners, late-loading fonts | Set width and height, reserve space |
According to web.dev, INP measures the time from an interaction (a tap, click or key press) to the next frame being painted, across the whole time someone spends on the page. INP has been an official Core Web Vital since March 2024. web.dev rates it good up to 200 milliseconds, needs improvement up to 500 and poor above that.
Touch targets and the phone button
Nobody uses a mouse pointer on a phone. In its guidance on tap targets, web.dev recommends about 48 device-independent pixels with roughly 8 pixels of space between targets. That holds even when the visible icon is smaller: padding enlarges the tappable area without making the design look clumsy. WCAG 2.2 requires at least 24 by 24 CSS pixels (level AA), with exceptions where spacing is sufficient, and suggests 44 by 44 pixels as the stricter option.
For service businesses that live on phone calls and appointment requests, one element matters most:
- The phone number is a tappable
tel:link, not just text. - The button is visible without scrolling and stays reachable while scrolling, for example as a slim bar at the bottom. That is easy to hit with a thumb.
- It is a labelled button ("Call now"), not an icon without text.
- A second route (contact form or booking) sits next to it, for people who would rather not phone.
Track taps on the phone button as an event of its own. That is the only way to see later whether a change made a difference. Other levers that turn visitors into enquiries are covered in conversion optimisation: the levers that matter.
Forms that work on a phone
A form is where mobile visitors give up most often. The recommendations in web.dev's form guidance carry over to contact forms:
- Use matching field types:
type="email"andtype="tel"bring up the right keyboard. - Set the
autocompleteattribute so the browser can fill in name and address. - Give every field a visible
<label>. A placeholder alone disappears when typing starts, and people forget what the field was for. - Keep required fields to a minimum. Name, a way to reach you and the request are usually enough for a first enquiry.
- Test on a real device, not just in a shrunken browser window.
Images and fonts: where the seconds go
On most SME sites a single large image determines the LCP value. web.dev splits LCP time into four parts: server response (about 40 percent), resource load delay (under 10 percent), resource load duration (about 40 percent) and element render delay (under 10 percent). Most of the time therefore goes to the server and the image itself.
Images
- Use modern formats such as WebP or AVIF and serve images at the size they are displayed.
- Never put
loading="lazy"on the hero image. For images visible on first load, web.dev recommends the default behaviour so they load right away. For likely LCP images,fetchpriority="high"helps. - Give every image
widthandheightso the layout does not jump. For images below the fold,loading="lazy"makes sense.
Fonts
- Serve WOFF2 only and keep the number of font files small. System fonts or one variable font save requests.
- Choose deliberately with
font-displaywhat shows until the font has loaded, and define a similar fallback font so the text does not shift. - Body text of at least 16 pixels. That is a common rule of practice rather than a Google requirement; smaller text is simply tiring to read on a phone.
Pop-ups are the fourth classic. Google lists intrusive interstitials among the things to avoid for a good page experience. A cookie notice that covers half the screen hurts usability and can worsen your CLS value.
How to test: PageSpeed Insights and Search Console
PageSpeed Insights works with two data sources that should not be confused. Field data comes from the Chrome UX Report and describes real visitors over the last 28 days. Lab data comes from Lighthouse and simulates a mid-range smartphone on a mobile network. According to Google, the two can differ, even for an unchanged page.
- Open PageSpeed Insights and enter the home page and one important service page separately. Field data (if there is enough) is at the top, the Lighthouse diagnosis below.
- Switch to "Mobile" and compare LCP, INP and CLS with the targets first. If the URL has too little data, PSI falls back to the whole domain. If there is none there either, you only see lab values.
- Look at the Core Web Vitals report in Search Console (Google's instructions). It groups similar URLs, separates mobile and desktop and shows "Good", "Needs improvement" or "Poor". The worst value of any metric decides the status of the group.
- Change one thing, then wait. Because field data covers 28 days, an improvement only shows up with a delay. Use lab values in between to see whether the change works.
- Tap through on a real device. Open the page on your smartphone, tap the phone button, fill in the form. No measurement replaces that.
If you would rather not do this yourself, the free website check for SMEs gives you a first assessment of your site.
When this does not apply, and where the limits are
- Good scores are not a ranking guarantee. Google itself says content relevance takes priority and that page experience matters most when many helpful results are available.
- Too little data: New or small websites often have no field data in Search Console. Then you are left with lab values and the test on a device.
- Fast but unconvincing: A page with green scores and an unclear offer still brings no enquiries. Why that happens so often is covered in why SME websites do not generate enquiries.
- Page builders and plugins: If the theme or builder itself is the bottleneck, fine-tuning achieves little. A rebuild or partial rebuild is then more honest than more patches.
- Values fluctuate: Lab values differ from run to run. Decide by the trend, not by a single run.
At TRIUM, websites are handcrafted and built mobile-first, and every web design project starts with an audit and a demo. If you want to know what to tackle first on your site, we are happy to talk it through in a free initial call. Keeping an eye on the values after launch is part of the ongoing support under Care & Growth.
Frequently asked questions
Do I need a separate mobile website?
No. Google says a mobile version is not required but very strongly recommended. In practice a responsive website that delivers the same content on every device is enough.
Which Core Web Vitals thresholds apply in 2026?
LCP at most 2.5 seconds, INP at most 200 milliseconds and CLS at most 0.1, assessed at the 75th percentile of page views and separately for mobile and desktop.
Do Core Web Vitals affect my Google ranking?
Google lists them as part of page experience and recommends good scores. There is no single ranking signal for it, though, and good scores do not guarantee a top position. Relevant content comes first.
Why does PageSpeed Insights show no field data for my site?
The Chrome UX Report does not have enough data for it. PSI then tries the value for the whole domain and, if that is not enough either, shows lab values only.
How big should a button be on a phone?
web.dev recommends about 48 pixels with roughly 8 pixels of spacing. WCAG 2.2 requires at least 24 by 24 CSS pixels (level AA) and names 44 by 44 pixels as the stricter option.
How long until improvements show up in Search Console?
The report is based on field data from the last 28 days. Allow a few weeks before a change is fully visible.
Sources
- Google Search Central: "Mobile sites and mobile-first indexing". developers.google.com, retrieved 3 Oct 2026.
- web.dev (Google): "Web Vitals", updated 31 Oct 2024. web.dev/articles/vitals
- web.dev (Google): "Interaction to Next Paint (INP)", updated 2 Sep 2025. web.dev/articles/inp
- Google Search Central: "Understanding Core Web Vitals and Google Search results", updated 10 Dec 2025. developers.google.com
- Google Search Central: "Understanding page experience in Google Search results", updated 22 Sep 2026. developers.google.com
- Eurostat: "Individuals - devices used to access the internet" (isoc_ci_dev_i), 2025 data, updated 17 Apr 2026. ec.europa.eu/eurostat
- Statistik Austria: press release "IKT-Einsatz in Haushalten 2025", 23 Oct 2025. statistik.at
- Google for Developers: "About PageSpeed Insights". developers.google.com/speed
- Google Search Console Help: "Core Web Vitals report". support.google.com
- web.dev (Google): "Accessible tap targets", updated 31 Mar 2020. web.dev
- W3C: "Understanding SC 2.5.8 Target Size (Minimum)", WCAG 2.2. w3.org
- web.dev (Google): "Payment and address form best practices". web.dev
- web.dev (Google): "Optimize Largest Contentful Paint". web.dev
- web.dev (Google): "Optimize Cumulative Layout Shift"; "Best practices for fonts"; "Browser-level image lazy loading". web.dev
Möchten Sie das für Ihr Unternehmen umsetzen?Want this for your business?
In einem kostenlosen 30-Minuten-Gespräch zeigen wir Ihnen, wo bei Ihnen der größte Hebel liegt. Passende Leistung: Webdesign Wien.In a free 30-minute call we show you where your biggest lever is. Related service: Webdesign Wien.
Termin buchenBook a call Demo anfragenRequest a demo
