Everything in one place: Speed & Cache · CDN · Responsiveness · SSL/HTTPS — what each thing is, how to check it, what counts as good, and how to fix it. Then a flowchart and step-by-step routine to run on every website before it goes to the client.
One tool measures all of this: Google PageSpeed Insights (pagespeed.web.dev). Paste the URL and it returns five things — two scores and three Core Web Vitals.
Overall performance score when tested as a phone on a slow 4G connection.
A single number summarising how fast and stable the page is on a mobile device. Google simulates a mid-range phone on slow internet — how most real visitors browse. That's why Mobile is almost always lower than Desktop, and why it's the more important score.
pagespeed.web.dev → paste URL → result opens on the Mobile tab. Locally: Chrome → F12 → Lighthouse tab → Mobile → Analyze.
The same 0–100 score, tested as a desktop computer on fast internet.
Identical test, easier conditions. A site scoring 55 on Mobile may score 90 on Desktop. If even Desktop is low, the problem is serious — very heavy pages or a slow server — because this is the easiest test to pass.
Same PageSpeed result — click the Desktop tab. Always record both scores in an audit.
Largest Contentful Paint — how long the main content takes to appear.
Time from clicking the link until the largest visible element (usually the hero image or main heading) is fully painted. It answers: "When can I actually see the page?"
Shown directly in PageSpeed Insights (field + lab data). It even highlights which element is the LCP element.
Interaction to Next Paint — how quickly the page responds to a tap or click.
The delay between an interaction (tap, click, key press) and the screen visibly reacting. A page can load fast but feel frozen — you tap the menu and nothing happens. INP catches that. (It replaced FID in 2024.)
In PageSpeed Insights under "Discover what your real users are experiencing" (needs real-user data, so very small sites may not show it). Feel-test: open on a phone and tap menus/buttons — visible lag = INP problem.
Cumulative Layout Shift — how much the page jumps around while loading.
Measures unexpected movement. You start reading, an image or ad loads above, the text jumps, you tap the wrong button. Every jump adds to the score — lower is better, 0 is perfect.
Shown in PageSpeed / Lighthouse; Diagnostics names the exact elements that shifted. To see it: reload on slow internet and watch whether text or buttons move after first appearing.
Cache = a saved copy of work already done, kept somewhere fast, so it doesn't have to be rebuilt for every visitor.
Without cache, every visit makes the server rebuild the page from scratch (run PHP, query the database, assemble HTML). With cache, the hard work is done once, the finished copy is saved, and everyone else gets that copy instantly. Copies are saved at several layers:
| Layer | Where the copy lives |
|---|---|
| 1. Browser cache | On the visitor's own device (images, CSS, JS) |
| 2. CDN cache | On edge servers near the visitor (Part 3) |
| 3. Page cache | Ready-made HTML pages saved on the server (caching plugin) |
| 4. Object cache | Database query results (Redis/Memcached) |
"I updated the website but I still see the old content." Cache serves saved copies, so after changes every layer must be told to refresh — in this order:
The order matters: if you refresh the browser first, it just re-downloads the old copy still saved on the CDN/server.
CDN = Content Delivery Network — a worldwide network of servers keeping cached copies of the site close to every visitor.
The site's origin server sits in one city (say Mumbai). Without a CDN, a visitor in New York pulls every image across ~12,000 km of cable — high latency, slow load. With a CDN (Cloudflare, CloudFront, Akamai), copies sit on edge servers in 100+ cities; the New York visitor downloads from a New York server in milliseconds, and the origin server relaxes. Bonus: it absorbs traffic spikes, gives DDoS protection, and often free SSL.
server: cloudflare, cf-ray:, x-cache: HIT, via:.x-cache: HIT = the edge server had a saved copy (good). MISS = it had to fetch from origin (first visit, or cache purged).One website must adapt to every screen — phone, tablet, desktop. Most visitors are on phones, so this check is never optional.
Responsive design uses flexible layouts + CSS media queries so the same page rearranges itself per screen width. The one line that makes it possible is the viewport tag — if it's missing, phones show a shrunken desktop page:
<meta name="viewport" content="width=device-width, initial-scale=1.0">
max-width:100% so they never overflow.sm:/md:/lg: classes, or @media (max-width:768px) rules).The padlock 🔒 = SSL/TLS encryption between the visitor's browser and the server. Browsers mark plain HTTP as "Not Secure", Google ranks HTTPS higher, and payments require it.
An SSL certificate does three jobs: encryption (data travels scrambled — passwords and card numbers can't be read on the way), identity (a trusted Certificate Authority confirms the site is who it claims), and integrity (nothing can be modified in transit).
Click the padlock in the address bar → "Connection is secure" → Certificate is valid. Record: Issued to (the domain), Issued by (the CA — Let's Encrypt, Google Trust, DigiCert…), and Expiry date. An expiring certificate is a ticking issue — most (like Let's Encrypt) auto-renew every 90 days, but confirm.
Type the site with plain http:// in front. It must automatically redirect to https://. If both versions open separately, that's an issue to report — the redirect is forced in the hosting panel or via the CDN.
If the page is HTTPS but some images/scripts still load over http://, the padlock breaks or shows a warning. Open F12 → Console tab and look for "Mixed Content" warnings — they name the exact insecure file. Fix: update those links to https (or run a search-replace plugin on WordPress).
Run the domain through ssllabs.com/ssltest. It gives a grade (A+ … F) and full certificate details. A / A+ Good B / C Report it Expired / invalid Blocker
| Issue | What the visitor sees | Fix |
|---|---|---|
| Expired certificate | Full-page red browser warning | Renew in hosting panel; enable auto-renew (Let's Encrypt) |
| Mixed content | Padlock missing / warning | Find http:// links in Console, change to https:// |
| No redirect | Site opens on both http and https | Force HTTP→HTTPS redirect in hosting panel / CDN |
Run this on every website after the content work is finished and before it is handed over. At any FAIL: note the issue → fix (or send to developer) → re-test that step → continue.
Since the content is her own work, this comes first. Read every page top to bottom on the live site (text often breaks differently online than in the draft). Click every menu item, button and link — internal and external. Check that every image loads and has meaningful alt text, and that the page titles and headings match the content.
Before measuring speed, make sure the layout survives on small screens — a beautiful desktop site that breaks on phones is a failed delivery. F12 → Ctrl+Shift+M and test iPhone SE, iPhone 14/15, iPad and Desktop; then repeat quickly on a real phone. Hunt the 6 common bugs from Part 4 (horizontal scroll, tiny text, close tap targets, overflowing images, broken menu, uncloseable popups) and confirm the viewport meta tag exists in the page source.
Run pagespeed.web.dev on the homepage and at least one inner content page (inner pages are often heavier). Record Mobile score, Desktop score, LCP, INP, CLS and compare with the good limits: Score ≥ 90 · LCP ≤ 2.5s · INP ≤ 200ms · CLS ≤ 0.1. If something fails, open "Opportunities/Diagnostics" — as the content person, the fixes she can often do herself are compressing the images she uploaded (WebP, correct dimensions) and removing very heavy embeds; deeper fixes (caching, scripts, hosting) go to the developer with the PageSpeed screenshot attached.
Two things here. First, confirm caching works: F12 → Network → reload twice → the second load should show files from (disk cache) and load visibly faster. Second — and this is the step people forget — after the final content changes, purge in order: CMS/plugin cache → CDN cache → hard refresh (Ctrl+Shift+R). Otherwise the client may open the site and see an older version of her content, even though everything was updated.
F12 → Network → click any image → Response Headers. server: cloudflare / cf-ray / x-cache: HIT = CDN active. No CDN is not a delivery blocker for a small local site, but it goes in the report as a recommendation (Cloudflare free plan), especially if the audience is spread across regions or the speed scores were weak.
Four quick checks from Part 5: (1) padlock present, certificate valid — note issuer and expiry date; (2) typing http:// redirects automatically to https://; (3) F12 → Console shows no "Mixed Content" warnings; (4) SSL Labs grade is A. An expired certificate or a red browser warning is a delivery blocker — the site cannot be submitted until it's fixed.
Close everything, open the live site fresh like a first-time visitor — once on the phone, once on desktop. Navigate the main journey a real visitor would take (home → service/product page → contact → submit the contact form with a test message). Confirm the form actually delivers. This catches anything the individual checks missed, because now you're testing the experience, not the parts.
One short document (1 page is enough) attached with the delivery: the speed scores table, screenshots of mobile/tablet/desktop views, SSL certificate details (issuer + expiry), CDN status, and a list of issues found — marked Fixed or Recommended. Rule: every claim has evidence (number or screenshot), every issue has a one-line plain-language fix. This report is what turns "I checked it" into proof of quality.
Pick one real website (a live client site or any local business site) and treat it as if you are delivering it tomorrow. Every answer needs evidence — a screenshot or a number.