Technical SEO for international patients: Core Web Vitals
Measuring Core Web Vitals on the networks patients in the Gulf, Iran and Europe actually use: country-level CrUX, RTL fonts, galleries and third-party scripts.
By Roozbeh Nazari · CEO
Most of what is written about Core Web Vitals rests on measurements taken from the country where the site is hosted, over a fast connection. For a clinic attracting international patients that measurement is misleading: your patient is connecting from Riyadh, Tehran or Frankfurt, mostly over a mobile network and from a point far from your server. The page experience measured from Istanbul and the page experience lived from the Gulf are two different results for the same page. This article narrows the general framework we set out in our earlier article on Core Web Vitals to the case of international patients: what to measure, from where and how, and which problems specific to health tourism sites break these three metrics.
Three metrics, on the international patient's network
By web.dev's definition, the three Core Web Vitals metrics and their thresholds are fixed: Largest Contentful Paint should occur within 2.5 seconds of when the page first starts loading; Interaction to Next Paint should be 200 milliseconds or less; Cumulative Layout Shift should stay at 0.1 or less. All three thresholds are defined at the 75th percentile of page loads; that is, the experience of three quarters of users should be under the threshold. For international patients the critical point is this percentile: if the majority of your site's visitors come from Türkiye, the 75th percentile reflects the experience in Türkiye, and the slowness experienced by the minority connecting from the Gulf does not show up in the aggregate figure. While the aggregate figure looks good, the patient in your target market may be experiencing a page that exceeds the threshold.
Measurement: where country-level field data comes from
Google's Chrome UX Report is field data reflecting the experience of real Chrome users, and the source of Core Web Vitals. The country dimension was added to this dataset in 2018; however, according to the Chrome for Developers documentation, the country dimension is not available in the CrUX APIs, only in the BigQuery dataset, which has a separate table for each country plus summary tables that include the country code as a column. The practical consequence is this: PageSpeed Insights and the Core Web Vitals report in Search Console do not give a country breakdown; to see the experience in the target market you need to look at the country table in BigQuery, or record the country alongside the metrics with a library that collects field measurements on your own site. The second route is more accessible for small sites: send the metrics to your own analytics tool together with the visitor's country and language version, and break the report down by country and locale. Also run lab tests from a location close to the target market; if the test tool's server is in Europe, you are not seeing the latency in the Gulf.
RTL fonts and layout shift
The most common Core Web Vitals problem we see on Arabic and Persian pages is font-related. In the Latin alphabet the difference between system fonts and web fonts is small; in Arabic and Persian, a web font loading late changes line height, letter joins and the number of lines, and that produces a measurable layout shift. The fix has three parts: define a metric-compatible fallback font stack, load the main font early, and subset it to reduce file size. In addition, if the direction behaviour of icons and numbers in a right-to-left layout changes after the first paint, that is also measured as a shift. Our technical SEO checklist for RTL sites covers these items together with the indexing and hreflang side; here we only cover the performance dimension.
Galleries and images: the real owner of LCP
On health tourism sites the largest content element is very often an image: the clinic photo in the hero area, the doctor's image on the treatment page or the first frame of the results gallery. LCP depends on when that image is painted, and for a patient connecting from a distant network the image's size means seconds directly. The rules we apply in practice: a modern format and several sources by screen size for the above-the-fold image, no lazy loading on the above-the-fold image, lazy loading for the other gallery frames placed below the fold, and image dimensions declared in the HTML to prevent shift. Results galleries have one more layer: how to set up these galleries in terms of regulation and user experience is explained in a separate article; on the performance side, the gallery must not take over the LCP of the first screen.
Third-party scripts and INP
On clinic sites, what occupies the main thread most is usually not your own code but third parties: the WhatsApp chat button, the live support widget, cookie consent, automatic translation, the call-back form, and analytics and ad tags. Each of these runs while the page loads and while the user makes their first tap, and can push INP above 200 milliseconds. For a patient connecting from a distant network the effect is larger, because the scripts themselves are also downloaded from far away. Our approach: question every third-party script one by one as to whether it is really needed, defer the necessary ones to user interaction or idle time, build the WhatsApp button as a simple link rather than a heavy widget, and move tags server-side where possible. We are not giving numbers in this article; on each site you will see in your own field data how many milliseconds each script eats.
Geography: server, CDN and the first byte
All three metrics depend on when the first byte arrives, and the first byte depends on the distance between the patient and the server. Serving the Gulf or Iran from a single server in Türkiye adds a measurable delay to every request. Serving static assets from a CDN with edge locations near the target market, caching the HTML, and measuring the first byte from the target country is the single largest improvement for international patients. Iran is a special case here: some CDNs and service providers do not serve Iran, or serve it with restrictions; rather than assuming your Persian pages actually load, you need to test from that market.
Ranking effect: what Google says, and does not say
Google Search Central's page experience document says that Core Web Vitals are used by its ranking systems, and adds in the same document that a good score does not guarantee top rankings, and that relevance and overall page experience matter more than any single metric. Our reading is this: for international patients, Core Web Vitals is a threshold for ranking and a direct factor for conversion. A patient on a distant network abandoning the page shows up not in the ranking report but in the number of enquiries. In our technical SEO service, country-level field measurement, font and image layout, and the third-party audit are handled in that order; the largest gain is usually in the first two.
Conclusion
For international patients, Core Web Vitals is read from the target country, not from the aggregate figure. Because the country dimension exists only in BigQuery, collecting your own field measurements together with country and locale, closing the shift produced by RTL fonts with a fallback stack and early loading, not letting the gallery take over the above-the-fold image, deferring third-party scripts and serving content from edge locations near the target market improves the three metrics where the patient actually experiences them. The thresholds are fixed; moving the measurement point to where the patient is, is your job.