Skip to report
Scan another site

Performance report

jumptoweb.com

Scanned jumptoweb.com

  • WordPress
  • nginx
  • PHP

82 out of 100

Warp Score

B Good

TTFB — Goodserver response
68 ms
LCP — Poorlab
4.3 s
LCP — Goodlab
1.0 s
INPno field data
—
CLS — Goodlab
0
CLS — Goodlab
0.002
Desktop — GoodLighthouse
97
Mobile — PoorLighthouse
55
Transfer
1.04 MB
Transfer
988 KB
Requests
75
Requests
63
Share on X Share on LinkedIn

Overview

Score breakdown

Performance

C

72 / 100

Lighthouse scored this page 55 on mobile and 97 on desktop.

Core Web Vitals

— not scored

Not enough Chrome UX Report data is available for this URL.

Server & Cache

A+

100 / 100

HTML is served from cache by Proxy cache with a warm TTFB of 68 ms.

Assets

C

73 / 100

1.04 MB transferred in 75 requests, including 369 KB of JavaScript.

Delivery

A

93 / 100

Delivered with HTTP/2, Gzip compression, no CDN detected.

Top improvements

  1. Eliminate render-blocking resourcesHigh impactPotential savings: 12.6 s

    22 stylesheets and scripts block the first paint.

    Evidence

    • jumptowebcom7b408.zapwp.com/wp-content/…utomatic-css/automatic.css?icv=faf0c589 (1.7 s)
    • jumptowebcom7b408.zapwp.com/wp-content/…t-awesome-6-ed2cbab998.css?icv=2b86a7d1 (1.5 s)
    • jumptowebcom7b408.zapwp.com/wp-content/…ontend-light-layer.min.css?icv=fb3300e5 (1.1 s)

    Why it matters

    The browser cannot draw anything until these files are downloaded and processed, which delays FCP and LCP.

    How to fix

    Inline the CSS needed for the first screen and load the rest asynchronously; defer scripts that are not needed to render the page.

    Related metric: LCP

    In Warp PerformanceWarp Performance → CSS → Remove Unused CSSWarp Performance → JavaScript → Defer JavaScript
  2. Delay non-critical JavaScriptHigh impact

    JavaScript kept the main thread busy for 942 ms while the page was loading.

    Evidence

    • Total Blocking Time: 942 ms
    • 8 scripts with significant execution time
    • jumptoweb.com/
    • Unattributable

    Why it matters

    While scripts run, the page cannot respond to taps or clicks. High blocking time is the main cause of poor INP and a sluggish first interaction.

    How to fix

    Delay scripts that are not required for initial rendering (analytics, chat widgets, ads, social embeds) until the first user interaction.

    Related metric: TBT

    In Warp PerformanceWarp Performance → JavaScript → Delay JavaScript
  3. Reduce the impact of third-party codeHigh impact

    Scripts and resources from other companies account for 649 KB of this page.

    Evidence

    • Third-party code: 649 KB (61% of page weight) across 61 requests
    • jumptowebcom7b408.zapwp.com — 374 KB
    • app.usercentrics.eu — 207 KB
    • privacy-proxy.usercentrics.eu — 33 KB

    Why it matters

    Tags, widgets and embeds run on the same main thread as your own code and are outside your control. They are a common cause of slow interaction.

    How to fix

    Remove tags that are no longer used, load the rest after the first interaction, and replace heavy embeds (video, maps, chat) with a lightweight placeholder that loads on click.

    Related metric: TBT

    In Warp PerformanceWarp Performance → JavaScript → Delay JavaScript
  4. Optimize image deliveryMedium impactPotential savings: 137 KB

    Images are larger than they need to be: resizing, recompressing or converting them would save about 137 KB.

    Evidence

    • jumptoweb.com/wp-content/uploads/antigua-about-us-768x3298.webp (43 KB could be saved)
    • jumptoweb.com/wp-content/uploads/Home-768x2970.webp (39 KB could be saved)
    • jumptoweb.com/wp-content/uploads/Riverwalk-Ranch-Home-768x3379.webp (36 KB could be saved)

    Why it matters

    Images are usually the largest part of a page and often the LCP element.

    How to fix

    Serve images at the size they are displayed, in WebP or AVIF, with sensible compression.

    Related metric: LCP

    In Warp PerformanceWarp Performance → Media → Local Image OptimizationWarp Performance → Media → Responsive Images
  5. Reduce unused JavaScriptMedium impactPotential savings: 135 KB

    135 KB of downloaded JavaScript was never executed during page load.

    Evidence

    • app.usercentrics.eu/browser-ui/3.108.0/index.module.js (54 KB could be saved)
    • jumptoweb.com/wp-content/themes/bricks/assets/js/bricks.min.js (50 KB could be saved)
    • app.usercentrics.eu/browser-ui/3.108.0/VirtualServiceItem-79fbba2b.js (31 KB could be saved)

    Why it matters

    Unused code still has to be downloaded, parsed and compiled, which competes with rendering and slows interaction.

    How to fix

    Load scripts only on the pages that use them, split large bundles, and delay scripts that are not needed until the visitor interacts.

    Related metric: LCP

    In Warp PerformanceWarp Performance → JavaScript → Delay JavaScript

6 more findings are listed in the other tabs.

Page weight

1.04 MB transferred · 75 requests · Mobile

  • JavaScript 369 KB 26 requests
  • Images 316 KB 14 requests
  • Fonts 210 KB 2 requests
  • CSS 103 KB 22 requests
  • HTML 40 KB 1 request
  • Other 23 KB 10 requests

988 KB transferred · 63 requests · Desktop

  • JavaScript 323 KB 16 requests
  • Images 293 KB 14 requests
  • Fonts 210 KB 2 requests
  • CSS 103 KB 22 requests
  • HTML 40 KB 1 request
  • Other 19 KB 8 requests

Shareable summary

Core Web Vitals

Real-user data shows what visitors actually experienced over the last 28 days. The lab test is a single controlled page load, useful for finding causes. The two often differ, and Google uses the real-user data.

Real users Chrome UX Report · 75th percentile

Not enough Chrome UX Report data is available for this URL.

This is common for newer or lower-traffic pages. It does not lower the Warp Score; the score is calculated from the other categories instead.

Lab test Google Lighthouse · simulated load

Mobile

Lighthouse — Poor
55
LCP — Poor
4.3 s
FCP — Poor
3.0 s
TBT — Poor
942 ms
Speed Index — Needs improvement
5.0 s
CLS — Good
0

Desktop

Lighthouse — Good
97
LCP — Good
1.0 s
FCP — Good
0.7 s
TBT — Good
96 ms
Speed Index — Good
0.9 s
CLS — Good
0.002

Server & Cache

TTFB (server response)
68 ms
HTML cache
Proxy cache Confirmed
CDN
None detected
Compression
Gzip
HTTP version
HTTP/2
Server
nginx
Redirects
None
Browser caching
HTML is revalidated on each visit (ETag / Last-Modified)
Static asset caching
6 of 6 sampled assets cached for 30 days or more

Connection timing from the scanner

DNS
31 ms
TCP
36 ms
TLS
40 ms
First-byte wait
73 ms
Total
170 ms
HTML size
39 KB

Measured from the Warp Scan server, so network times reflect its location rather than your visitors'. The TTFB figure above is the first-byte wait on an open connection (the faster of two requests), so it includes one network round trip from the scanner.

Developer details

Cache evidence

  • x-cache: HIT (first request)
  • age: 2712 (first request)
  • x-cache: HIT (repeat request)
  • age: 2763 (repeat request)

Response headers (first request)

age: 2712
last-modified: Tue, 06 Oct 2026 19:57:24 GMT
vary: Accept-Encoding
server: nginx
content-type: text/html; charset=UTF-8
content-encoding: gzip
content-length: 40119
link: <https://jumptoweb.com/wp-json/>; rel="https://api.w.org/", <https://jumptoweb.com/wp-json/wp/v2/pages/2>; rel="alternate"; title="JSON"; type="application/json", <https://jumptoweb.com/>; rel=shortlink
x-cache: HIT

Response headers (repeat request, 68 ms) 

age: 2763
last-modified: Tue, 06 Oct 2026 19:57:24 GMT
vary: Accept-Encoding
server: nginx
content-type: text/html; charset=UTF-8
content-encoding: gzip
content-length: 40119
link: <https://jumptoweb.com/wp-json/>; rel="https://api.w.org/", <https://jumptoweb.com/wp-json/wp/v2/pages/2>; rel="alternate"; title="JSON"; type="application/json", <https://jumptoweb.com/>; rel=shortlink
x-cache: HIT

Sampled static assets

Asset Cache lifetime Cache-Control
jumptoweb.com/wp-content/them…ricks/assets/js/bricks.min.js 1 year public, max-age=31536000
jumptoweb.com/wp-content/uploads/website_mockups.webp 1 year public, max-age=31536000
jumptoweb.com/wp-content/uplo…elay-v3-loader-7.25.00.min.js 1 year public, max-age=31536000
jumptoweb.com/wp-content/uploads/Home-scaled.webp 1 year public, max-age=31536000
jumptoweb.com/wp-content/uplo…/antigua-about-us-scaled.webp 1 year public, max-age=31536000
jumptoweb.com/wp-content/uplo…erwalk-Ranch-Home-scaled.webp 1 year public, max-age=31536000
  • Improve static asset cache lifetimeLow impactPotential savings: 310 KB

    Some CSS, JavaScript or image files tell browsers to cache them only briefly, or not at all.

    Evidence

    • 0 of 6 sampled static assets have a cache lifetime under 30 days
    • Lighthouse flagged 36 resources with a short cache lifetime

    Why it matters

    Returning visitors re-download files that have not changed. Long cache lifetimes make repeat views and page-to-page navigation much faster.

    How to fix

    Serve versioned static files with Cache-Control: public, max-age=31536000, immutable.

JavaScript

369 KB in 26 requests · 35% of page weight · Mobile

323 KB in 16 requests · 33% of page weight · Desktop

  • Eliminate render-blocking resourcesHigh impactPotential savings: 12.6 s

    22 stylesheets and scripts block the first paint.

    Evidence

    • jumptowebcom7b408.zapwp.com/wp-content/…utomatic-css/automatic.css?icv=faf0c589 (1.7 s)
    • jumptowebcom7b408.zapwp.com/wp-content/…t-awesome-6-ed2cbab998.css?icv=2b86a7d1 (1.5 s)
    • jumptowebcom7b408.zapwp.com/wp-content/…ontend-light-layer.min.css?icv=fb3300e5 (1.1 s)

    Why it matters

    The browser cannot draw anything until these files are downloaded and processed, which delays FCP and LCP.

    How to fix

    Inline the CSS needed for the first screen and load the rest asynchronously; defer scripts that are not needed to render the page.

    Related metric: LCP

    In Warp PerformanceWarp Performance → CSS → Remove Unused CSSWarp Performance → JavaScript → Defer JavaScript
  • Delay non-critical JavaScriptHigh impact

    JavaScript kept the main thread busy for 942 ms while the page was loading.

    Evidence

    • Total Blocking Time: 942 ms
    • 8 scripts with significant execution time
    • jumptoweb.com/
    • Unattributable

    Why it matters

    While scripts run, the page cannot respond to taps or clicks. High blocking time is the main cause of poor INP and a sluggish first interaction.

    How to fix

    Delay scripts that are not required for initial rendering (analytics, chat widgets, ads, social embeds) until the first user interaction.

    Related metric: TBT

    In Warp PerformanceWarp Performance → JavaScript → Delay JavaScript
  • Reduce unused JavaScriptMedium impactPotential savings: 135 KB

    135 KB of downloaded JavaScript was never executed during page load.

    Evidence

    • app.usercentrics.eu/browser-ui/3.108.0/index.module.js (54 KB could be saved)
    • jumptoweb.com/wp-content/themes/bricks/assets/js/bricks.min.js (50 KB could be saved)
    • app.usercentrics.eu/browser-ui/3.108.0/VirtualServiceItem-79fbba2b.js (31 KB could be saved)

    Why it matters

    Unused code still has to be downloaded, parsed and compiled, which competes with rendering and slows interaction.

    How to fix

    Load scripts only on the pages that use them, split large bundles, and delay scripts that are not needed until the visitor interacts.

    Related metric: LCP

    In Warp PerformanceWarp Performance → JavaScript → Delay JavaScript
  • Stop sending legacy JavaScript to modern browsersLow impactPotential savings: 11 KB

    About 11 KB of polyfills and transpiled code targets browsers that no longer need it.

    Evidence

    • app.usercentrics.eu/browser-ui/3.108.0/VirtualServiceItem-79fbba2b.js (11 KB could be saved)

    Why it matters

    Modern browsers download and run compatibility code they never use.

    How to fix

    Update the build target (browserslist) to current browsers and remove unnecessary polyfills.

CSS

103 KB in 22 requests · 10% of page weight · Mobile

103 KB in 22 requests · 10% of page weight · Desktop

  • Remove unused CSSLow impactPotential savings: 32 KB

    32 KB of CSS rules are not used by this page.

    Evidence

    • jumptowebcom7b408.zapwp.com/wp-content/…utomatic-css/automatic.css?icv=faf0c589 (32 KB could be saved)

    Why it matters

    Stylesheets block rendering, so every unused rule delays the first paint.

    How to fix

    Generate per-page CSS that contains only the rules in use, and load the remainder without blocking rendering.

    Related metric: FCP

    In Warp PerformanceWarp Performance → CSS → Remove Unused CSS
  • Minify CSSLow impactPotential savings: 5 KB

    CSS files are served unminified; minifying would save about 5 KB.

    Evidence

    • jumptowebcom7b408.zapwp.com/wp-content/…utomatic-css/automatic.css?icv=faf0c589 (5 KB could be saved)

    Why it matters

    Smaller stylesheets download faster and unblock rendering sooner.

    How to fix

    Minify CSS as part of the build, or enable minification in your performance plugin.

    In Warp PerformanceWarp Performance → CSS → Minify CSS

Images

316 KB in 14 requests · 30% of page weight · Mobile

293 KB in 14 requests · 30% of page weight · Desktop

  • Optimize image deliveryMedium impactPotential savings: 137 KB

    Images are larger than they need to be: resizing, recompressing or converting them would save about 137 KB.

    Evidence

    • jumptoweb.com/wp-content/uploads/antigua-about-us-768x3298.webp (43 KB could be saved)
    • jumptoweb.com/wp-content/uploads/Home-768x2970.webp (39 KB could be saved)
    • jumptoweb.com/wp-content/uploads/Riverwalk-Ranch-Home-768x3379.webp (36 KB could be saved)

    Why it matters

    Images are usually the largest part of a page and often the LCP element.

    How to fix

    Serve images at the size they are displayed, in WebP or AVIF, with sensible compression.

    Related metric: LCP

    In Warp PerformanceWarp Performance → Media → Local Image OptimizationWarp Performance → Media → Responsive Images

Fonts

210 KB in 2 requests · 20% of page weight · Mobile

210 KB in 2 requests · 21% of page weight · Desktop

  • Keep text visible while fonts loadLow impactPotential savings: 95 ms

    2 web fonts hide text until they have loaded.

    Evidence

    • jumptowebcom7b408.zapwp.com/wp-content/…ts/fonts/fontawesome/fa-solid-900.woff2 (50 ms)
    • jumptowebcom7b408.zapwp.com/wp-content/…ricks/assets/fonts/themify/themify.woff (45 ms)

    Why it matters

    Visitors see blank space where text should be until the font arrives, which delays FCP and can delay LCP.

    How to fix

    Use font-display: swap (or optional) so text renders immediately in a fallback font.

    Related metric: FCP

    In Warp PerformanceWarp Performance → Fonts → Font Display Swap

Third Parties

649 KB from other domains in 61 requests · 61% of page weight

Service Transfer size Requests Main-thread blocking
Google Fonts Referenced in the page; not measured during the test
YouTube Referenced in the page; not measured during the test
Vimeo Referenced in the page; not measured during the test
  • Reduce the impact of third-party codeHigh impact

    Scripts and resources from other companies account for 649 KB of this page.

    Evidence

    • Third-party code: 649 KB (61% of page weight) across 61 requests
    • jumptowebcom7b408.zapwp.com — 374 KB
    • app.usercentrics.eu — 207 KB
    • privacy-proxy.usercentrics.eu — 33 KB

    Why it matters

    Tags, widgets and embeds run on the same main thread as your own code and are outside your control. They are a common cause of slow interaction.

    How to fix

    Remove tags that are no longer used, load the rest after the first interaction, and replace heavy embeds (video, maps, chat) with a lightweight placeholder that loads on click.

    Related metric: TBT

    In Warp PerformanceWarp Performance → JavaScript → Delay JavaScript

Headers & Delivery

HTTPS
Yes
HSTS
Not set
Cache-Control
Not set
Validators
ETag / Last-Modified present
Content-Type
text/html; charset=UTF-8
Vary
Accept-Encoding
  • Consider a CDNLow impact

    No CDN was detected in front of this page.

    Evidence

    • No CDN headers were present in the response

    Why it matters

    Without a CDN every visitor connects to one origin location, so distant visitors wait longer for every file.

    How to fix

    Serve static assets, and ideally HTML, through a CDN with locations near your audience.

    In Warp PerformanceWarp Performance → CDN → CDN Integration

Technology

  • WordPress Detected
    • Asset paths under /wp-content/
    • Asset paths under /wp-includes/
    • REST API discovery link (api.w.org)
    • Generator meta tag: WordPress
    • link: <https://jumptoweb.com/wp-json/>; rel="https://api.w.org/", <https://jumptoweb.com/wp-json/wp/v2/pages/2>; rel="alter…
  • nginx Detected
    • server: nginx
  • PHP Detected
    • Implied by WordPress

WordPress

Theme
bricks
REST API
Advertised
Plugins visible in the page
4 plugins

Optimization tools

Unable to determine. No optimization plugin exposed itself in the page or its headers.

Plugins referenced by asset paths

bricksextras automaticcss-plugin wp-compress-image-optimizer web-concierge-ai