Check your page speed in under 60 seconds

SiteCurl checks factors that affect load speed: page size, script count, CSS count, compression (gzip/brotli), font loading, preconnect hints, render-blocking styles, third-party scripts, image size, lazy loading, and responsive images.

These are server and markup speed checks. They catch issues you can fix in your code or server setup without needing a browser lab. Each finding shows what was measured, what the recommended target is, and how far off your page is.

SiteCurl runs these checks on every page in your scan, so you can compare speed scores across your site and find which pages need the most work.

Page speed problems are usually invisible to site owners because they visit their own site from fast connections with warm browser caches. The experience for a first-time visitor on a mobile network is very different. They are downloading every file for the first time, on a connection that may be 10x slower than your office Wi-Fi.

The most common problem is page weight. A page that loads 3 MB of JavaScript, images, and CSS feels instant on fiber but takes 8 seconds on a 3G connection. The visitor sees a blank screen, then a flash of unstyled content, then the page slowly fills in. By the time it loads, they have already hit the back button.

The second most common problem is too many files. Each file your page loads requires a separate network request. Even on fast connections, the browser can only open a limited number of connections at once. A page that loads 30 separate JavaScript and CSS files spends more time waiting for connections than actually downloading content.

Compression is the third big factor. Gzip and brotli compress text-based files (HTML, CSS, JavaScript) by 60 to 80 percent. A 200 KB JavaScript file becomes 50 KB. Yet many servers ship without compression enabled because it is not turned on by default. It is often a one-line fix.

These problems compound. A page with large files, many requests, and no compression is not just slow. It costs visitors mobile data, drains battery faster, and may not load at all on poor connections. Speed is not a nice-to-have. It is the difference between a page that works and one that does not.

Each extra second of load time costs you visitors. Research shows a one-second delay can drop conversions by 7%. Mobile users are less patient. If your page takes more than 3 seconds, over half of mobile visitors may leave before it finishes.

Speed is also a ranking factor. Google confirmed it affects rankings, especially on mobile. Their Page Experience update made speed part of the core ranking signals. Faster pages get more traffic and keep more of the visitors they get.

There is a compounding effect. A slow site has higher bounce rates. Higher bounce rates signal to Google that the content is not useful. Lower rankings mean less traffic. Less traffic means fewer conversions. Fixing speed breaks this cycle at the root.

E-commerce sites lose revenue directly. Amazon found that every 100ms of latency cost them 1% in sales. Your site is not Amazon, but the principle scales. A product page that takes 5 seconds to load converts at a fraction of the rate of one that loads in 2.

Content sites and blogs lose readers. A visitor who clicks a search result and waits 4 seconds for your article to load will click back and read the next result instead. You lose the visit and the potential to build a returning reader.

SaaS marketing pages need speed for a different reason: first impressions. If your marketing site is slow, prospects assume your product is slow too. The signup page is the last place you want a speed problem.

Step 1: Enable compression. Turn on gzip or brotli on your server. In Nginx, add gzip on; in your config. In Apache, enable mod_deflate. Cloudflare enables this automatically. This single change often cuts file transfer sizes by 60 to 80 percent.

Step 2: Reduce script count. Check how many JavaScript files your page loads. Combine scripts where possible. Defer scripts that are not needed for the initial page render by adding defer or async to the script tag. Remove scripts you no longer use.

Step 3: Optimize images. Serve images in WebP or AVIF format instead of PNG or JPEG. Use the srcset attribute to serve different sizes for different screen widths. A phone does not need a 2000px-wide hero image.

Step 4: Add lazy loading. Add loading='lazy' to images below the fold. The browser will not download them until the visitor scrolls near them. This cuts initial page weight without changing what the visitor sees.

Step 5: Cut third-party scripts. Each chat widget, analytics tool, and social embed adds weight and network requests. Audit your third-party scripts quarterly. Remove any you are not actively using. The ones you keep, load them asynchronously so they do not block your own content.

Step 6: Add preconnect hints. If your page loads fonts or files from external domains (like Google Fonts or a CDN), add <link rel='preconnect' href='https://fonts.googleapis.com'> in your HTML head. This starts the connection before the browser discovers the file.

Optimizing the wrong metric. A fast Time to First Byte (TTFB) means nothing if the browser then downloads 5 MB of JavaScript. Focus on what visitors experience: how long until the page is usable, not just how fast the server responds.

Adding lazy loading to above-the-fold images. Lazy loading delays image downloads until the user scrolls near them. If you lazy-load your hero image, it will flash in after the page renders instead of being ready when the page loads. Only lazy-load images below the fold.

Compressing images without resizing them. A 4000x3000 photo compressed to WebP is still 400 KB. Resize the image to the largest size it will be displayed (e.g., 1200px wide for a content area) before compressing. The combination of resize plus compression is what gets file sizes down.

Ignoring fonts. Web fonts add 100-300 KB per family. If you load three font weights you do not use, that is wasted bandwidth on every page load. Audit which weights and styles your CSS actually uses and remove the rest.

After making changes, run another SiteCurl scan. Compare the speed score and finding count to the previous scan. SiteCurl tracks scores over time so you can see the trend. Focus on the findings that changed: did the page size drop? Did the script count decrease?

For a quick manual check, open your browser's developer tools (F12), go to the Network tab, and reload the page with cache disabled (check 'Disable cache'). Look at the total transfer size and the number of requests. Compare before and after your changes.

For Core Web Vitals (which SiteCurl does not measure), use PageSpeed Insights or Lighthouse. SiteCurl covers the server and markup factors. Lighthouse covers the browser rendering metrics. Together they give a complete picture.

Speed issues are the easiest wins on most sites. Turn on compression, cut your script count, and add lazy loading to images below the fold. These three fixes alone can cut load times in half. Run a scan after each change to track your gains. SiteCurl stores your speed score over time so you can see if your site is getting faster or slower.