A look at where lighthousecu.org stands today, what's driving the numbers, and a clear path forward.
Lighthouse CU's website is currently not passing Google's Core Web Vitals — the metrics that directly influence search rankings. The primary drivers are architectural overhead from the Elementor page builder and infrastructure-level issues with the current hosting setup. This document walks through the performance data, uptime and reliability monitoring, hosting and security comparison, and the critical distinction between lab testing and real-world measurement — then lays out a phased path forward.
The site that won the Webby was built on WordPress with the native block editor (Gutenberg), a custom theme, and a performance-first architecture. Since then, the site has been rebuilt using Elementor, a third-party page builder plugin. This analysis looks at the performance impact of that change and what your options are going forward.
These numbers come from pagespeed.web.dev — Google's own measurement tool and the benchmark that drives search ranking signals.
INP and CLS are both in good shape — that's worth acknowledging. The issue is LCP (how quickly the main content paints) and the supporting loading metrics. The site's overall Core Web Vitals assessment is not passing, which means it doesn't receive Google's CWV ranking boost.
Scores from Chrome DevTools (running Lighthouse locally) will typically be higher than pagespeed.web.dev — sometimes significantly. Local tests run on your machine, on your network, without real-world variability. They're useful for development but don't reflect what Google measures for ranking. The numbers in this document use pagespeed.web.dev and CrUX field data — the authoritative sources for SEO.
The performance gap is rooted in how Elementor renders pages. This isn't about a missing setting or an incomplete optimization step — it's how the tool is built.
The difference comes down to architecture. Elementor loads its own CSS and JavaScript framework on every page (300–600 KB before any content), wraps every element in multiple nested <div> layers, and renders content from serialized data at runtime. [2][3] The native WordPress editor outputs static HTML with minimal JavaScript — CSS is scoped to only the blocks used on each page.
We understand the team has been exploring a CDN, and we'd recommend it regardless of the platform decision — it's good infrastructure. But it's worth being clear about what it can and can't address here, so effort gets allocated to the right place.
These are two separate roadmap items. We'd recommend treating them independently — CDN as an infrastructure improvement, platform architecture as a performance one.
Elementor sites can be improved with caching plugins, JavaScript deferral, and CSS optimization. The question is how far those techniques take you, and what the ongoing cost looks like.
The optimization gets Elementor to a good score — but it requires a dedicated caching plugin with aggressive configuration. A Gutenberg site achieves that same range out of the box. And critically, the optimization work isn't one-and-done: Elementor updates can break caching configurations, every new page adds more overhead, and each optimization plugin is another dependency to maintain.
Your team has outlined clear objectives: top-tier performance, strong SEO, future-proofing, and a site you won't have to redo in five years. Here's how the two approaches map to those goals.
| Goal | With Elementor | With Native WordPress |
|---|---|---|
| Passing Core Web Vitals | Requires aggressive optimization + ongoing maintenance | Achievable out of the box |
| PageSpeed 90+ mobile | Possible with heavy caching stack; fragile across updates | Standard baseline |
| Clean SEO markup | Verbose nested HTML with proprietary classes | Semantic HTML, structured data friendly |
| Brand consistency | Per-widget overrides can cause drift | Global Styles + locked patterns enforce consistency |
| Future-proof (5+ years) | Dependent on third-party roadmap & pricing | Built on WordPress core |
| Maintainable | Requires Elementor-specific expertise + Pro license | Standard WordPress — any developer can maintain |
Elementor's drag-and-drop editor is polished and intuitive — that's a real strength worth acknowledging. The question is whether the editing trade-off justifies the performance trade-off, given the small team making day-to-day updates.
If you move to the native editor, we wouldn't hand your team a blank screen. We'd build a guided experience tailored to your actual workflows:
This is a one-time setup investment. The performance difference is ongoing.
To be fair: Elementor does output valid HTML, and your content can be exported. The distinction is where it can go. Elementor content can be migrated to another Elementor site, but it cannot be meaningfully converted to Gutenberg blocks or any other standard format — the layout structure, styling, and widget data are all Elementor-specific. You're portable within the Elementor ecosystem, but locked into it.
WordPress itself has lock-in dynamics too — themes and plugins create dependencies in any WordPress build. The difference is the scope. With native Gutenberg, the lock-in is distributed across standard WordPress components (themes, individual plugins), each of which can be swapped independently. With Elementor, a single plugin controls the entire content structure, layout engine, and presentation layer. If the license lapses, a breaking update ships, or Elementor's business model changes, the entire site is affected at once.
This section exists because there is a common misconception that running Lighthouse in Chrome DevTools produces scores equivalent to PageSpeed Insights. It does not, and the difference matters for SEO.
Chrome DevTools runs Lighthouse locally — on your machine, on your network, using your CPU. It is a development tool designed to help engineers identify issues during the build process. PageSpeed Insights (PSI) runs on Google's standardized infrastructure with simulated throttling, and — critically — incorporates Chrome User Experience Report (CrUX) field data: real performance metrics collected from real Chrome users visiting your site over the previous 28 days. [12]
Google has been explicit about which one it uses for search ranking: CrUX field data is the sole input for the Core Web Vitals ranking signal. Not DevTools. Not any lab test. The field data section at the top of a PSI report is what determines whether your site passes or fails CWV for ranking purposes. [13]
A DevTools Lighthouse run bypasses every real-world condition that affects your members:
The result: it is routine to see a DevTools score 20–40 points higher than PSI for the same page. A site that scores 75 in DevTools might score 38 on PageSpeed Insights — and the 38 is what Google sees. [14]
PageSpeed Insights with CrUX field data is the authoritative measure of how Google evaluates your site's performance for search rankings. Chrome DevTools is for debugging during development. They are not interchangeable, and treating DevTools scores as representative of real-world performance leads to false confidence.
Performance isn't just about how fast a page loads — it's also about whether the page loads at all. We monitor both lighthousecu.org and another credit union site we host on Pantheon (communitychoicecu.com) using Oh Dear, an independent, third-party uptime monitoring service. Both sites are checked from the same location at the same interval. Here's what the data shows.
| Metric | lighthousecu.org | communitychoicecu.com Hosted on Pantheon |
|---|---|---|
| Uptime (7 days) | 99.68% | 100% |
| Uptime (12 months) | 99.95% | 100% |
| Daily uptime (past week) | 99.44% – 99.82% per day | 100% every day |
| Downtime incidents (past 9 days) | 10+ incidents 1–4 minutes each, multiple per day |
0 |
| Total downtime incidents (all time) | Multiple per week | 1 incident 50 seconds, Nov 14, 2025 |
| Avg. response time | 2,174 ms | 194 ms |
| Peak response time | 3,851 ms | 410 ms |
| Server processing time | 510 ms (before template rendering) | – |
The response time difference is 11×. lighthousecu.org's server takes over 2 seconds on average to respond to a request, compared to under 200 milliseconds on Pantheon. And the lighthousecu.org site experiences downtime every single day — brief outages of 1–4 minutes that members may experience as the site simply not loading.
The HTTP response headers on lighthousecu.org reveal the issue. The server is currently sending:
Cache-Control: no-store, no-cache, must-revalidate, max-age=0
This tells browsers to never cache anything — every single page visit requires a full round trip to the server, which then has to execute WordPress and Elementor's full rendering pipeline from scratch. The server timing data confirms this: WordPress alone takes 510 ms just to reach the template phase, before any content is generated or any Elementor rendering begins.
On Pantheon, page caching is handled at the platform level via a global CDN with Varnish edge caching. Cached pages are served in milliseconds from edge nodes close to your members. Cache invalidation happens automatically when content is updated — no manual configuration, no caching plugins, no risk of serving stale content.
Oh Dear also monitors broken links across the site. lighthousecu.org currently has 108 broken external links — old date-based permalinks from 2015–2017 that return 404 errors. These appear to be legacy URLs from before the Elementor rebuild that were not redirected when the site's permalink structure changed. Each broken link represents lost SEO link equity. communitychoicecu.com has 1 broken link across 688 pages crawled.
Credit union members expect their institution's website to be available whenever they need it. Brief, recurring outages erode trust — especially when members are trying to check rates, apply for loans, or access account information. The reliability gap between self-managed hosting and a platform like Pantheon is the difference between hoping your infrastructure holds up and knowing it will.
Oh Dear runs automated Lighthouse audits on both sites from the same infrastructure. These are independent, server-side tests — not influenced by local network conditions or browser state.
| Lighthouse Metric | lighthousecu.org | communitychoicecu.com |
|---|---|---|
| Performance | 17 | 63 |
| Accessibility | 89 | 100 |
| Best Practices | 74 | 59 |
| SEO | 92 | 100 |
| Speed Index | 8,035 ms (threshold: 4,000) | 1,994 ms |
| Time to Interactive | 6,669 ms (threshold: 4,000) | 5,002 ms |
| Total Blocking Time | 1,604 ms (threshold: 600) | 698 ms |
| Largest Contentful Paint | 3,584 ms | 1,598 ms |
| Cumulative Layout Shift | 0.39 (threshold: 0.25) | 0.03 |
lighthousecu.org fails five of Oh Dear's six Lighthouse thresholds: performance score, speed index, time to interactive, total blocking time, and cumulative layout shift. communitychoicecu.com — running on Pantheon with a custom Gutenberg theme — fails only one (time to interactive, and just barely).
The performance score of 17 is especially notable. Oh Dear's threshold for flagging a performance issue is 50. lighthousecu.org scores less than half of the failure threshold.
For a credit union, website security isn't optional — it's a regulatory expectation. The NCUA and FFIEC both set standards for the protection of member-facing digital systems. The hosting platform and the software stack are two key variables in meeting those expectations.
| Security Feature | Current Hosting (Liquid Web) | Pantheon |
|---|---|---|
| SOC 2 Type II | Data center level [15] | Entire platform [16] |
| Filesystem access | Standard writable filesystem | Read-only in production |
| Code deployment | FTP/SFTP or dashboard upload | Git-based: Dev → Test → Live |
| Automated updates | Core & OS updates | Core, plugins, & themes with automatic rollback |
| HTTPS | Included | Auto-managed, TLS 1.3, HTTP/3 |
| Global CDN | Cloudflare CDN available | Included on all plans, Varnish + edge |
| Cache management | Manual configuration required | Automatic, platform-level |
The distinction on SOC 2 is important. Liquid Web's SOC 2 Type II certification covers their data center facilities — the physical infrastructure, access controls, and environmental protections. Pantheon's SOC 2 Type II covers the entire platform, including the Security and Availability Trust Services Criteria: the deployment pipeline, access controls, automated backups, and the application layer itself. [16]
On Pantheon, the production codebase is read-only. It rebuilds from Git on every deployment. This means an attacker who finds a vulnerability in a plugin cannot write files to the server, inject backdoors, or modify core files. This single architectural decision neutralizes entire categories of WordPress exploits. [17]
On a standard hosting environment with a writable filesystem, every plugin vulnerability is a potential entry point for persistent file-based attacks.
To be clear: Elementor itself has a reasonable security track record for a plugin of its scale. The core vulnerabilities that have been disclosed are mostly stored XSS issues that require an authenticated user with at least Contributor-level access to exploit — not the kind of thing an anonymous attacker can leverage. [18]
The broader concern is the ecosystem. Elementor's extensibility model encourages third-party addon plugins, and those have had more serious issues:
The point isn't that Lighthouse CU is currently vulnerable to these specific CVEs — it isn't. The point is that Elementor as a dependency represents ongoing technical debt in the security surface. It's a large, complex plugin that requires its own update cycle, and its ecosystem attracts third-party addons with varying security quality. Every additional plugin is another thing to monitor, patch, and audit. Reducing the plugin footprint by moving to native WordPress building blocks reduces that ongoing maintenance burden. Running on a read-only platform like Pantheon adds a second layer of protection even if a vulnerability is discovered.
We see a clear route to getting lighthousecu.org back to the performance level that won you a Webby — and building on it.
Elementor is a capable tool for many use cases. But for an institution that has already demonstrated it can compete at the highest level of digital excellence — and whose goals include best-in-class performance and a platform that lasts — we believe the native WordPress architecture is the stronger foundation. It's what won you the Webby.
[1] Lighthouse Credit Union, "Lighthouse Credit Union Makes History as First-Ever Credit Union to Win a Webby Award," April 2025.
[2] Inspired Monks, "Bricks Builder vs. Elementor in 2026: A Performance Benchmark," Jan 2026.
[3] Andrei Alba / ShortPixel, "20 Common Elementor Performance Problems and How to Fix Them," Dec 2025.
[4] Google Chrome DevRel, "Avoid an Excessive DOM Size," Chrome for Developers.
[5] Mike Andreasen / WP Bullet, "Elementor vs GenerateBlocks Benchmarks." Same server, same content, 10-run averages.
[6] Marine Larmier / WP Rocket, "Divi vs Elementor Performance," updated Dec 2025.
[7] corewebvitals.io, "WordPress Core Web Vitals Optimization Guide," 2026.
[8] Aman Dubey, "Gutenberg vs Elementor in 2026: Speed, SEO & Performance Comparison."
[9] WordPress.org, "Block Templates," Block Editor Handbook.
[10] WordPress.org, "Version 6.1," November 2022.
[11] Advanced Custom Fields, "ACF Blocks," official documentation.
[12] Google, "About PageSpeed Insights," Google for Developers. PSI uses both lab data (Lighthouse) and field data (CrUX).
[13] Google Search Central, "Understanding Core Web Vitals and Google Search Results," 2024. CrUX field data is the ranking signal input.
[14] Barry Pollard / Google, "Why Lab and Field Data Can Be Different (and What to Do About It)," web.dev, 2023.
[15] Liquid Web, "Security and Trust," liquidweb.com. SOC 2 Type II covers data center facilities.
[16] Pantheon, "Security & Compliance," pantheon.io. SOC 2 Type II covers the entire platform (Security & Availability TSC).
[17] Pantheon, "Pantheon Protects You from the Latest WordPress Security Exploits," pantheon.io. Read-only production filesystem.
[18] CVE Details, "Elementor Security Vulnerabilities," cvedetails.com. Includes CVE-2024-5416 (Stored XSS, Elementor core), CVE-2025-8489 (privilege escalation, King Addons for Elementor), CVE-2026-0920 (privilege escalation, LA-Studio Element Kit for Elementor).