GreenRobot Blog

When building GreenRobot Job Search, we needed to test multiple subdomains locally — aicareers.greenrobot.com for AI/ML jobs and remotedevjobs.greenrobot.com for remote developer positions. Each subdomain shares the same codebase but serves filtered content with its own branding. The challenge? Getting Google OAuth and shared sessions to work across subdomains in local development.

The Problem

In production, session sharing across subdomains is straightforward. You set your PHP session cookie domain to .greenrobot.com, and all subdomains — jobsearch, aicareers, remotedevjobs — share the same login session. Simple.

Local development is a different story. Our main site runs on localhost because that’s what’s registered as an authorized redirect URI in Google Cloud Console for OAuth. But subdomains like aicareers.local or aicareers.localhost are on completely different domains — browsers won’t share cookies between localhost and aicareers.local.

We tried several approaches:

• *.local domains — Can’t share cookies with localhost. Different domain entirely.
• *.localhost domains — RFC 6761 says these should resolve to 127.0.0.1, and they do. But localhost is on the browser’s Public Suffix List, which means browsers block cookies set with domain=.localhost. Session sharing is impossible.
• Registering jobsearch.localhost with Google OAuth — Google rejects it. Their redirect URI validation requires a public top-level domain like .com or .org. The .localhost TLD is not accepted.

The Solution: lvh.me

lvh.me is a free domain that resolves to 127.0.0.1 — including all subdomains. No /etc/hosts changes required:

$ ping jobsearch.lvh.me
PING jobsearch.lvh.me (127.0.0.1)

$ ping aicareers.lvh.me
PING aicareers.lvh.me (127.0.0.1)

Because .me is a real public TLD, everything just works:

1. Google OAuth accepts it — http://jobsearch.lvh.me/auth/google-callback.php is a valid redirect URI.
2. Cookie sharing works — Setting domain=.lvh.me on the session cookie lets jobsearch.lvh.me, aicareers.lvh.me, and remotedevjobs.lvh.me share the same PHP session.
3. No DNS configuration — All *.lvh.me subdomains resolve to 127.0.0.1 out of the box.

Implementation

The PHP side is minimal. In our session configuration:

$currentHost = strtolower($_SERVER['HTTP_HOST'] ?? '');
$hostNoPort = preg_replace('/:\d+$/', '', $currentHost);

$cookieDomain = '';
if (preg_match('/\.greenrobot\.com$/', $hostNoPort)) {
    // Production: share across *.greenrobot.com
    $cookieDomain = '.greenrobot.com';
} elseif (preg_match('/(^|\.)lvh\.me$/', $hostNoPort)) {
    // Local dev: share across *.lvh.me
    $cookieDomain = '.lvh.me';
}

session_set_cookie_params([
    'domain' => $cookieDomain ?: '',
    'path' => '/',
    'httponly' => true,
    'samesite' => 'Lax',
]);

Our subdomain detection code doesn’t need to know about lvh.me specifically — it just checks the hostname prefix:

if (preg_match('/^aicareers\./', $host)) {
    // Serve AI Careers content
} elseif (preg_match('/^remotedevjobs\./', $host)) {
    // Serve Remote Dev Jobs content
}

This matches aicareers.greenrobot.com in production and aicareers.lvh.me in development with the same code.

For Apache, we added the lvh.me subdomains as aliases to our existing vhost:

<VirtualHost *:80>
    ServerName jobsearch.local
    ServerAlias jobsearch.lvh.me aicareers.lvh.me remotedevjobs.lvh.me
    DocumentRoot "/path/to/public_html"
</VirtualHost>

The Login Flow

1. User visits http://aicareers.lvh.me/
2. Clicks Login — redirected to http://jobsearch.lvh.me/auth/login.php?return_to=http://aicareers.lvh.me/
3. Authenticates via Google OAuth (callback registered on jobsearch.lvh.me)
4. Session cookie set with domain=.lvh.me
5. Redirected back to http://aicareers.lvh.me/ — already logged in because the session cookie is shared

Takeaway

If you’re building a multi-subdomain app and need to test OAuth and shared sessions locally, skip the localhost/.local headaches and use lvh.me. It’s a zero-configuration solution that plays nicely with Google’s OAuth restrictions and browser cookie policies.

We recently added WCAG 2 AA accessibility testing to our CI pipeline at GreenRobot Job Search using pa11y. After fixing dozens of real issues in our own code – contrast ratios, missing form labels, empty anchor tags – we got every page on our site to zero accessibility errors.

Then we opened a pull request.

Our GitHub Actions CI pipeline ran pa11y against the live site – and every single page with Google AdSense failed.

The Problem

Google AdSense injects iframes into your page at runtime with no title attribute:

[iframe src="https://www.google.com/recaptcha/api2/aframe"
        width="0" height="0"
        style="display: none;">[/iframe>

[iframe id="google_esf" name="google_esf"
        src="https://googleads.g.doubleclick.net/pagead/html/..."
        style="display: none;">[/iframe>

(note less than sign replaced with [ so it renders code in the blog. gotta fix this one day)

This violates WCAG 2.4.1 (Bypass Blocks) and WCAG 4.1.2 (Name, Role, Value). Every iframe needs a non-empty title attribute so screen reader users can identify its purpose.

The fix would be trivial on Google’s end. Something like:

[iframe title="Google ad services" ...>[/iframe>

That’s it. One attribute.

Why This Matters

If you’re a developer trying to make your site accessible – and you should be – Google’s ad scripts will fail your automated accessibility tests through no fault of your own. You’re left with two options:

1. Exclude Google’s iframes from your tests (what we had to do)
2. Remove ads from your site

Neither option is great. The first means you’re sweeping a real accessibility violation under the rug. The second means giving up revenue because a trillion-dollar company couldn’t add a title attribute to an iframe.

Here’s the pa11y ignore rule we had to add to our CI config:

{
  "defaults": {
    "hideElements": "iframe[src*='google'], iframe[src*='doubleclick'], iframe[src*='recaptcha']"
  }
}

We shouldn’t have to do this.

The Bigger Picture

Google has published extensive accessibility guidelines and Chrome DevTools has built-in accessibility auditing via Lighthouse. Google literally built tools to catch this exact problem. Yet their own ad platform ships inaccessible markup to millions of websites.

This isn’t just a Google problem. The entire ad-tech ecosystem largely ignores accessibility. Ad iframes routinely lack titles, ad content rarely meets contrast requirements, and interactive ad elements often aren’t keyboard-navigable. But Google sets the standard. If AdSense shipped accessible markup, the industry would follow.

A Call to Action

To Google: Please add title attributes to the iframes your ad scripts inject. It’s a one-line fix that would instantly improve accessibility across millions of websites.

To ad-tech competitors: There’s a real opportunity here. If you’re building an ad platform that competes with AdSense, ship accessible markup by default. Make it a selling point. As accessibility regulations tighten globally – the European Accessibility Act took effect in June 2025 – publishers will increasingly need ad partners that don’t break their compliance.

To fellow developers: Don’t let third-party scripts be an excuse to skip accessibility testing. Add the ignore rules you need to keep your CI green, but document why those rules exist. File bugs with the offending services. And keep testing the code you can control.

We got our site from 91 accessibility errors down to zero across 16 pages. The only failures left are Google’s, not ours. We’ll keep the ignore rules in place for now, but we’d love nothing more than to remove them.

Andy Triboletti is the founder of GreenRobot. GreenRobot Job Search helps developers find jobs at VC-backed companies. Our codebase is tested with pa11y (WCAG 2 AA), Nu HTML Checker, and Puppeteer console error detection on every pull request.

Why Page Speed Matters

Page load time directly impacts user experience, SEO rankings, and conversion rates. Google has made Core Web Vitals a ranking factor, and studies consistently show that users abandon pages that take more than 3 seconds to load. Every 100ms of added latency costs measurable engagement.

The single biggest contributor to slow pages? Oversized images and unoptimized resources.

The Problem We Found on Our Own Site

We recently ran our own Mega Report against codefrog.app and discovered our landing page was shipping 3.24 MB of images to users. The breakdown:

• codefrog-1024-transparent.png – 1.10 MB (hero logo, displayed at 200px)
• owasp.png – 594 KB (screenshot, 2880×1800 source)
• githubpr.png – 410 KB (screenshot, 2880×1800 source)
• megareport.png – 322 KB (screenshot, 2880×1800 source)
• Plus 4 more oversized screenshots

The hero logo was a 1024×1024 PNG being displayed at a maximum of 200px CSS width. The screenshots were all 2880×1800 retina captures being served at full resolution regardless of display size.

How We Fixed It

1. Right-Size Your Images

Never serve an image larger than it needs to be. If your CSS displays an image at 200px wide, a 512px source is plenty (accounts for 2x retina). If your screenshots display in a grid at ~700px, a 1440px source covers retina displays.

We resized our hero logo from 1024px to 512px and all screenshots from 2880×1800 to 1440×900.

2. Use WebP Format

WebP provides significantly better compression than PNG for photographic and screenshot content, while still supporting transparency. Browser support is now above 97%.

Our results after converting to WebP:

Total page image weight dropped from 3.24 MB to ~248 KB – a 92% reduction.

3. Use the <picture> Element for Fallback

The <picture> element lets you serve WebP to browsers that support it while falling back to PNG for older browsers.

4. Lazy Load Below-the-Fold Images

Add loading="lazy" to any image that isn’t visible in the initial viewport. The browser will defer loading these images until the user scrolls near them, dramatically improving initial page load time.

For your hero/above-the-fold image, use fetchpriority="high" instead to tell the browser to prioritize it.

5. Quick Optimization with Command-Line Tools

You don’t need fancy build pipelines. On macOS, you can optimize images with tools you already have:

# Resize with sips (built into macOS)
sips -z 900 1440 screenshot.png

# Convert to WebP with ImageMagick
magick screenshot.png -resize 1440x900 -quality 80 screenshot.webp

Common Thresholds for Page Weight

Based on industry best practices, here are reasonable targets:

PNG images over 100 KB are almost always candidates for WebP conversion.

New in CodeFrog: Page Size & Performance Test

We built these insights directly into CodeFrog’s Mega Report. The new Page Size & Performance test, coming in an upcoming release, automatically:

• Discovers all page resources – images, scripts, stylesheets, fonts, and other assets
• Measures compressed and uncompressed sizes for each resource
• Flags oversized resources with severity ratings:
  • Critical: Any single resource over 5 MB, or total page over 10 MB
  • High: Any image over 1 MB, or total page over 5 MB
  • Medium: Any image over 500 KB, or total page over 3 MB
  • Low: Any image over 200 KB, or total page over 1.5 MB
  • Info: PNG images over 100 KB that could benefit from WebP conversion
• Shows a breakdown by resource type (images, scripts, styles, fonts)
• Shows compression savings so you can see how much transfer encoding helps
• Works in Sitemap Mode to audit every page across your entire site

The Page Size test integrates with the existing Mega Report alongside Accessibility, Security, SEO, Meta Tags, and HTML Validation tests. You get a single comprehensive report covering all aspects of your site’s health.

How It Looks

When you run a Mega Report, the Page Size section shows:

1. Summary card with total page weight, compression savings percentage, resource count, and breakdown by type
2. Sorted resource list showing every asset on the page, color-coded by size, with file type icons
3. Severity counts that feed into the overall health score grade (A through F)

Export Support

Page Size results are included in both Markdown and PDF exports, so you can share findings with your team or include them in client reports.

Try It Yourself

The Page Size & Performance test will be available in the next release of CodeFrog for macOS and Windows. In the meantime, you can manually audit your pages using browser DevTools (Network tab, sort by size) or run Lighthouse.

The fastest page is the one that loads the least. Start with your images – they’re almost always the biggest win.

CodeFrog is a developer tool for macOS and Windows that helps you find and fix bugs with comprehensive code analysis, web testing, and GitHub automation. Learn more at codefrog.app.