Error rate<\/strong>: Alert immediately on any 5xx errors or JavaScript console errors on critical pages<\/li>\n<\/ul>\nConfigure alert escalation policies – for example, send a Slack notification after the first failed check, page the on-call engineer after three consecutive failures, and escalate to a manager after 10 minutes of sustained degradation.<\/p>\n
Dotcom-Monitor supports alerts via email, SMS, phone call, PagerDuty, Slack, and webhook integrations, so notifications reach the right people through the right channel.<\/p>\n
Step 4: Monitor from Multiple Geographies<\/h3>\n
Performance is not uniform. Your CDN may have full coverage in North America and Europe but sparse PoP coverage in Southeast Asia, the Middle East, or Latin America. Dotcom-Monitor’s global network of monitoring nodes lets you run identical tests from locations like S\u00e3o Paulo, Singapore, Mumbai, and Tokyo – giving you an honest picture of the global user experience, not just the experience from your nearest AWS region.<\/p>\n
When you find that LCP is 2.1 seconds in London but 6.4 seconds in Jakarta, you have a specific, actionable signal: add a CDN PoP in Southeast Asia or review your CDN routing configuration for that region.<\/p>\n
Step 5: Capture Waterfall Charts and Resource Timing<\/h3>\n
Dotcom-Monitor captures detailed waterfall charts for every synthetic test run. A waterfall chart shows every resource the browser loads – HTML, CSS, JavaScript files, images, fonts, API calls – with each resource’s DNS lookup time, connection time, wait time, and transfer time visualized as horizontal bars on a shared timeline.<\/p>\n
Waterfall analysis is how you diagnose why<\/em> a page is slow, not just that<\/em> it is slow. Common findings from waterfall review:<\/p>\n\n- A render-blocking CSS file loads from a slow CDN node, adding 400 milliseconds to FCP<\/li>\n
- A third-party analytics script takes 1.8 seconds to respond, blocking the main thread<\/li>\n
- 47 image requests are not batched or lazy-loaded, creating a waterfall of sequential requests<\/li>\n
- An API call that should return in 120 milliseconds is taking 2.4 seconds intermittently<\/li>\n<\/ul>\n
None of these findings are visible from a single “page load time” metric. They require the waterfall.<\/p>\n
Step 6: Use Real Browser Testing<\/h3>\n
Many basic monitoring tools use simple HTTP health checks that verify server connectivity and response codes – they confirm the server returned a 200 status but do not execute JavaScript, parse CSS, or render the page. These checks miss the majority of frontend performance problems in modern web applications because they measure only the server response, not the complete browser experience. Note that this is a distinction of monitoring methodology, not rendering mode: headless browsers (such as those used by Puppeteer or Playwright) do fully execute JavaScript and render CSS – they simply do not display a visual interface. The relevant difference is between an HTTP-only check and a full browser-based check, regardless of whether that browser runs headed or headless.<\/p>\n
Dotcom-Monitor uses real browser engines – Chrome and Firefox – to execute your monitoring scripts. This means it captures the complete render experience: JavaScript execution time, font loading, image decode time, and layout shifts. It is the same performance data a real user’s browser generates, not an approximation.<\/p>\n
This is particularly important for single-page applications (SPAs) built on React, Angular, or Vue, where the HTML response may be a minimal shell that JavaScript fills in. A basic HTTP health check on a React SPA will report a fast server response time while the user actually waits several seconds for JavaScript to render the content.<\/p>\n
Step 7: Integrate with Your Deployment Workflow<\/h3>\n
Performance regressions most commonly originate from deployments. A developer adds a new JavaScript dependency. A designer uploads a 4MB hero image. An engineer adds a new API call in the critical path.<\/p>\n
Dotcom-Monitor’s API allows you to trigger test runs as part of your CI\/CD pipeline. Configure your deployment process to:<\/p>\n
\n- Run the Dotcom-Monitor test suite against your staging environment before promotion to production<\/li>\n
- Fail the build if any performance metric exceeds your defined thresholds<\/li>\n
- Automatically re-run the full test suite immediately after each production deployment<\/li>\n
- Compare the post-deployment performance metrics against the pre-deployment baseline<\/li>\n<\/ol>\n
This shifts performance monitoring left – catching regressions before they reach users rather than after.<\/p>\n
Point-in-time performance data has limited value. What matters is the trend. Is your LCP improving quarter-over-quarter as your team invests in performance? Is your TTFB gradually worsening as your database grows? Did a specific deployment in March 2024 cause a step-change in error rate that was never fully resolved?<\/p>\n
Dotcom-Monitor retains historical performance data and provides dashboards and reports for trend analysis. Use these to:<\/p>\n
\n- Track progress against performance improvement goals<\/li>\n
- Identify gradual degradation before it becomes a crisis<\/li>\n
- Correlate performance changes with deployments, traffic spikes, or infrastructure changes<\/li>\n
- Report performance trends to stakeholders with data, not anecdotes<\/li>\n<\/ul>\n
Monitoring tells you where problems are. These best practices tell you how to fix and prevent them.<\/p>\n
Optimize images.<\/strong> Serve images in WebP or AVIF format, size images to their display dimensions, and implement lazy loading for images below the fold. Use a CDN with automatic image optimization. This single category of optimization typically reduces page weight by 30\u201360%.<\/p>\nEliminate render-blocking resources.<\/strong> Defer non-critical JavaScript using the defer or async attribute. Inline critical CSS (the CSS needed to render above-the-fold content) and load the full stylesheet asynchronously. Move non-critical CSS to load after the initial render.<\/p>\nImplement code splitting.<\/strong> Use dynamic import() and route-based code splitting to ensure users only download the JavaScript needed for the current page. A user visiting your homepage does not need the JavaScript for your checkout flow.<\/p>\nPreload critical resources.<\/strong> Use <link rel=”preload”> for fonts, critical images, and JavaScript chunks that will be needed immediately. Use <link rel=”dns-prefetch”> for third-party domains. Use <link rel=”preconnect”> for origins where you know you will make a request.<\/p>\nMinimize third-party scripts.<\/strong> Audit every third-party script on your most critical pages. Remove scripts that are not delivering measurable value. For scripts you must keep, load them asynchronously and monitor their performance contribution in your waterfall charts. A chat widget that adds 1.5 seconds to LCP on your homepage may be doing more harm than good.<\/p>\nUse a Content Delivery Network.<\/strong> Serve all static assets – JavaScript, CSS, images, fonts – from a CDN. CDNs cache content on edge nodes geographically close to users, reducing round-trip time for assets that are frequently downloaded.<\/p>\nOptimize database queries.<\/strong> Review slow query logs regularly. Add indexes on columns used in WHERE clauses and JOIN conditions. Avoid N+1 queries by using query batching or eager loading. Use EXPLAIN ANALYZE to understand query execution plans. Set up database query monitoring so slow queries trigger alerts.<\/p>\nImplement caching at every layer.<\/strong> Cache database query results in Redis or Memcached for data that changes infrequently. Cache rendered HTML responses for pages that are identical for all users. Set appropriate browser cache headers (Cache-Control, ETag) for static assets. A well-cached application serves the majority of requests from cache, reducing server CPU and database load.<\/p>\nUse HTTP\/2 or HTTP\/3.<\/strong> HTTP\/2’s multiplexing allows multiple requests over a single TCP connection, eliminating head-of-line blocking. HTTP\/3 (QUIC) improves on this further for lossy or high-latency networks. Most CDNs and modern servers support HTTP\/2 with minimal configuration.<\/p>\nCompress responses.<\/strong> Enable Brotli or gzip compression on all text-based responses – HTML, JSON, CSS, JavaScript. Brotli typically achieves 15\u201320% better compression ratios than gzip. Compression reduces transfer size and therefore transfer time for every user.<\/p>\nScale horizontally with load balancing.<\/strong> A single application server has a finite capacity. Configure a load balancer to distribute traffic across multiple application server instances. Use auto-scaling to add capacity during traffic spikes and remove it during quiet periods.<\/p>\nMove time-consuming tasks to background jobs.<\/strong> Operations that do not need to complete before the user receives a response – sending email, resizing images, generating reports, syncing data to third-party systems – should be processed by a background job queue (Sidekiq, Celery, AWS SQS) rather than in the request-response cycle.<\/p>\nInfrastructure and Architecture Best Practices<\/h3>\n
Use a multi-region deployment strategy.<\/strong> Deploy your application in multiple geographic regions to minimize latency for users worldwide. Route users to the nearest region using GeoDNS or a global load balancer like AWS Global Accelerator or Cloudflare Load Balancing.<\/p>\nMonitor external dependencies.<\/strong> Your application’s performance depends on every external service it calls – payment processors, email providers, identity providers, analytics vendors, mapping APIs. Monitor the health and response time of these dependencies. When Stripe’s API slows down, your checkout slows down. When your identity provider has an incident, your login breaks.<\/p>\nImplement graceful degradation.<\/strong> Design your application to continue functioning – with reduced features – when dependencies fail or slow down. If your recommendation engine API is unavailable, display static product listings rather than timing out. Circuit breaker patterns prevent a slow dependency from cascading into a full application outage.<\/p>\nSet and enforce performance budgets.<\/strong> A performance budget defines the maximum acceptable values for key metrics – for example, LCP under 2.5 seconds, total JavaScript bundle size under 200KB, total page weight under 1MB. Integrate performance budget checks into your CI\/CD pipeline so developers are notified immediately when a change would violate the budget.<\/p>\nHow do you know whether your application’s performance is good? Industry benchmarks provide a reference point.<\/p>\n
For LCP, Google’s Core Web Vitals threshold of 2.5 seconds is the standard to target. According to Chrome UX Report data, the median LCP for pages that pass the Core Web Vitals assessment is approximately 1.4 seconds on desktop and approximately 2.0 seconds on mobile – though these figures shift as the web evolves.<\/p>\n
For TTFB, Google’s own guidance classifies under 800 milliseconds as “good” and over 1,800 milliseconds as “poor.” Most well-optimized applications with CDN caching achieve TTFB in the 200\u2013500 millisecond range for cached responses.<\/p>\n
For total page load time, HTTP Archive’s Web Almanac consistently reports median page load times in the 3\u20134 second range on mobile and 1.5\u20132 second range on desktop for the 50th percentile. Top-performing applications targeting the 75th percentile aim for load times under 2 seconds on desktop.<\/p>\n
For error rate, a mature production web application should maintain an error rate below 0.1% (1 in 1,000 requests). An error rate above 1% represents a significant user experience problem requiring immediate investigation.<\/p>\n
For availability, enterprise web applications typically target 99.9% uptime (8.77 hours of downtime per year). High-criticality applications target 99.95% (4.38 hours per year) or 99.99% (52.56 minutes per year).<\/p>\n
Conclusion<\/h2>\n
Web application performance is not a one-time project. It is a continuous practice. Pages slow down as applications grow. New dependencies add latency. Traffic patterns change. Infrastructure ages.<\/p>\n
The organizations that maintain fast, reliable web applications are not those that ran a performance audit once and shipped a few optimizations. They are those that monitor continuously, catch regressions early, track trends over time, and treat performance as a first-class concern in their development process.<\/p>\n
Dotcom-Monitor’s web application monitoring platform<\/a> gives your team the proactive, real-browser, multi-location synthetic monitoring<\/a> capability to do exactly that – measure what matters, detect issues before users do, and build the performance data foundation that every optimization decision should rest on.<\/p>\nStart monitoring your most critical user journeys today. Performance is not felt in milliseconds – it is felt in conversions made, carts completed, and users who return instead of leaving for a faster alternative.<\/p>\n","protected":false},"excerpt":{"rendered":"
Web application performance is not just a technical concern – it is a business imperative. Google\u2019s research shows that as page load time increases from one second to five seconds, the probability of a mobile visitor bouncing rises by 90%. Deloitte\u2019s 2020 \u201cMilliseconds Make Millions\u201d report found that a 0.1-second improvement in mobile site speed […]<\/p>\n","protected":false},"author":39,"featured_media":34009,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-34007","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/wp-json\/wp\/v2\/posts\/34007","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/wp-json\/wp\/v2\/users\/39"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/wp-json\/wp\/v2\/comments?post=34007"}],"version-history":[{"count":0,"href":"https:\/\/www.dotcom-monitor.com\/blog\/wp-json\/wp\/v2\/posts\/34007\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/wp-json\/wp\/v2\/media\/34009"}],"wp:attachment":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/wp-json\/wp\/v2\/media?parent=34007"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/wp-json\/wp\/v2\/categories?post=34007"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/wp-json\/wp\/v2\/tags?post=34007"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"Editorial](\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2026\/06\/website-monitoring-best-practices-featured-browser-facets.webp\")
Web application performance is not just a technical concern – it is a business imperative. Google\u2019s research shows that as page load time increases from one second to five seconds, the probability of a mobile visitor bouncing rises by 90%. Deloitte\u2019s 2020 \u201cMilliseconds Make Millions\u201d report found that a 0.1-second improvement in mobile site speed lifted retail conversion rates by 8.4%.<\/p>\n