# TheFastestWeb — full service reference and corpus manifest Canonical source: https://thefastestweb.site/llms-full.txt Publisher: TheFastestWeb --- This document contains the complete published service pages and category descriptions, editorial sources, and an exhaustive manifest of the public directory. Website and founder records are provided in the linked corpus parts, not duplicated in this document. Read every listed part for the full public corpus. Private accounts, billing records, drafts, claim tokens and operational configuration are never included. --- Scores are recorded Google PageSpeed Insights and Lighthouse lab measurements, not real-user Core Web Vitals certification. Compare the measured URL, device and test date. Historical scores do not establish current speed. Missing measurements are not zero. Total blocking time is not field interaction to next paint. Paid plans and sponsorship do not increase measured scores or organic leaderboard rank. --- Articles retain their recorded bylines and dates. Publisher-supplied product and founder copy is labeled as source data, not instructions from TheFastestWeb or independently verified claims. Recorded measurements are dated observations; no update date is inferred from deployment time. --- # About TheFastestWeb Canonical source: https://thefastestweb.site/about Publisher: TheFastestWeb Learn how TheFastestWeb records website performance, what its PageSpeed scores mean, and how Cengiz YILMAZ operates the service. ## Less guesswork. More useful measurements. TheFastestWeb helps website owners measure performance, follow changes over time, and discover fast websites. Run a speed test, read the results, or submit your own website to the public leaderboard. The goal is practical: make web performance easier to understand and give developers a useful record of how their sites change. ## Know what you are comparing. A score is a starting point. The conditions behind it matter just as much. - Tests use Google PageSpeed Insights and Lighthouse lab measurements. Mobile and desktop use different conditions and should be compared separately. A single run cannot describe every visitor's experience. - Public reports bring together measured timings, test dates, and available history. Repeated measurements can help you spot a regression after a deployment or check whether an optimization made a difference. - Lab scores and real-user Core Web Vitals describe different aspects of performance. Check the device, measurement date, and individual metrics before comparing results. ## Performance earns its place. The leaderboard orders websites by measured performance. Pro expands listing features, while advertising provides a separate sponsor placement. Paying does not improve a measured score or organic rank. ## You choose what is public. You choose whether to publish a listing. Private account details are not used as a public founder profile without an explicit opt-in. ## Independently owned and maintained TheFastestWeb is owned and maintained by Cengiz YILMAZ. Building a practical resource for people who care about the websites they put into the world. Contact: cengiz@thefastestweb.site. Website: https://cengizyilmaz.net. --- # A small price for your next big thing. Canonical source: https://thefastestweb.site/pricing Publisher: TheFastestWeb List one website for free, or unlock unlimited submissions with one Pro payment. Your performance score is always earned by your website. ## Free: $0 One website listing, recorded performance results and scheduled speed monitoring. A TheFastestWeb badge on your homepage is required. Listing and monitoring depend on eligibility and service availability. ## Pro: $9 USD, one-time Account access for unlimited website submissions with no badge requirement. A one-time payment, not a recurring listing subscription. Dodo Payments handles checkout; applicable taxes and the final amount are shown there. ## Sidebar advertising: $19 USD per month One sponsored desktop sidebar placement, subject to inventory, listing ownership and creative approval. Advertising is separate from organic rankings. Review placement details at /advertise. --- # Put your product beside the leaderboard. Canonical source: https://thefastestweb.site/advertise Publisher: TheFastestWeb Reach people exploring website performance with a sponsored sidebar placement. Clear monthly pricing, a direct website link and your published product details. ## A place alongside the rankings Your placement appears in an available left or right sidebar on desktop layouts wider than 1100 pixels. Sidebars are hidden on smaller screens. A placement contains the website icon, name, tagline and a link to its destination. Sponsored placements are separate from the leaderboard. Buying an ad does not change a website’s measured performance score or organic position. ## $19 USD per month One placement is billed monthly through Dodo Payments. Availability is checked before checkout. Applicable taxes and the final amount are shown at checkout; the subscription renews until cancelled or its billing term ends. ## Start with a published website Sign in using the account that owns the published listing, then use its URL to request a placement. The checkout uses the listing’s published name and tagline. Listing ownership and creative approval are required; a purchase does not bypass content review. ## Manage your subscription Request cancellation through your billing portal or contact cengiz@thefastestweb.site. Cancellation stops future renewals; a valid paid placement remains available until the end of its paid period. --- # Privacy policy Canonical source: https://thefastestweb.site/privacy Publisher: TheFastestWeb Updated: 2026-09-20T00:00:00.000Z How TheFastestWeb handles account information, website measurements, email preferences and privacy requests. ## Overview TheFastestWeb ("we", "our", "us") is operated by Cengiz YILMAZ. This policy explains what data we collect, how we use it, and how to contact us about your information. ## Data We Collect ### Account data (when you sign in) When you sign in with Google, we receive your name, email address, and profile picture. We use this information to maintain your account and associate it with websites you manage. Your email is not published. A public founder profile requires a separate opt-in. ### Submitted site data When you submit a website, we store the URL, site name, description, category, country of origin, and speed test results. This data powers the leaderboard and daily retesting. The country describes the product’s origin, not your citizenship or the location of its hosting server. ### Speed test data We store tested URLs and performance measurements. Request identifiers are used to enforce rate limits and prevent abuse. Signed-in submissions are associated with the account that requested them. ### Payment data Dodo Payments processes payments and manages billing. We do not store card numbers or card security codes. We retain order references, amounts, payment status, and subscription records to provide purchases and reconcile refunds or cancellations. ### Ad slot data If you purchase an ad slot, we store your website name, URL, and tagline to display it. Click counts use a daily pseudonymous identifier to reduce duplicates; the click record does not retain the raw IP address, browser, or referrer. ### Badge verification When a free plan user submits a site, we fetch their homepage HTML server-side to verify the TheFastestWeb badge is present. We do not store the HTML content — only whether the badge was found (pass/fail). We may re-check periodically as part of badge compliance monitoring. ## How We Use Your Data - To display your site on the public leaderboard (if you opt in) - To run daily speed retests and send trend alert emails - To send transactional emails (Pro upgrade confirmation, welcome email) - To enforce rate limits and prevent abuse - To provide ad click reports to advertisers - To verify badge embed compliance on free plan homepages - To manage listing visibility and your monitoring preferences We do not sell your data. We do not use your data for advertising purposes. ## Third-Party Services - Google OAuth: used for sign-in. Governed by Google's Privacy Policy. - Google PageSpeed Insights API: used to run speed tests. URLs you test are sent to Google's API. - Dodo Payments: payment processing, invoices, subscriptions, and billing support. - Self-hosted infrastructure: application hosting, PostgreSQL storage, and Redis queues managed through Coolify. - Microsoft 365: transactional email delivery through Microsoft Graph when email is enabled. - Cloudflare R2: storage for generated website screenshots when screenshot storage is enabled. - Visitor analytics: DataFast measures public page visits in cookieless mode. It uses a pseudonymous identifier derived by the provider from signals including IP address, browser information, domain and a daily rotating salt. Private account pages, query strings and sensitive referrers are excluded. Eligible initial purchases can be linked to the current visit using their confirmed amount, currency and transaction ID; no account name or email is sent for attribution. Longer-term and cross-day attribution is limited. Google Analytics is not loaded. - Crawler analytics: When enabled, the separate DataFast server integration observes requests identified as AI or search crawlers. It sends the public page path and crawler user agent, and may send the crawler IP when our trusted proxy is configured for IP verification. It excludes private routes, query strings, cookies and authorization headers. Crawler classifications are estimates, not proof that a visitor is human. ## Data Retention We retain account information, website measurements, and operational records while needed to provide the service. Billing records may need to be retained for accounting and dispute handling. Contact us to request deletion or ask which records are held about you. ## Your Rights You can request to: - Access the data we hold about you - Delete your account and associated data - Remove your site from the public leaderboard To make a request, email us at cengiz@thefastestweb.site. ## Contact Questions about this policy? Email us at cengiz@thefastestweb.site . --- # Terms of service Canonical source: https://thefastestweb.site/terms Publisher: TheFastestWeb Updated: 2026-09-20T00:00:00.000Z Read the terms for using TheFastestWeb, including website submissions, account responsibilities and paid services. ## Acceptance By using TheFastestWeb ("the Service"), you agree to these Terms. If you do not agree, do not use the Service. The Service is operated by Cengiz YILMAZ. ## What the Service Does TheFastestWeb is a public speed leaderboard and monitoring tool for websites. It lets users test website performance, submit listings, and view recorded results. Scheduled retests and email alerts depend on service availability and the account's preferences. ## Accounts You must sign in with a Google account to submit a website. You are responsible for maintaining the security of your account. You must not use another person's account or submit websites you do not own or have permission to submit. ## Submitted Content By submitting a website, you confirm that you own or have permission to list it. We reserve the right to remove any listing that: - Contains illegal, harmful, or deceptive content - Violates third-party intellectual property rights - Is submitted with false or misleading information - We determine, at our discretion, is inappropriate for the directory ## Free and Pro Plans The free plan allows submission of one website with a dofollow backlink. Free plan listings require a TheFastestWeb badge to be embedded on your site homepage (see Section 6). Listing and monitoring availability depend on the site remaining eligible and accessible. The Pro plan is a one-time payment of $9 and includes unlimited website submissions, dofollow backlinks, and no badge requirement. Dodo Payments handles checkout and billing. Any applicable taxes and the final amount are shown at checkout. For billing issues or refund requests, contact us using the address below; applicable statutory rights are unaffected. ## Badge Embed Requirement (Free Plan) Free plan users must embed a TheFastestWeb speed badge on their site homepage before submission is accepted. By embedding the badge, you confirm you have permission to place third-party content on that page. - We periodically verify the badge is present on your homepage. - Missing or invalid badges may affect a free listing's eligibility. - Pro plan users are exempt from the badge requirement. ## Ad Slots Ad slots are monthly subscriptions at $19/month through Dodo Payments. You may request cancellation through your billing portal or by contacting us. Cancellation stops future renewals, and a valid paid placement remains available until the end of its paid period. We reserve the right to reject or remove ad content that violates these Terms. ## Speed Testing Speed tests use the Google PageSpeed Insights API. Lighthouse lab results may vary between runs and devices. We do not guarantee specific scores, search rankings, or other outcomes. Usage limits and provider availability may restrict the number of tests. ## Backlinks Both free and Pro listings receive a dofollow backlink. Backlinks are provided as part of the listing service and are not guaranteed to improve search rankings. We reserve the right to modify link attributes in accordance with search engine guidelines. ## Prohibited Use You may not use the Service to: - Scrape, crawl, or bulk-test URLs in an automated manner - Attempt to game or manipulate leaderboard rankings - Submit spam, phishing, or malware sites - Interfere with or disrupt the Service ## Disclaimer The Service is provided "as is" without warranties of any kind. We do not guarantee uptime, accuracy of speed scores, or uninterrupted access. We are not liable for any damages arising from your use of the Service. ## Changes We may update these Terms at any time. Continued use of the Service after changes constitutes acceptance of the updated Terms. ## Contact Questions? Email us at cengiz@thefastestweb.site . --- # Website categories Canonical source: https://thefastestweb.site/categories Publisher: TheFastestWeb Browse the IndieTools interest categories and the original website types. Each collection links to public websites and their recorded mobile lab performance. Scores are recorded Google PageSpeed Insights and Lighthouse lab measurements, not real-user Core Web Vitals certification. Compare the measured URL, device and test date. Historical scores do not establish current speed. Missing measurements are not zero. Total blocking time is not field interaction to next paint. Paid plans and sponsorship do not increase measured scores or organic leaderboard rank. ## IndieTools categories ### [AI](https://thefastestweb.site/markdown/fastest/ai) AI assistants, generation tools and machine-learning products with a public website. Compare how quickly the public landing page explains the product before an interactive model or workspace loads. Public leaderboard: https://thefastestweb.site/fastest/ai ### [Analytics](https://thefastestweb.site/markdown/fastest/analytics) Website analytics, audience measurement and reporting products. Look at loading and blocking time on the public product page; a public test does not measure an authenticated dashboard. Public leaderboard: https://thefastestweb.site/fastest/analytics ### [CMS](https://thefastestweb.site/markdown/fastest/cms) Content management systems, publishing platforms and headless CMS products. Compare the public site rather than assuming its score describes every website built with the CMS. Public leaderboard: https://thefastestweb.site/fastest/cms ### [Design](https://thefastestweb.site/markdown/fastest/design) Design tools, creative resources and products for visual work. Image-heavy showcases make largest contentful paint and layout stability useful alongside the overall score. Public leaderboard: https://thefastestweb.site/fastest/design ### [Developer tools](https://thefastestweb.site/markdown/fastest/developer-tools) Developer services, APIs, debugging tools and software development utilities. Check the recorded mobile result and its date when comparing documentation-rich product pages. Public leaderboard: https://thefastestweb.site/fastest/developer-tools ### [Finance](https://thefastestweb.site/markdown/fastest/finance) Budgeting, invoicing, accounting and financial management product websites. These results describe website loading performance, not a financial product's suitability, reliability or security. Public leaderboard: https://thefastestweb.site/fastest/finance ### [Fitness](https://thefastestweb.site/markdown/fastest/fitness) Fitness, workout, training and activity product websites. Compare mobile loading performance on public pages; scores do not evaluate training advice or health outcomes. Public leaderboard: https://thefastestweb.site/fastest/fitness ### [Games](https://thefastestweb.site/markdown/fastest/games) Browser games, gaming products and game-related websites. A landing-page score describes page loading and does not benchmark frame rate or gameplay performance. Public leaderboard: https://thefastestweb.site/fastest/games ### [Lifestyle](https://thefastestweb.site/markdown/fastest/lifestyle) Lifestyle products for everyday interests, activities and experiences. Read the individual report to see which URL was tested and when its performance was recorded. Public leaderboard: https://thefastestweb.site/fastest/lifestyle ### [Marketing](https://thefastestweb.site/markdown/fastest/marketing) Marketing platforms, growth tools, email products and campaign services. Compare the effect of media, third-party scripts and interactive content through the published loading metrics. Public leaderboard: https://thefastestweb.site/fastest/marketing ### [Personal life](https://thefastestweb.site/markdown/fastest/personal-life) Products for personal organization, daily routines and individual projects. A responsive public page can help visitors understand the product; the report measures that page, not private account screens. Public leaderboard: https://thefastestweb.site/fastest/personal-life ### [Productivity](https://thefastestweb.site/markdown/fastest/productivity) Task management, note-taking, scheduling and workflow product websites. Use the individual metrics to compare public pages without treating the score as a measure of the product's productivity benefits. Public leaderboard: https://thefastestweb.site/fastest/productivity ### [Programming](https://thefastestweb.site/markdown/fastest/programming) Programming resources, coding products and language-focused websites. Public examples and embedded editors can affect loading; inspect blocking time as well as the overall score. Public leaderboard: https://thefastestweb.site/fastest/programming ### [SEO](https://thefastestweb.site/markdown/fastest/seo) Search optimization tools, site auditing products and search research platforms. A PageSpeed performance score is one lab measurement; it is not a search ranking or a complete SEO audit. Public leaderboard: https://thefastestweb.site/fastest/seo ### [Social media](https://thefastestweb.site/markdown/fastest/social-media) Social publishing, scheduling, community and audience management products. Embedded feeds and third-party media can affect page loading, so compare the measured URL and test date. Public leaderboard: https://thefastestweb.site/fastest/social-media ## Website types ### [SaaS](https://thefastestweb.site/markdown/fastest/saas) Software-as-a-service products and hosted web applications. The recorded score measures the submitted public URL, not every part of the application. Public leaderboard: https://thefastestweb.site/fastest/saas ### [Tools](https://thefastestweb.site/markdown/fastest/tool) Useful web tools, utilities and focused online services. Compare the published loading metrics and the measurement date for each tool. Public leaderboard: https://thefastestweb.site/fastest/tool ### [Directories](https://thefastestweb.site/markdown/fastest/directory) Directories, searchable collections and listing websites. Large collections can load differently from their detail pages; check the specific URL in each report. Public leaderboard: https://thefastestweb.site/fastest/directory ### [Agencies](https://thefastestweb.site/markdown/fastest/agency) Agency, studio and professional service websites. Project imagery and animation can affect loading; compare both contentful paint and layout stability. Public leaderboard: https://thefastestweb.site/fastest/agency ### [E-commerce](https://thefastestweb.site/markdown/fastest/ecommerce) Online stores, shopping platforms and commerce websites. Public homepage measurements do not represent every product page or checkout step. Public leaderboard: https://thefastestweb.site/fastest/ecommerce ### [Blogs](https://thefastestweb.site/markdown/fastest/blog) Blogs, editorial publications and content-led websites. Images, fonts and embeds can affect article loading; follow each report to inspect its measured URL. Public leaderboard: https://thefastestweb.site/fastest/blog ### [Portfolios](https://thefastestweb.site/markdown/fastest/portfolio) Portfolio websites, personal showcases and project collections. Compare image loading and layout stability as well as the overall recorded score. Public leaderboard: https://thefastestweb.site/fastest/portfolio ### [Other](https://thefastestweb.site/markdown/fastest/other) Public websites that do not fit one of the more specific categories. Choose a specific category when it matches your website so visitors can make more relevant comparisons. Public leaderboard: https://thefastestweb.site/fastest/other --- # Website performance journal Canonical source: https://thefastestweb.site/blog Publisher: TheFastestWeb Published guides about page loading, lab measurements and website performance. Each article retains its original byline and publication date; a redesign does not make an older guide newly updated. ## [Astro PageSpeed Optimization Guide](https://thefastestweb.site/markdown/blog/astro-pagespeed-optimization-guide) Astro ships zero JavaScript by default, making it one of the fastest frameworks available. Here's how to keep your Astro site scoring in the 90s and what can still go wrong. Author: TheFastestWeb Published: 2026-03-14T00:00:00.000Z Canonical article: https://thefastestweb.site/blog/astro-pagespeed-optimization-guide ## [Django PageSpeed Optimization Guide](https://thefastestweb.site/markdown/blog/django-pagespeed-optimization-guide) Django is a Python web framework that can serve very fast pages with the right configuration. Here's how to optimize a Django site for top PageSpeed scores. Author: TheFastestWeb Published: 2026-03-25T00:00:00.000Z Canonical article: https://thefastestweb.site/blog/django-pagespeed-optimization-guide ## [Does Page Speed Affect SEO Rankings?](https://thefastestweb.site/markdown/blog/does-page-speed-affect-seo) How Core Web Vitals relate to Google Search, why Lighthouse scores differ from field data, and how to prioritize performance improvements. Author: TheFastestWeb Published: 2026-03-28T00:00:00.000Z Updated: 2026-09-20T00:00:00.000Z Canonical article: https://thefastestweb.site/blog/does-page-speed-affect-seo ## [How to Check Website Speed (Free Tools)](https://thefastestweb.site/markdown/blog/how-to-check-website-speed) A practical guide to the best free tools for checking website speed, what each one measures, and when to use which one. Author: TheFastestWeb Published: 2026-03-27T00:00:00.000Z Canonical article: https://thefastestweb.site/blog/how-to-check-website-speed ## [How to Get a 100 PageSpeed Score](https://thefastestweb.site/markdown/blog/how-to-get-100-pagespeed-score) A perfect 100 PageSpeed score is achievable for most sites. Here's exactly what it takes and what the fastest sites on the web have in common. Author: TheFastestWeb Published: 2026-03-21T00:00:00.000Z Canonical article: https://thefastestweb.site/blog/how-to-get-100-pagespeed-score ## [Laravel PageSpeed Optimization Guide](https://thefastestweb.site/markdown/blog/laravel-pagespeed-optimization-guide) Laravel is a PHP framework that can power very fast websites when configured correctly. Here's how to optimize a Laravel app for high PageSpeed scores. Author: TheFastestWeb Published: 2026-03-24T00:00:00.000Z Canonical article: https://thefastestweb.site/blog/laravel-pagespeed-optimization-guide ## [Next.js Performance Optimization Guide](https://thefastestweb.site/markdown/blog/nextjs-performance-optimization-guide) Next.js gives you a great starting point for performance, but there's plenty that can go wrong. Here's how to get the most out of your Next.js site's PageSpeed score. Author: TheFastestWeb Published: 2026-03-18T00:00:00.000Z Canonical article: https://thefastestweb.site/blog/nextjs-performance-optimization-guide ## [Next.js vs Nuxt: Which Is Faster?](https://thefastestweb.site/markdown/blog/nextjs-vs-nuxt-speed) Next.js and Nuxt are the leading meta-frameworks for React and Vue. Here's how they compare on performance, what affects speed on each, and which to choose. Author: TheFastestWeb Published: 2026-03-20T00:00:00.000Z Canonical article: https://thefastestweb.site/blog/nextjs-vs-nuxt-speed ## [Nuxt PageSpeed Optimization Guide](https://thefastestweb.site/markdown/blog/nuxt-pagespeed-optimization-guide) Nuxt gives you SSR and static generation out of the box, but there are several things that can hurt your PageSpeed score. Here's how to optimize a Nuxt site for top performance. Author: TheFastestWeb Published: 2026-03-13T00:00:00.000Z Canonical article: https://thefastestweb.site/blog/nuxt-pagespeed-optimization-guide ## [Shopify PageSpeed Optimization Guide](https://thefastestweb.site/markdown/blog/shopify-pagespeed-optimization-guide) Shopify stores often struggle with PageSpeed scores because of heavy themes and app scripts. Here's how to fix it and get your store loading faster. Author: TheFastestWeb Published: 2026-03-15T00:00:00.000Z Canonical article: https://thefastestweb.site/blog/shopify-pagespeed-optimization-guide ## [Shopify vs WooCommerce: Which Is Faster?](https://thefastestweb.site/markdown/blog/shopify-vs-woocommerce-speed) Shopify and WooCommerce power most of e-commerce, but they take different approaches that directly affect performance. Here's how they compare on real-world speed. Author: TheFastestWeb Published: 2026-03-19T00:00:00.000Z Canonical article: https://thefastestweb.site/blog/shopify-vs-woocommerce-speed ## [Squarespace PageSpeed Optimization Guide](https://thefastestweb.site/markdown/blog/squarespace-pagespeed-optimization-guide) Squarespace controls most of its own infrastructure, but there are still practical steps you can take to improve your PageSpeed score. Here's what works. Author: TheFastestWeb Published: 2026-03-23T00:00:00.000Z Canonical article: https://thefastestweb.site/blog/squarespace-pagespeed-optimization-guide ## [SvelteKit PageSpeed Optimization Guide](https://thefastestweb.site/markdown/blog/sveltekit-pagespeed-optimization-guide) SvelteKit ships less JavaScript than any other major framework. Here's how to configure it for top PageSpeed scores and avoid the common pitfalls. Author: TheFastestWeb Published: 2026-03-21T00:00:00.000Z Canonical article: https://thefastestweb.site/blog/sveltekit-pagespeed-optimization-guide ## [Webflow PageSpeed Optimization Guide](https://thefastestweb.site/markdown/blog/webflow-pagespeed-optimization-guide) Webflow generates clean code but there are still several things that can drag your PageSpeed score down. Here's how to optimize a Webflow site for speed. Author: TheFastestWeb Published: 2026-03-16T00:00:00.000Z Canonical article: https://thefastestweb.site/blog/webflow-pagespeed-optimization-guide ## [What Are Core Web Vitals? (Explained Simply)](https://thefastestweb.site/markdown/blog/what-are-core-web-vitals) Core Web Vitals are three metrics Google uses to measure real-world user experience. Here's what they are, why they matter, and what scores you should aim for. Author: TheFastestWeb Published: 2026-03-29T00:00:00.000Z Canonical article: https://thefastestweb.site/blog/what-are-core-web-vitals ## [What Is a Good PageSpeed Score?](https://thefastestweb.site/markdown/blog/what-is-a-good-pagespeed-score) A score of 90+ is good, but context matters. Here's what PageSpeed scores actually mean, what's realistic for different site types, and what to aim for. Author: TheFastestWeb Published: 2026-03-26T00:00:00.000Z Canonical article: https://thefastestweb.site/blog/what-is-a-good-pagespeed-score ## [What Is CLS and How to Fix It](https://thefastestweb.site/markdown/blog/what-is-cls-and-how-to-fix-it) Cumulative Layout Shift measures visual stability. It's worth 25% of your PageSpeed score and one of the easiest Core Web Vitals to fix once you know what's causing it. Author: TheFastestWeb Published: 2026-03-19T00:00:00.000Z Canonical article: https://thefastestweb.site/blog/what-is-cls-and-how-to-fix-it ## [What Is FCP and How to Fix It](https://thefastestweb.site/markdown/blog/what-is-fcp-and-how-to-fix-it) First Contentful Paint measures how quickly your page shows its first piece of content. It's worth 10% of your PageSpeed score and affects how fast your site feels. Author: TheFastestWeb Published: 2026-03-12T00:00:00.000Z Canonical article: https://thefastestweb.site/blog/what-is-fcp-and-how-to-fix-it ## [What Is LCP and How to Fix It](https://thefastestweb.site/markdown/blog/what-is-lcp-and-how-to-fix-it) Largest Contentful Paint is one of the most important Core Web Vitals. Here's what it measures, why it matters, and how to improve it. Author: TheFastestWeb Published: 2026-03-22T00:00:00.000Z Canonical article: https://thefastestweb.site/blog/what-is-lcp-and-how-to-fix-it ## [What Is PageSpeed Insights and How to Use It](https://thefastestweb.site/markdown/blog/what-is-pagespeed-insights) Google PageSpeed Insights is the standard tool for measuring website performance. Here's what it measures, how to read the results, and what to do with them. Author: TheFastestWeb Published: 2026-03-30T00:00:00.000Z Canonical article: https://thefastestweb.site/blog/what-is-pagespeed-insights ## [What Is Speed Index and How to Fix It](https://thefastestweb.site/markdown/blog/what-is-speed-index-and-how-to-fix-it) Speed Index measures how quickly content is visually populated on your page. Here's what it means and how to improve it. Author: TheFastestWeb Published: 2026-03-10T00:00:00.000Z Canonical article: https://thefastestweb.site/blog/what-is-speed-index-and-how-to-fix-it ## [What Is TBT and How to Fix It](https://thefastestweb.site/markdown/blog/what-is-tbt-and-how-to-fix-it) Total Blocking Time is the biggest factor in your PageSpeed score at 30%. Here's what it measures and how to reduce it. Author: TheFastestWeb Published: 2026-03-20T00:00:00.000Z Canonical article: https://thefastestweb.site/blog/what-is-tbt-and-how-to-fix-it ## [What Is TTI and How to Fix It](https://thefastestweb.site/markdown/blog/what-is-tti-and-how-to-fix-it) Time to Interactive measures when your page is fully ready to respond to user input. Here's what causes high TTI and how to fix it. Author: TheFastestWeb Published: 2026-03-11T00:00:00.000Z Canonical article: https://thefastestweb.site/blog/what-is-tti-and-how-to-fix-it ## [Why Your PageSpeed Score Dropped (And How to Fix It)](https://thefastestweb.site/markdown/blog/why-your-pagespeed-score-dropped) A sudden PageSpeed score drop can silently kill your Google rankings before you notice. Here's how to diagnose what went wrong and recover fast. Author: TheFastestWeb Published: 2026-03-23T00:00:00.000Z Updated: 2026-09-20T00:00:00.000Z Canonical article: https://thefastestweb.site/blog/why-your-pagespeed-score-dropped ## [Wix PageSpeed Optimization Guide](https://thefastestweb.site/markdown/blog/wix-pagespeed-optimization-guide) Wix handles hosting and infrastructure for you, but there are still several things you can do to improve your PageSpeed score. Here's what works and what doesn't. Author: TheFastestWeb Published: 2026-03-22T00:00:00.000Z Canonical article: https://thefastestweb.site/blog/wix-pagespeed-optimization-guide ## [WordPress PageSpeed Optimization Guide](https://thefastestweb.site/markdown/blog/wordpress-pagespeed-optimization-guide) WordPress powers 40% of the web but is notorious for slow scores. Here's exactly how to get a fast PageSpeed score on WordPress without breaking your site. Author: TheFastestWeb Published: 2026-03-17T00:00:00.000Z Canonical article: https://thefastestweb.site/blog/wordpress-pagespeed-optimization-guide ## [WordPress vs Webflow: Which Is Faster?](https://thefastestweb.site/markdown/blog/wordpress-vs-webflow-speed) WordPress and Webflow take very different approaches to building websites. Here's how they compare on real-world PageSpeed scores and what affects performance on each. Author: TheFastestWeb Published: 2026-03-18T00:00:00.000Z Canonical article: https://thefastestweb.site/blog/wordpress-vs-webflow-speed --- ## Complete corpus manifest Published website records: 155. Public founder profiles: 146. Published articles: 27. Read every listed part to obtain the complete public corpus. Website and founder records are separate from this service reference. Each part contains at most 200 records; article parts also have a 1 MiB bound and preserve whole articles. Part numbers start at zero. Parts are ordered deterministically and include previous/next links. The live directory can change between requests; re-read this manifest when collecting a new snapshot. - [sites part 1](https://thefastestweb.site/llms/sites/0.md): 155 records. - [articles part 1](https://thefastestweb.site/llms/articles/0.md): 27 records. - [founders part 1](https://thefastestweb.site/llms/founders/0.md): 146 records. --- # Astro PageSpeed Optimization Guide Canonical source: https://thefastestweb.site/blog/astro-pagespeed-optimization-guide Publisher: TheFastestWeb Author: TheFastestWeb Published: 2026-03-14T00:00:00.000Z Astro ships zero JavaScript by default, making it one of the fastest frameworks available. Here's how to keep your Astro site scoring in the 90s and what can still go wrong. Astro is built for performance. It ships zero JavaScript to the browser by default, uses static generation out of the box, and produces minimal, clean HTML. Most Astro sites score 90-100 on PageSpeed without any optimization. But there are still things that can drag your score down. Here's what to watch for and how to fix it. ## Why Astro Is Fast by Default Astro's architecture is fundamentally different from React or Vue SPAs: - **Zero JS by default.** Components render to static HTML at build time. No hydration overhead. - **Islands architecture.** Only interactive components ship JavaScript, and only when needed. - **Static output.** Pages are pre-rendered and served instantly from a CDN. - **No layout shifts from hydration.** Content is in the HTML from the start. This means TBT is near zero, FCP is fast, and CLS from hydration doesn't exist. Your score problems, if any, will come from images, fonts, or the interactive islands you add. ## What Can Still Hurt Your Astro Score ### 1. Unoptimized Images The most common issue. Astro's built-in `` component from `@astrojs/image` handles optimization, but only if you use it. **Fix:** Use Astro's Image component instead of raw `` tags: ```astro --- import { Image } from "astro:assets"; import heroImage from "../assets/hero.jpg"; --- Hero ``` This automatically converts to WebP, generates srcset, and sets correct dimensions to prevent CLS. For external images, compress and resize them before referencing them. Aim for under 100KB for hero images. ### 2. The LCP Image Not Being Prioritized Astro lazy-loads images by default. Your hero image should load eagerly. **Fix:** Add `loading="eager"` and `fetchpriority="high"` to your LCP image: ```astro Hero ``` ### 3. Too Many Client-Side Islands Every time you use `client:load`, `client:visible`, or `client:idle` on a component, you're shipping JavaScript. If you have many interactive islands loading on the initial page view, TBT will climb. **Fix:** Use the right hydration directive for each component: - `client:load` - loads immediately (use only when necessary) - `client:idle` - loads when the browser is idle (good for non-critical UI) - `client:visible` - loads when the component enters the viewport (best for below-fold) - `client:media` - loads only on certain screen sizes Replace `client:load` with `client:idle` wherever the component doesn't need to be interactive immediately. ### 4. Third-Party Scripts Analytics, chat widgets, and other third-party scripts affect Astro sites just like any other. Astro doesn't shield you from these. **Fix:** Use Astro's ` ``` Or use a lightweight analytics tool. Astro integrates well with Partytown, which runs third-party scripts in a web worker off the main thread: ```bash npx astro add partytown ``` ### 5. Google Fonts Loading fonts from Google Fonts adds an external DNS lookup and render-blocking request. **Fix:** Download your fonts and self-host them in your `public/fonts/` directory. Add `font-display: swap` and preload your primary font: ```html ``` ### 6. View Transitions API Overhead Astro's View Transitions feature (``) adds a small JavaScript bundle to enable smooth page transitions. If you're chasing a perfect 100 score, this adds a few milliseconds of TBT. For most sites the trade-off is worth it. If you're obsessing over those last few points, you can remove it. ## Astro Score Targets Astro sites consistently outperform other frameworks. Realistic targets: | Setup | Realistic Score | |---|---| | Static site, optimized images, no third-party | 95-100 | | Few interactive islands, lightweight analytics | 90-95 | | Multiple client:load islands, third-party scripts | 75-90 | | Heavy SSR with dynamic content | 70-85 | ## Deployment Matters Astro's static output shines when deployed to edge networks. The fastest options: - **Cloudflare Pages** - free, global edge, fastest TTFB - **Vercel** - excellent DX, fast edge network - **Netlify** - solid, slightly slower than the above two - **Astro's own hosting (Astro DB / Starlight)** - optimized for Astro Avoid deploying static Astro sites to traditional shared hosting. The CDN is where the speed comes from. ## Quick Checklist - [ ] Using `astro:assets` Image component for all images - [ ] Hero/LCP image has `loading="eager"` and `fetchpriority="high"` - [ ] All images under 100KB for hero, 30KB for thumbnails - [ ] Islands use `client:idle` or `client:visible` instead of `client:load` where possible - [ ] Third-party scripts use `defer` or Partytown - [ ] Fonts are self-hosted with preload - [ ] Deployed to edge CDN (Cloudflare Pages or Vercel) If you're using Astro and scoring below 85, something specific is causing it. The most likely culprits are images and third-party scripts. [Test your Astro site](/test) to get your exact score and a breakdown of what's affecting each metric. --- # Django PageSpeed Optimization Guide Canonical source: https://thefastestweb.site/blog/django-pagespeed-optimization-guide Publisher: TheFastestWeb Author: TheFastestWeb Published: 2026-03-25T00:00:00.000Z Django is a Python web framework that can serve very fast pages with the right configuration. Here's how to optimize a Django site for top PageSpeed scores. Django is a batteries-included Python web framework used by some of the highest-traffic sites on the web. With the right setup, Django sites can score 90+ on PageSpeed. Without it, they often score in the 40s-60s due to slow TTFB and unoptimized assets. Here's how to optimize Django for performance. ## Reduce TTFB: The Foundation Everything starts with how quickly Django responds to requests. A slow TTFB means slow FCP, LCP, and everything else. ### Use a Production-Ready Server Never run `python manage.py runserver` in production. Use Gunicorn or uWSGI: ```bash gunicorn myapp.wsgi:application --workers 4 --bind 0.0.0.0:8000 ``` Workers should be `2 * CPU cores + 1`. For async views, consider Uvicorn with Gunicorn: ```bash gunicorn myapp.asgi:application -k uvicorn.workers.UvicornWorker --workers 4 ``` ### Enable Database Query Optimization Unoptimized database queries are the most common cause of slow TTFB. Use Django's query optimization tools: ```python # Bad: N+1 query problem for article in Article.objects.all(): print(article.author.name) # One query per article # Good: Single query with JOIN articles = Article.objects.select_related("author").all() ``` For many-to-many or reverse FK relationships: ```python articles = Article.objects.prefetch_related("tags").all() ``` Enable query logging in development to catch N+1 problems before they hit production: ```python # settings.py (development only) LOGGING = { "version": 1, "handlers": {"console": {"class": "logging.StreamHandler"}}, "loggers": { "django.db.backends": { "handlers": ["console"], "level": "DEBUG", } }, } ``` ### Use Caching Aggressively Django's cache framework supports multiple backends. Use Redis for production: ```bash pip install django-redis ``` ```python # settings.py CACHES = { "default": { "BACKEND": "django_redis.cache.RedisCache", "LOCATION": "redis://127.0.0.1:6379/1", "OPTIONS": { "CLIENT_CLASS": "django_redis.client.DefaultClient", }, } } ``` Cache expensive views with the `cache_page` decorator: ```python from django.views.decorators.cache import cache_page @cache_page(60 * 60) # Cache for 1 hour def blog_list(request): articles = Article.objects.select_related("author").published() return render(request, "blog/list.html", {"articles": articles}) ``` Or cache at the template fragment level for pages with some dynamic content: ```html {% load cache %} {% cache 3600 article_list %} {% endcache %} ``` ## Optimize Static File Delivery ### Use WhiteNoise for Simple Deployments WhiteNoise serves static files efficiently from Django itself with correct cache headers and compression: ```bash pip install whitenoise ``` ```python # settings.py MIDDLEWARE = [ "django.middleware.security.SecurityMiddleware", "whitenoise.middleware.WhiteNoiseMiddleware", # ... ] STATICFILES_STORAGE = "whitenoise.storage.CompressedManifestStaticFilesStorage" ``` WhiteNoise adds Brotli and gzip compression automatically and sets long-term cache headers for versioned files. ### Use a CDN for Production Scale For higher traffic, serve static files from a CDN: ```python # settings.py STATIC_URL = "https://your-cdn.example.com/static/" MEDIA_URL = "https://your-cdn.example.com/media/" ``` Use django-storages with S3 or a similar service: ```bash pip install django-storages boto3 ``` ```python DEFAULT_FILE_STORAGE = "storages.backends.s3boto3.S3Boto3Storage" STATICFILES_STORAGE = "storages.backends.s3boto3.S3StaticStorage" ``` Serve assets from S3 + CloudFront for global CDN distribution. ### Run collectstatic in Deployment ```bash python manage.py collectstatic --noinput ``` This copies all static files to `STATIC_ROOT` and (with WhiteNoise or custom storage) adds content hashes to filenames for long-term caching. ## Optimize Frontend Assets ### Minify JavaScript and CSS Use a bundler like Vite or webpack for your frontend assets: ```bash npm install vite ``` Or use Django's built-in static files with a minification library: ```bash pip install django-compressor ``` ```python INSTALLED_APPS = ["compressor", ...] COMPRESS_ENABLED = True COMPRESS_OFFLINE = True # Pre-compress for production ``` In templates: ```html {% load compress %} {% compress css %} {% endcompress %} ``` ### Defer Non-Critical JavaScript In your base template, ensure scripts don't block rendering: ```html ``` ## Optimize Images ### Process Images on Upload Use Pillow (already a Django dependency) or ImageKit for automatic image optimization: ```bash pip install django-imagekit ``` ```python from imagekit.models import ImageSpecField from imagekit.processors import ResizeToFit class Article(models.Model): image = models.ImageField(upload_to="articles/") image_thumbnail = ImageSpecField( source="image", processors=[ResizeToFit(800, 600)], format="WEBP", options={"quality": 85}, ) ``` ### Always Set Width and Height Prevent layout shift in templates: ```html {{ article.title }} ``` For your hero/LCP image, use `loading="eager"` (or omit the attribute). ## Use Database Connection Pooling Django opens a new database connection per request by default. Use a connection pooler: ```bash pip install django-db-connection-pool ``` Or use PgBouncer in front of PostgreSQL for high-traffic deployments. ## Deploy to a Fast Platform Django performance varies significantly by hosting: - **Railway or Render:** Easy deployment, decent performance, auto-scaling - **Fly.io:** Deploy close to your users globally - **DigitalOcean App Platform:** Managed, auto-scaling - **VPS (DigitalOcean, Linode):** Most control, most configuration required For database: use managed PostgreSQL (Supabase, RDS, DigitalOcean Managed Database) rather than running PostgreSQL on the same server as your app. ## Quick Checklist - [ ] Gunicorn or uWSGI in production (not `runserver`) - [ ] N+1 queries eliminated (`select_related`, `prefetch_related`) - [ ] Redis configured for caching - [ ] Expensive views or fragments cached - [ ] WhiteNoise installed and configured (or CDN for static files) - [ ] `collectstatic` run as part of deployment - [ ] JavaScript deferred or placed at end of body - [ ] Images converted to WebP and compressed - [ ] Width and height attributes on all images - [ ] Database connection pooling configured Django can be very fast -- Instagram, Pinterest, and Disqus all use or used Django at massive scale. But it requires configuration. The defaults are safe, not fast. [Test your Django site](/test) to see your current PageSpeed score and find out where the bottlenecks are. --- # Does Page Speed Affect SEO Rankings? Canonical source: https://thefastestweb.site/blog/does-page-speed-affect-seo Publisher: TheFastestWeb Author: TheFastestWeb Published: 2026-03-28T00:00:00.000Z Updated: 2026-09-20T00:00:00.000Z How Core Web Vitals relate to Google Search, why Lighthouse scores differ from field data, and how to prioritize performance improvements. Yes, website performance matters for SEO. Google says its ranking systems use Core Web Vitals, but good measurements do not guarantee a higher position. Search relevance and the wider page experience still matter. [Google's page experience guidance](https://developers.google.com/search/docs/appearance/page-experience) explains that relationship. ## Does a faster page always rank higher? No. Google can show highly relevant content even when its page experience needs improvement. Better page experience can help when several results are useful, but that is not a rule that the fastest page wins. Google's guidance does not provide a formula that converts milliseconds or a performance score into ranking positions. [Read how Google describes page experience in Search](https://developers.google.com/search/docs/appearance/page-experience). Our recommendation is to treat performance work as one part of improving a useful, accessible website. Do not promise a particular ranking increase from a speed change alone. ## Which measurements should you use? The current Core Web Vitals cover loading, responsiveness and visual stability: - **Largest Contentful Paint (LCP):** when the largest visible content appears. The good threshold is 2.5 seconds or less. - **Interaction to Next Paint (INP):** how quickly a page responds visually to interaction. The good threshold is 200 milliseconds or less. - **Cumulative Layout Shift (CLS):** unexpected movement of page content. The good threshold is 0.1 or less. Assess these targets at the 75th percentile, separately for mobile and desktop. When sufficient measurements are available, all three should meet their targets. This is a performance assessment, not a search ranking guarantee. [The Web Vitals guide](https://web.dev/articles/vitals) explains the metrics and thresholds. Google recommends using Search Console's Core Web Vitals report to understand how your pages perform and identify opportunities to improve them. [Core Web Vitals and Google Search](https://developers.google.com/search/docs/appearance/core-web-vitals) links the relevant measurement tools. ## Is a Lighthouse score the same as Core Web Vitals? No. PageSpeed Insights combines two different views: Lighthouse runs a controlled lab test, while the Chrome User Experience Report (CrUX) supplies historical measurements from real users. A 0–100 lab performance score does not certify that a page passes its field assessment. [About PageSpeed Insights](https://developers.google.com/speed/docs/insights/v5/about) describes both datasets. CrUX data in PageSpeed Insights covers a trailing 28-day period. Some URLs lack enough samples; the tool may show origin-level data instead, or no field data at all. Check which scope the report uses. Missing data does not establish either a pass or a failure. [PageSpeed Insights field-data documentation](https://developers.google.com/speed/docs/insights/v5/about#real-user-experience-data) explains these limits. Lab tests help investigate problems and compare changes under similar conditions. A standard Lighthouse navigation test reports Total Blocking Time (TBT); it does not measure field INP. Reducing blocking work can help responsiveness, but TBT and INP are different measurements. [Web Vitals: lab tools](https://web.dev/articles/vitals) explains this distinction. ## Does mobile-first indexing make desktop performance irrelevant? Mobile-first indexing describes Google's use of the mobile version of a site's content for indexing and ranking. It is not a statement that one mobile Lighthouse score represents every visitor or all desktop performance. Keep important content and metadata accessible on mobile, and inspect performance for both device groups. [Google's mobile-first indexing documentation](https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing) sets out the content requirements. ## What about engagement and crawl budget? Use your own engagement and conversion measurements to judge whether an optimization helped visitors. A change in bounce rate, scrolling or session duration does not by itself establish why a search position changed. We recommend treating those measurements as product evidence rather than converting them into promised ranking gains. Server performance can also affect crawling. Google adjusts crawl capacity in response to server health, response times and errors, while crawl demand is a separate consideration. Faster responses do not guarantee that more pages will be crawled or indexed. [Google's crawl-budget guidance](https://developers.google.com/crawling/docs/crawl-budget) explains both constraints. That guidance mainly concerns large or frequently changing sites and sites with substantial discovery/indexing issues. If your pages are already crawled promptly, Google recommends maintaining your sitemap and checking the Page Indexing report rather than treating crawl budget as the first problem to solve. [See who the crawl-budget guide is for](https://developers.google.com/crawling/docs/crawl-budget). ## How should you prioritize fixes? Start with the metric and page template causing a real problem. LCP deserves attention when content appears late; responsiveness and layout stability may need different work. Avoid assuming LCP always contributes the most to the overall lab score: Lighthouse uses a weighted combination of metrics, and its weights can change between versions. Use the diagnostics from the version that produced your report. [Chrome's performance-scoring documentation](https://developer.chrome.com/docs/lighthouse/performance/performance-scoring) explains the calculation. Our practical workflow is: 1. Review available field data and note whether it describes one URL, a group of pages or an entire origin. 2. Compare mobile and desktop separately. Identify affected templates and the people using them. 3. Run lab tests to diagnose those pages, keeping test conditions consistent when comparing changes. 4. Fix the observed bottleneck, then check that the change improves the intended measurement without introducing another problem. 5. Record deployment dates and inspect subsequent field results. A rolling historical dataset will not immediately contain only post-deployment visits. [Test your site's speed](/test) to inspect a lab result on TheFastestWeb. Compare its date and device with earlier runs, and use the field-data tools above to assess real-user Core Web Vitals. --- # How to Check Website Speed (Free Tools) Canonical source: https://thefastestweb.site/blog/how-to-check-website-speed Publisher: TheFastestWeb Author: TheFastestWeb Published: 2026-03-27T00:00:00.000Z A practical guide to the best free tools for checking website speed, what each one measures, and when to use which one. There are dozens of tools to check website speed, and each gives you slightly different data. Here's which ones to use and what they're actually telling you. ## The Tools That Matter ### 1. PageSpeed Insights (Google) **URL:** pagespeed.web.dev The standard reference for web performance. It runs Lighthouse (Google's performance engine) on your URL and gives you a 0-100 score based on six metrics. More importantly, it shows your real-world Core Web Vitals from actual Chrome users if your site has enough traffic. **Use it when:** You want the official score Google sees, or you want to understand what's affecting your rankings. **Limitation:** Single test result can vary by 10-15 points depending on server load. Run it 3 times and average the results. ### 2. TheFastestWeb **URL:** thefastestweb.site/test Runs PageSpeed Insights on your URL and presents the results clearly with metric-by-metric breakdowns. Also lets you monitor your score daily and get alerts if it drops. **Use it when:** You want to track your score over time and see how it compares to other sites. ### 3. WebPageTest **URL:** webpagetest.org The most detailed free performance tool available. Runs your page in a real browser (Chrome, Firefox) from a real location with a configurable connection speed. Shows a full waterfall of every request, how long each resource takes, and exactly what's blocking what. **Use it when:** You need to understand the root cause of a slow load, not just the score. If PageSpeed Insights tells you something is slow, WebPageTest tells you why. **Best feature:** Filmstrip view showing exactly what the page looked like at each moment during load. ### 4. GTmetrix **URL:** gtmetrix.com Combines Lighthouse and WebPageTest data in a cleaner interface. Free tier gives you 1 test location (Vancouver) with Chrome. Shows waterfall, video playback, and performance scores. **Use it when:** You want something more visual than PageSpeed Insights but less technical than WebPageTest. ### 5. Chrome DevTools (Lighthouse) **Built into Chrome:** F12 > Lighthouse tab Same Lighthouse engine as PageSpeed Insights but runs locally. Because it's running on your machine without network latency to Google's servers, it's faster but can give slightly different results. Useful for testing local development builds before deploying. **Use it when:** You're actively debugging and iterating on changes locally. **How to use:** Open DevTools (F12), go to the Lighthouse tab, select Mobile or Desktop, click "Analyze page load." ### 6. Google Search Console **URL:** search.google.com/search-console Not a speed testing tool, but the most important source of real-world Core Web Vitals data. The Core Web Vitals report shows how your pages are performing for actual users, grouped by Good/Needs Improvement/Poor. **Use it when:** You want to know what Google is actually seeing and using for rankings. **Limitation:** Only available if you've verified ownership of your site. ## Which Tool to Use for What | Goal | Tool | |---|---| | Check overall score | PageSpeed Insights | | Track score over time | TheFastestWeb | | Debug a specific issue | WebPageTest | | Test before deploying | Chrome DevTools | | See ranking impact | Google Search Console | ## Testing Best Practices **Test mobile first.** Google uses mobile Core Web Vitals for rankings. Desktop scores are almost always better and less relevant. **Run multiple tests.** A single PageSpeed run can vary significantly. Run at least 3 tests and take the average or middle value. **Test the right pages.** Your homepage might be well-optimized, but product pages, blog posts, or landing pages might not be. Test the pages that drive actual traffic and conversions. **Test from multiple locations.** WebPageTest lets you choose test locations. Users in Europe get a different experience than users in Singapore. If you have a global audience, test from multiple regions. **Test consistently.** Run tests at the same time of day if possible. A page that's cached by a CDN will test much faster at midday than at 3am when caches are cold. ## Understanding Score Variability PageSpeed scores can vary by 10-20 points between runs. This is normal and caused by: - Server response time variation - CDN cache state (cached vs. uncached) - Background network conditions during the test - Third-party script load times If you're seeing a sudden drop in score, run the test 3-5 times before reacting. If the average is consistently lower than before, then something changed. [Test your site now](/test) and get your current PageSpeed score in seconds. --- # How to Get a 100 PageSpeed Score Canonical source: https://thefastestweb.site/blog/how-to-get-100-pagespeed-score Publisher: TheFastestWeb Author: TheFastestWeb Published: 2026-03-21T00:00:00.000Z A perfect 100 PageSpeed score is achievable for most sites. Here's exactly what it takes and what the fastest sites on the web have in common. A 100 PageSpeed score means your site loads instantly, has no layout shifts, and blocks the main thread for almost zero time. It's achievable, but it requires discipline. On [TheFastestWeb leaderboard](/leaderboard/perfect), several sites consistently score 100. Here's what they have in common. ## What Goes Into a 100 Score Google PageSpeed Insights uses these metrics (with their weights): - **Total Blocking Time (TBT):** 30% - **Largest Contentful Paint (LCP):** 25% - **Cumulative Layout Shift (CLS):** 25% - **First Contentful Paint (FCP):** 10% - **Speed Index (SI):** 10% To hit 100, you need near-perfect scores across all five. The good news: fixing TBT and LCP alone gets you most of the way there. ## What Sites With a 100 Score Do Differently ### 1. Almost No JavaScript The biggest common trait among perfect-scoring sites is minimal JavaScript. No heavy frameworks, no bloated libraries, no third-party scripts loaded on page load. If you need JavaScript, ship as little as possible. Defer everything that isn't critical. Use vanilla JS where you can. ### 2. Optimized Images Every image is compressed, correctly sized, and served in WebP. The LCP image is preloaded. Nothing is lazy-loaded above the fold. ### 3. No Third-Party Scripts on Page Load Analytics, chat widgets, A/B testing tools, tag managers. These are TBT killers. Perfect-scoring sites either don't use them or load them only after the page is interactive. If you need analytics, consider lightweight alternatives like [Umami](https://umami.is/) or [Plausible](https://plausible.io/) instead of Google Analytics with GTM. ### 4. Inline Critical CSS Rather than loading a large CSS file that blocks rendering, they inline the CSS needed for above-the-fold content and defer the rest. ### 5. Fast Hosting A slow server response time (TTFB) puts a ceiling on your score no matter how optimized your assets are. Top-scoring sites use edge hosting (Vercel, Cloudflare Pages, Netlify Edge) with servers close to their users. ### 6. No Layout Shifts Every image has explicit width and height. Fonts use `font-display: swap`. No content is injected above existing content after load. ## Step-by-Step: How to Improve Your Score **Start with the bottleneck.** Run your site through [PageSpeed Insights](https://pagespeed.web.dev/) and look at which metric is lowest. Fix that first. **For TBT:** - Remove or defer all non-critical JavaScript - Audit your npm packages for bloat - Move third-party scripts to load after interaction **For LCP:** - Compress your hero image to WebP - Add `` or `priority` attribute to the LCP image - Improve server response time **For CLS:** - Add `width` and `height` to all `` tags - Use `font-display: swap` - Reserve space for ads and embeds **For FCP:** - Inline critical CSS - Reduce server response time - Eliminate render-blocking resources ## Realistic Targets by Site Type Not every site can hit 100. A complex SaaS dashboard with heavy interactivity will never score like a static landing page. Here's what's realistic: | Site Type | Realistic Target | |---|---| | Static landing page | 95-100 | | Marketing site | 85-95 | | Blog | 85-95 | | SaaS tool | 70-85 | | E-commerce | 60-80 | If you're in the right range for your site type, you're doing well. The goal isn't a perfect score, it's being faster than your competitors. ## Is a Perfect Score Worth It? For most sites, chasing 100 after you're already at 90+ has diminishing returns. The performance gains from 90 to 100 are real but small. What matters for rankings is being in the "Good" range (90+) consistently. That said, for marketing sites, landing pages, and content sites, getting to 95+ is absolutely worth the effort. Want to know your current score? [Test your site](/test) and see exactly where you stand. --- # Laravel PageSpeed Optimization Guide Canonical source: https://thefastestweb.site/blog/laravel-pagespeed-optimization-guide Publisher: TheFastestWeb Author: TheFastestWeb Published: 2026-03-24T00:00:00.000Z Laravel is a PHP framework that can power very fast websites when configured correctly. Here's how to optimize a Laravel app for high PageSpeed scores. Laravel is the most popular PHP framework and powers millions of websites. Like any server-rendered framework, its performance depends on how you configure it, what you cache, and how you deliver assets to users. Here's how to get your Laravel site scoring well on PageSpeed. ## The Foundation: Reduce Server Response Time (TTFB) Every metric on PageSpeed starts with TTFB. If your server takes 800ms to respond, that's 800ms before the browser even starts rendering. ### Enable Route Caching In production, cache your routes so Laravel doesn't parse route files on every request: ```bash php artisan route:cache php artisan config:cache php artisan view:cache ``` Run these as part of your deployment process. Remember to clear them when you make changes: ```bash php artisan optimize:clear ``` Or use the shortcut that runs all caches at once: ```bash php artisan optimize ``` ### Use a PHP Opcode Cache Make sure OPcache is enabled on your server. It caches compiled PHP bytecode so PHP doesn't need to compile your files on every request. It's enabled by default on most managed hosting but worth verifying: ```ini ; php.ini opcache.enable=1 opcache.memory_consumption=256 opcache.max_accelerated_files=20000 opcache.revalidate_freq=0 ``` ### Use Redis or Memcached for Cache File-based caching works but Redis is significantly faster. Use Redis for sessions, cache, and queues: ```env CACHE_DRIVER=redis SESSION_DRIVER=redis QUEUE_CONNECTION=redis ``` ```bash composer require predis/predis ``` ## Cache Your Database Queries Repeated database queries are a common cause of slow TTFB. Cache expensive queries: ```php $users = Cache::remember('users', 3600, function () { return User::with('posts')->where('active', true)->get(); }); ``` For public-facing pages where all users see the same content, cache the entire response using response caching: ```bash composer require spatie/laravel-responsecache ``` This caches the entire HTTP response, making repeat visits effectively instant. ## Optimize Your Frontend Assets ### Use Vite (Laravel 12+ Default) Laravel's default Vite integration handles asset bundling, minification, and cache-busting. Make sure you're running the production build: ```bash npm run build ``` The production build minifies JS and CSS, adds content hashes for caching, and tree-shakes unused code. ### Defer and Async JavaScript Make sure non-critical scripts don't block rendering: ```html ``` In Blade templates, put non-critical scripts at the end of `` or add `defer`. ### Inline Critical CSS For your above-the-fold CSS, inline it in the `` to avoid a render-blocking stylesheet request. Extract critical CSS from your main stylesheet and inline it directly in your layout: ```blade ``` ## Optimize Images ### Use Laravel's Storage with Image Processing For user-uploaded images, process them before storing to ensure they're web-optimized: ```bash composer require intervention/image ``` ```php use Intervention\Image\ImageManager; $manager = new ImageManager(['driver' => 'imagick']); $image = $manager->make($request->file('photo')) ->resize(800, null, function ($constraint) { $constraint->aspectRatio(); $constraint->upsize(); }) ->encode('webp', 85); ``` Store WebP versions alongside originals and serve WebP to browsers that support it. ### Add Width and Height to Image Tags Prevent layout shift by always specifying dimensions: ```blade Hero image ``` Use `loading="lazy"` for images below the fold, `loading="eager"` (or no attribute) for your LCP image. ## Use a CDN for Static Assets Serve CSS, JavaScript, images, and other static files from a CDN to reduce latency for global users. With Vite and Laravel: ```env ASSET_URL=https://your-cdn.example.com ``` Cloudflare's free plan works well for this -- it proxies your origin and caches static assets globally. ## Enable HTTP Compression Make sure your server sends compressed responses. For Nginx: ```nginx gzip on; gzip_types text/plain text/css application/json application/javascript text/xml; gzip_min_length 1000; # Or even better, use Brotli if available brotli on; brotli_types text/plain text/css application/json application/javascript; ``` For Apache: ```apache AddOutputFilterByType DEFLATE text/html text/css application/javascript application/json ``` ## Configure Long-term Caching for Assets Vite already adds content hashes to asset filenames. Configure your web server to cache these aggressively: ```nginx # Nginx location ~* \.(js|css|woff2|png|webp|jpg)$ { expires 1y; add_header Cache-Control "public, max-age=31536000, immutable"; } ``` ## Deploy on a Fast Server Laravel benefits significantly from good hosting: - **Managed Laravel hosting:** Laravel Forge on DigitalOcean or Linode, Ploi - **Platform hosting:** Laravel Vapor (serverless, auto-scaling), Railway, Render - **VPS with optimization:** Any VPS with PHP-FPM, Nginx, Redis, OPcache configured properly Shared hosting is the most common cause of poor TTFB on Laravel sites. If your server response time is over 600ms, hosting is likely the bottleneck. ## Quick Checklist - [ ] `php artisan optimize` run as part of deployment - [ ] OPcache enabled and configured - [ ] Redis used for cache, sessions, and queues - [ ] Database queries cached for public pages - [ ] Vite production build (`npm run build`) deployed - [ ] Non-critical JS deferred or placed before `` - [ ] Images compressed and served as WebP - [ ] Width and height set on all images - [ ] CDN configured for static assets - [ ] Gzip or Brotli compression enabled - [ ] Long-term cache headers set for versioned assets A well-configured Laravel application can comfortably score 85+ on PageSpeed. The biggest wins are usually server-side: faster TTFB through caching and good hosting makes every other metric better. [Test your Laravel site](/test) to see your current PageSpeed score and identify where to focus your optimization work. --- # Next.js Performance Optimization Guide Canonical source: https://thefastestweb.site/blog/nextjs-performance-optimization-guide Publisher: TheFastestWeb Author: TheFastestWeb Published: 2026-03-18T00:00:00.000Z Next.js gives you a great starting point for performance, but there's plenty that can go wrong. Here's how to get the most out of your Next.js site's PageSpeed score. Next.js is one of the fastest frameworks available out of the box. Server-side rendering, automatic code splitting, and built-in image optimization give you a solid foundation. But there's still plenty that can slow things down. Here's a practical guide to squeezing the best PageSpeed scores out of a Next.js site. ## Use the Image Component Correctly The `` component from `next/image` is one of the most impactful performance features in Next.js. It automatically serves WebP, resizes images for the requesting device, and lazy-loads below-the-fold images. But it only works well if you use it properly. **Always set `priority` on your LCP image:** ```tsx import Image from "next/image"; Hero ``` Without `priority`, Next.js lazy-loads the image, which will hurt your LCP score significantly. **Never use `fill` on above-the-fold images without a sized container.** The browser needs to know the dimensions upfront to avoid layout shifts. ## Load Scripts the Right Way The ` ``` Always `await` your data fetching in setup so it completes before the component renders. This prevents layout shifts from content appearing after hydration. ## Optimize Fonts Self-host your fonts instead of loading from Google Fonts. Use the `@nuxtjs/google-fonts` module if you want to keep using Google Fonts but serve them from your domain: ```bash npm install @nuxtjs/google-fonts ``` ```ts export default defineNuxtConfig({ modules: ["@nuxtjs/google-fonts"], googleFonts: { download: true, // downloads and self-hosts fonts families: { Inter: [400, 600, 800], }, display: "swap", preload: true, }, }); ``` ## Handle Third-Party Scripts Properly Use Nuxt's `useHead` or `useScript` (Nuxt 3.9+) to load third-party scripts without blocking the main thread: ```ts // For analytics and non-critical scripts useHead({ script: [ { src: "https://analytics.example.com/script.js", defer: true, }, ], }); ``` With `@nuxt/scripts` (experimental): ```ts const { load } = useScript("https://analytics.example.com/script.js", { trigger: "idle", // loads when browser is idle }); ``` ## Enable Compression and Caching In your Nitro server config, enable compression: ```ts export default defineNuxtConfig({ nitro: { compressPublicAssets: true, routeRules: { "/_nuxt/**": { headers: { "cache-control": "max-age=31536000, immutable" }, }, "/**": { headers: { "cache-control": "s-maxage=3600" }, }, }, }, }); ``` ## Deploy to the Edge Nuxt's Nitro server supports edge deployment on Cloudflare Workers, Vercel Edge, and similar platforms. Edge deployment dramatically reduces TTFB for global audiences. ```bash # Deploy to Cloudflare Pages NITRO_PRESET=cloudflare-pages nuxt build ``` ## Quick Checklist - [ ] Using SSG or SSR (not CSR) for public pages - [ ] `@nuxt/image` installed, using `` for all images - [ ] LCP image has `preload` attribute - [ ] Bundle analyzed, large unused imports removed - [ ] Heavy components use `` - [ ] Fonts self-hosted or via `@nuxtjs/google-fonts` with `download: true` - [ ] Third-party scripts use `defer` or load on idle - [ ] Deployed to edge (Cloudflare Pages, Vercel Edge) Nuxt sites can comfortably score 90+ with the right configuration. The biggest wins come from choosing the right rendering mode, optimizing images, and managing your JavaScript bundle. [Test your Nuxt site](/test) to see your current PageSpeed score and find out what's affecting each metric. --- # Shopify PageSpeed Optimization Guide Canonical source: https://thefastestweb.site/blog/shopify-pagespeed-optimization-guide Publisher: TheFastestWeb Author: TheFastestWeb Published: 2026-03-15T00:00:00.000Z Shopify stores often struggle with PageSpeed scores because of heavy themes and app scripts. Here's how to fix it and get your store loading faster. Shopify stores have a unique set of performance challenges. Between theme bloat, app scripts, and large product images, it's common to see scores in the 30-50 range. But with the right approach, most Shopify stores can reach 70-85, and lean stores can hit 90+. Here's how to do it. ## Why Shopify Stores Are Often Slow Shopify's infrastructure is solid. The CDN is fast, SSL is included, and server response times are generally good. The slowness almost always comes from: - **Heavy themes** loaded with unused features - **App scripts** from every installed Shopify app loading on every page - **Large product images** without proper compression - **Third-party tracking scripts** from marketing tools - **Liquid rendering overhead** for complex templates ## Step 1: Switch to a Fast Theme The Dawn theme (Shopify's free default theme) is one of the fastest available. It's built on performance-first principles and scores well out of the box. If you're on a third-party theme, check its PageSpeed score on a demo store before committing. Many premium themes score in the 30-50 range on mobile. Fast theme options: - **Dawn** (free, Shopify default) - best baseline performance - **Sense** (free) - clean, fast - **Craft** (free) - minimal, good for brand stores - **Streamline** (paid) - fast, feature-rich If you're locked into a heavy theme for design reasons, focus on the other optimizations below. ## Step 2: Audit Your Shopify Apps Every Shopify app you install can inject scripts into every page of your store, even pages where the app isn't active. This is the single biggest cause of slow Shopify stores. **How to audit:** 1. Open Chrome DevTools > Network tab 2. Load your homepage 3. Filter by JS and look for scripts from domains you don't recognize 4. Match them back to your installed apps For each app, ask: - Do I actually use this? - Is the revenue/value worth the performance cost? - Is there a lighter alternative? Common heavy apps and their impact: - Review apps (Yotpo, Okendo) add 50-150KB of JavaScript - Live chat (Gorgias, Tidio) block the main thread for 100-300ms - Loyalty apps (Smile.io) add significant script overhead - A/B testing apps are TBT killers Uninstall apps you don't actively use. Deleted apps sometimes leave script tags behind, so check your theme's `theme.liquid` file for orphaned scripts after uninstalling. ## Step 3: Optimize Product Images Product images are usually the biggest contributor to slow LCP on Shopify stores. **Best practices:** - Upload images at 2048x2048 maximum (Shopify's recommendation) - Compress before uploading with [TinyPNG](https://tinypng.com/) or Squoosh - Shopify automatically serves WebP to browsers that support it - Use square images for product listings (consistent aspect ratio prevents layout shifts) **For collection pages:** Shopify loads all product images on the page. If you have 50 products with large images, this adds up. Make sure lazy loading is enabled in your theme for collection grids. ## Step 4: Defer App Scripts For apps you can't remove, you can often reduce their performance impact by loading them after the page is interactive. In your theme's `theme.liquid`, find app script tags that look like: ```html ``` Add `defer` to defer their execution: ```html ``` Note: This can break some apps that expect to run synchronously. Test carefully. ## Step 5: Use Shopify's Built-In Performance Tools Shopify has added performance tooling directly in the admin: **Online Store > Themes > Performance** shows your theme's speed score and specific recommendations. **Shopify Speed Score** in the admin is based on a sample of real page loads, not just a single PageSpeed test. Use it as a baseline but also run tests with [our tool](/test) for more detail. ## Step 6: Optimize Your Largest Contentful Paint On most Shopify stores, the LCP element is either the hero image on the homepage or the main product image on product pages. **For the hero image:** - Compress it aggressively (under 150KB) - Make sure it's not lazy-loaded (check your theme's `index.liquid`) - Add preload if possible in your theme's `` **For product pages:** - The main product image is usually the LCP - Upload product images pre-compressed - Ensure your theme doesn't lazy-load the first product image ## Step 7: Enable Lazy Loading for Below-Fold Images Most modern Shopify themes enable lazy loading by default. If yours doesn't, add `loading="lazy"` to images in collection grids, related products, and other below-fold content in your theme code. ## Realistic Score Targets for Shopify | Setup | Realistic Score | |---|---| | Dawn theme, minimal apps, optimized images | 80-90 | | Fast theme, 5-8 apps | 65-80 | | Heavy theme, many apps | 30-55 | | Large collection pages | 50-70 | Mobile scores are typically 15-25 points lower than desktop on Shopify. Focus your optimization efforts on mobile. ## Quick Checklist - [ ] Fast theme (Dawn or equivalent) - [ ] Apps audited, unused apps uninstalled - [ ] Product images compressed before upload (under 200KB) - [ ] Hero image not lazy-loaded - [ ] App scripts deferred where possible - [ ] No orphaned scripts from deleted apps in theme.liquid - [ ] Collection page images lazy-loaded Shopify performance is more constrained than other platforms because you're working within the platform's limits. But app management and image optimization alone can move the needle by 20-30 points for most stores. [Test your Shopify store](/test) to see your current PageSpeed score on both mobile and desktop. --- # Shopify vs WooCommerce: Which Is Faster? Canonical source: https://thefastestweb.site/blog/shopify-vs-woocommerce-speed Publisher: TheFastestWeb Author: TheFastestWeb Published: 2026-03-19T00:00:00.000Z Shopify and WooCommerce power most of e-commerce, but they take different approaches that directly affect performance. Here's how they compare on real-world speed. Shopify and WooCommerce are the two most popular e-commerce platforms. Speed matters a lot for online stores -- Amazon famously found that every 100ms of latency costs 1% in sales. Here's how the two platforms compare on performance. ## The Short Answer **Shopify is faster by default.** Its infrastructure handles caching and CDN automatically. WooCommerce (built on WordPress) is slower out of the box but can be optimized to similar levels with the right setup. ## How Each Platform Handles Performance ### Shopify Shopify is a fully hosted SaaS platform. You pick a theme, add products, and Shopify handles the server infrastructure globally. Key performance advantages: - **Built-in CDN** (Fastly) for all assets including images, CSS, and JS - **Automatic image compression** and WebP serving - **99.99% uptime SLA** with servers optimized for e-commerce traffic - **No server management** required The limitation: you're working within Shopify's infrastructure. You can't change the server setup, and themes can add bloat you can't fully control. ### WooCommerce WooCommerce is a WordPress plugin. You're responsible for: - Choosing and managing your hosting - Setting up caching (WP Rocket, LiteSpeed Cache) - Configuring a CDN (Cloudflare or hosting provider's CDN) - Optimizing images - Managing server performance More control, more responsibility. ## Real-World PageSpeed Scores | Setup | Mobile Score | Desktop Score | |---|---|---| | Shopify (default theme, no optimization) | 50-65 | 65-80 | | Shopify (optimized, fast theme like Dawn) | 65-80 | 75-90 | | Shopify (app-heavy store) | 30-50 | 45-65 | | WooCommerce (default, shared hosting) | 30-50 | 45-65 | | WooCommerce (optimized, managed hosting) | 60-80 | 75-90 | Both platforms suffer on mobile due to the inherent complexity of e-commerce pages (multiple product images, pricing, inventory, reviews, add-to-cart buttons). ## What Hurts Shopify Speed **Installed apps.** This is the biggest factor. Every Shopify app injects JavaScript into your storefront. A store with 10-15 apps (loyalty, reviews, upsells, chat, email capture) can easily add 500KB+ of JavaScript that loads before your page becomes interactive. Review every app and remove ones that aren't actively contributing to revenue. **Theme complexity.** Heavy, feature-rich themes load more CSS and JS by default. Shopify's own Dawn theme is one of the fastest. Third-party themes with sliders, mega menus, and built-in animations are slower. **Large product images.** Product photography is often high-resolution. Even with Shopify's CDN, unoptimized source images hurt LCP on product pages. ## What Hurts WooCommerce Speed **Hosting.** WooCommerce on shared hosting is slow. Managed WordPress hosts with WooCommerce optimization (WP Engine Commerce, Kinsta, SiteGround's WooCommerce plans) make a dramatic difference. **Plugin accumulation.** WooCommerce itself is relatively lean, but each extension (payment gateway, shipping calculator, product customizer, affiliate plugin) adds overhead. **WordPress overhead.** Every WooCommerce page runs PHP, hits the database, and assembles the page server-side unless caching is configured. Caching product pages is complex because cart and pricing data can be user-specific. **No built-in CDN.** You need to set up Cloudflare or a hosting CDN separately. ## Making Shopify Faster 1. **Audit your apps.** Remove any app that isn't directly tied to revenue. Even inactive apps can leave JavaScript on your storefront. 2. **Use a fast theme.** Dawn, Craft, or Sense from Shopify's library. Check theme speed scores before buying third-party themes. 3. **Use Shopify's native image formats.** Shopify serves WebP automatically when supported. 4. **Lazy load offscreen images.** Most modern themes do this, but verify. 5. **Avoid excessive upsell scripts.** One post-purchase upsell tool is fine. Three is too many. ## Making WooCommerce Faster 1. **Use managed WooCommerce hosting.** The hosting choice is the single biggest variable. 2. **Install WP Rocket or LiteSpeed Cache.** Caching is non-negotiable for acceptable performance. 3. **Use Cloudflare.** Free plan provides meaningful CDN acceleration. 4. **Use Smush or Imagify** to auto-compress product images. 5. **Use a lean theme.** Storefront (WooCommerce's official theme), GeneratePress, or Blocksy. ## Which Should You Choose? **Choose Shopify if:** - You want to start selling quickly without managing infrastructure - You're okay with per-transaction fees and app subscription costs - You want reliable uptime without technical overhead - Your store doesn't need deep WordPress/WooCommerce integrations **Choose WooCommerce if:** - You're already on WordPress and want to add a store - You need specific WooCommerce extensions that don't exist in Shopify - You want full data ownership and no platform transaction fees - You have a developer who can manage optimization Performance-wise, a well-optimized WooCommerce store can match or beat Shopify. But Shopify's floor is higher -- a default Shopify store with a clean theme is faster than a default WooCommerce install. [Test your store's speed](/test) to see where you stand and what's affecting your PageSpeed score. --- # Squarespace PageSpeed Optimization Guide Canonical source: https://thefastestweb.site/blog/squarespace-pagespeed-optimization-guide Publisher: TheFastestWeb Author: TheFastestWeb Published: 2026-03-23T00:00:00.000Z Squarespace controls most of its own infrastructure, but there are still practical steps you can take to improve your PageSpeed score. Here's what works. Squarespace is a fully hosted website builder like Wix, but with a stronger emphasis on design quality. Because Squarespace controls the platform, your optimization options are limited compared to self-hosted solutions -- but there are still meaningful improvements you can make. ## Understanding Squarespace's Performance Baseline Squarespace uses Fastly as its CDN and delivers assets globally. The infrastructure is solid. The issue is that Squarespace templates load substantial amounts of JavaScript and CSS to support their design system, animations, and e-commerce features -- regardless of whether you use all those features on a given page. Typical Squarespace mobile scores range from 50-75. Getting above 75 requires deliberate optimization. ## What You Can Control ### 1. Optimize Images (Your Biggest Lever) Squarespace automatically converts uploaded images to WebP and serves them responsively. But it can only work with what you provide. - **Compress before uploading.** Squarespace's compression is good but not perfect. Running your images through Squoosh or TinyPNG first helps. - **Keep images under 500KB before uploading.** Smaller source images result in smaller output. - **For banners and hero images:** Aim for under 300KB after compression. Hero images are almost always your LCP element. - **Use the Image Block settings.** In the block editor, set explicit aspect ratios and focal points to prevent unexpected cropping that loads excess image area. ### 2. Minimize Custom Code Injection Squarespace allows code injection through Settings > Advanced > Code Injection. Every script you add here loads on every page. - Remove any scripts you're no longer using - Move third-party scripts from the `` injection to the footer injection (runs after page load) - If you have Google Analytics, use Squarespace's built-in Google Analytics integration instead of manually injecting the GA script -- the built-in version is deferred automatically ### 3. Reduce Third-Party Integrations Each connected service (chat, scheduling, reviews) adds JavaScript. Squarespace's own integrations (like Acuity Scheduling) are somewhat optimized, but third-party embeds are not. If a widget doesn't directly generate leads or revenue, consider removing it. ### 4. Limit Animations and Effects Squarespace's scroll animations and entrance effects look polished but add JavaScript overhead. In **Design > Site Styles**, you can often disable: - Scroll effects (parallax) - Entrance animations - Page transitions Disabling these is one of the most impactful changes you can make to TBT on Squarespace. ### 5. Streamline Your Pages Long pages with many section types load more assets. A page with a gallery, a blog feed, a map, and an e-commerce listing block loads JavaScript for all of those features. For your most important pages (homepage, landing pages), keep the structure focused. Every feature block you add has a JavaScript cost. ### 6. Use Fewer Fonts Squarespace lets you use Google Fonts and Typekit. Each font family at each weight is a separate network request. Limit your site to 2 font families, each at 2-3 weights maximum. In **Design > Fonts**, set fewer font pairings and reduce the number of active weights. ## What You Can't Control on Squarespace - The JavaScript and CSS that Squarespace's templates load by default - Server response time and infrastructure decisions - Font loading strategy (`font-display` is controlled by Squarespace) - Core template rendering pipeline - HTTP headers and caching policies This is the fundamental trade-off of fully hosted platforms: ease of use in exchange for performance control. ## Realistic Score Expectations | Page Type | Expected Mobile Score | |---|---| | Simple landing page (minimal blocks) | 60-75 | | Homepage with gallery | 50-65 | | Blog post | 60-78 | | E-commerce product page | 45-62 | | Page with scheduling/booking | 45-60 | Above 80 on mobile is achievable but requires a very minimal page with few integrations. ## Squarespace vs Competitors on Speed Squarespace and Wix are comparable in terms of what you can achieve. Both are slower than: - Self-hosted frameworks (Next.js, Nuxt, Astro, SvelteKit) - WordPress with aggressive optimization - Webflow (which gives you more control over the code output) But they're easier to manage without a developer. ## When to Consider Migrating If PageSpeed is consistently hurting your Google rankings or your conversion rate, and you've hit the ceiling of what Squarespace allows, consider: - **Webflow:** More performance control, similar visual design approach - **WordPress:** Full control, requires more technical management - **Astro or SvelteKit:** Developer-focused, very fast out of the box For most Squarespace users -- small businesses, portfolios, restaurants, service providers -- the performance trade-off is acceptable. A score of 65-72 on mobile is not ideal, but it's not disqualifying either. ## Quick Checklist - [ ] Images compressed before upload (under 500KB) - [ ] Hero/banner images under 300KB - [ ] Scroll effects and entrance animations disabled - [ ] Code injection audited and cleaned up - [ ] Analytics using Squarespace's native integration (not manual script) - [ ] Unused integrations removed - [ ] Fonts limited to 2 families, 2-3 weights each - [ ] Pages use only necessary section blocks [Test your Squarespace site](/test) to see your current PageSpeed score and identify which metrics need the most attention. --- # SvelteKit PageSpeed Optimization Guide Canonical source: https://thefastestweb.site/blog/sveltekit-pagespeed-optimization-guide Publisher: TheFastestWeb Author: TheFastestWeb Published: 2026-03-21T00:00:00.000Z SvelteKit ships less JavaScript than any other major framework. Here's how to configure it for top PageSpeed scores and avoid the common pitfalls. SvelteKit has a significant performance advantage over React and Vue-based frameworks: it compiles components to minimal JavaScript at build time instead of shipping a runtime. The result is smaller bundles and faster pages by default. Here's how to configure SvelteKit for maximum performance and score in the 90s on PageSpeed. ## Choose the Right Rendering Mode SvelteKit supports multiple rendering strategies through adapters and page options. **Static Pre-rendering** is the fastest option. Pages are generated at build time and served from a CDN with no server involved: ```js // src/routes/+page.js export const prerender = true; ``` Or pre-render your entire site by default in `svelte.config.js`: ```js const config = { kit: { prerender: { default: true, }, }, }; ``` **Server-Side Rendering (SSR)** is the default. Pages render on the server per request. Use this for dynamic, user-specific content. **CSR-only** should be avoided for public pages. If a route doesn't need to be indexed or seen before JavaScript loads, you can disable SSR: ```js export const ssr = false; ``` For most sites, pre-render everything that can be pre-rendered, and use SSR only for truly dynamic routes. ## Optimize Images SvelteKit doesn't have a built-in image optimization component, but `@sveltejs/enhanced-img` provides automatic WebP conversion and responsive images: ```bash npm install --save-dev @sveltejs/enhanced-img ``` ```js // vite.config.js import { sveltekit } from "@sveltejs/kit/vite"; import { enhancedImages } from "@sveltejs/enhanced-img"; export default { plugins: [enhancedImages(), sveltekit()], }; ``` ```svelte ``` This generates `srcset` with WebP versions automatically. For your LCP image, make sure it's not lazy-loaded: ```svelte ``` ## Minimize JavaScript Bundle Size SvelteKit's output is already lean, but there are ways to keep it lean as your app grows. **Lazy load heavy components:** ```svelte {#if HeavyChart} {/if} ``` **Use SvelteKit's code splitting.** By default, each route gets its own bundle. Don't import everything at the top level of your layout. **Analyze your bundle:** ```bash VITE_BUILD_ANALYZE=true vite build ``` Or use rollup-plugin-visualizer to see what's in your bundle. ## Optimize Fonts Load fonts from your own domain to eliminate the external DNS lookup: ```css @font-face { font-family: "Inter"; src: url("/fonts/inter-400.woff2") format("woff2"); font-display: swap; font-weight: 400; } ``` Preload your primary font in `app.html`: ```html ``` The `crossorigin` attribute is required even for same-origin fonts when using preload. ## Handle Third-Party Scripts Third-party scripts are the most common cause of high TBT on otherwise fast SvelteKit sites. Load analytics and non-critical scripts after the page is interactive: ```svelte ``` Or use a `window.requestIdleCallback` wrapper: ```js window.requestIdleCallback(() => { // Load low-priority scripts when browser is idle loadAnalytics(); }); ``` ## Configure Caching Headers SvelteKit's static adapter serves assets with correct cache headers by default. For custom SSR deployments, configure your server: For Node.js adapter: ```js // server.js app.use("/_app/immutable", (req, res, next) => { res.setHeader("cache-control", "public, max-age=31536000, immutable"); next(); }); ``` SvelteKit's versioned static assets (in `/_app/immutable/`) can be cached forever since filenames change with each build. ## Deploy to a CDN or Edge Pre-rendered SvelteKit sites should be deployed to a CDN: ```bash # Vercel npm install @sveltejs/adapter-vercel # Cloudflare Pages npm install @sveltejs/adapter-cloudflare ``` For SSR on Cloudflare Workers: ```js // svelte.config.js import adapter from "@sveltejs/adapter-cloudflare"; export default { kit: { adapter: adapter() }, }; ``` Edge deployment reduces TTFB for global users and directly improves FCP and LCP. ## Why SvelteKit Scores High The fundamental advantage of Svelte is that it shifts work from runtime to compile time. A React component ships React, ReactDOM, and the component code. A Svelte component ships only the compiled output -- no framework runtime at all. This means: - Smaller initial JS payload - Less parsing and execution time - Lower TBT (Total Blocking Time) - Faster TTI (Time to Interactive) On a simple marketing site, SvelteKit can produce JavaScript bundles 50-70% smaller than equivalent React apps. ## Quick Checklist - [ ] Pre-rendering enabled for all static pages - [ ] `@sveltejs/enhanced-img` installed and used for all images - [ ] LCP image has `loading="eager"` and `fetchpriority="high"` - [ ] Fonts self-hosted with `font-display: swap` - [ ] Font preload link in `app.html` - [ ] Heavy components lazy-loaded - [ ] Third-party scripts deferred or loaded on idle - [ ] Deployed to CDN or edge platform - [ ] Bundle analyzed for unexpected large dependencies SvelteKit is one of the easiest frameworks to achieve 90+ PageSpeed scores. The default output is clean and the tooling handles most optimizations automatically. [Test your SvelteKit site](/test) to see your current score and find any remaining bottlenecks. --- # Webflow PageSpeed Optimization Guide Canonical source: https://thefastestweb.site/blog/webflow-pagespeed-optimization-guide Publisher: TheFastestWeb Author: TheFastestWeb Published: 2026-03-16T00:00:00.000Z Webflow generates clean code but there are still several things that can drag your PageSpeed score down. Here's how to optimize a Webflow site for speed. Webflow generates cleaner HTML and CSS than most page builders, which gives you a head start on performance. But there are still several common issues that drag scores down, especially around images, fonts, and third-party scripts. Here's how to get the most out of your Webflow site's PageSpeed score. ## What Webflow Does Well Before getting into fixes, it's worth knowing what Webflow handles for you: - **Clean, minimal HTML** with no unnecessary wrapper divs - **Automatic CSS minification** on publish - **Built-in lazy loading** for images below the fold - **Global CDN** via Fastly for all hosted sites - **Automatic WebP conversion** for images uploaded through the asset manager These give Webflow sites a solid baseline. Most Webflow sites score in the 70-85 range without any optimization. With deliberate effort, 90+ is achievable. ## The Biggest Performance Issues in Webflow ### 1. Large, Uncompressed Images Even with automatic WebP conversion, Webflow serves whatever resolution image you upload. If you upload a 4000x3000 photo for a 600px thumbnail, you're serving a massive file. **Fix:** Resize images before uploading. Match the image dimensions to their largest displayed size. For a hero image that displays at 1400px wide, upload at 1400px wide, not 4000px. Use [Squoosh](https://squoosh.app/) or [TinyPNG](https://tinypng.com/) to compress before uploading. Target under 100KB for hero images, under 30KB for thumbnails. ### 2. The LCP Image Not Being Prioritized Webflow lazy-loads images by default, which is good for most images. But your hero image (the LCP element) should load immediately, not lazily. **Fix:** Select your hero image in the Webflow designer, open the element settings, and uncheck "Lazy load." This removes the `loading="lazy"` attribute from your LCP image. ### 3. Google Fonts Adding Request Overhead Webflow's font picker defaults to Google Fonts, which adds an external request and can delay text rendering. **Fix:** Upload fonts directly to Webflow using custom fonts. Download your Google Font files (WOFF2 format), upload them in Project Settings > Fonts, and use `font-display: swap` in your custom code. Alternatively, use system fonts for body text. They load instantly with zero external requests. ### 4. Third-Party Scripts This is the most common cause of poor TBT scores in Webflow sites. Analytics, chat widgets, heat map tools, and marketing automation scripts all run on the main thread. **Fix:** Add scripts through Project Settings > Custom Code > Footer Code rather than the head. Scripts in the footer load after the page content, reducing their impact on your scores. For Google Analytics, consider switching to [Umami](https://umami.is/) or [Plausible](https://plausible.io/). They're under 2KB and have near-zero performance impact. ### 5. Too Many Interactions and Animations Webflow's interactions and animations feature is powerful but can add significant JavaScript weight. Complex scroll-triggered animations across many elements create long tasks that drive up TBT. **Fix:** Audit your interactions. Remove animations that aren't adding clear value. Use CSS transitions instead of Webflow interactions where possible, as CSS animations run off the main thread. ### 6. Custom Code Bloat Many Webflow users add jQuery plugins, sliders, and other libraries through the custom code section without realizing the performance impact. **Fix:** Audit your custom code sections (both page-level and site-level). Remove libraries you no longer use. Replace jQuery-dependent features with vanilla JavaScript alternatives. ## Webflow-Specific Settings to Check **In Project Settings > SEO:** - Enable automatic sitemap generation - Make sure your canonical URL is set correctly **In Project Settings > General:** - Enable SSL (affects TTFB and security) **In the Designer for each image:** - Set meaningful alt text (accessibility + SEO) - Uncheck lazy load for hero/LCP images - Set explicit dimensions when possible ## Using Webflow with a Custom Domain and CDN Webflow's built-in CDN via Fastly is good, but you can add Cloudflare in front for additional caching and performance: 1. Point your domain to Cloudflare (change nameservers) 2. Set Cloudflare to proxy your Webflow site 3. Enable Cloudflare's caching rules for static assets 4. Turn on Auto Minify for HTML, CSS, and JavaScript This typically reduces TTFB by 50-150ms and improves scores by 3-8 points. ## Realistic Score Targets for Webflow | Setup | Realistic Score | |---|---| | Optimized images, minimal scripts | 85-95 | | Default settings, good images | 70-80 | | Heavy animations + third-party scripts | 50-70 | | E-commerce with many products | 60-75 | ## Quick Checklist - [ ] Images resized and compressed before uploading (under 100KB for hero) - [ ] Hero/LCP image has lazy load unchecked - [ ] Google Fonts replaced with self-hosted or system fonts - [ ] Third-party scripts moved to footer - [ ] Unnecessary Webflow interactions removed - [ ] Custom code audited for unused libraries - [ ] Cloudflare added in front for extra caching Webflow is one of the easier platforms to optimize because you're working with clean, predictable output. The biggest wins almost always come from image optimization and script management. [Test your Webflow site](/test) to see your current score and identify the specific issues holding you back. --- # What Are Core Web Vitals? (Explained Simply) Canonical source: https://thefastestweb.site/blog/what-are-core-web-vitals Publisher: TheFastestWeb Author: TheFastestWeb Published: 2026-03-29T00:00:00.000Z Core Web Vitals are three metrics Google uses to measure real-world user experience. Here's what they are, why they matter, and what scores you should aim for. Core Web Vitals are three performance metrics that Google defined as the most important signals of a good web user experience. They're used as a ranking factor in Google Search and are the foundation of what Google calls the "Page Experience" signal. They measure three things: loading performance, interactivity, and visual stability. ## The Three Core Web Vitals ### Largest Contentful Paint (LCP) — Loading LCP measures when the largest piece of visible content on the page finishes loading. This is usually a hero image, a large heading, or a video poster. **Good:** Under 2.5 seconds **Needs improvement:** 2.5s to 4s **Poor:** Over 4 seconds LCP is the most important of the three. It's the moment the page feels "loaded" to the user. ### Cumulative Layout Shift (CLS) — Visual Stability CLS measures how much content unexpectedly moves around while the page loads. If an image loads and pushes the text down, or a banner appears and shifts everything, that's layout shift. CLS is a unitless score (not time-based). **Good:** Under 0.1 **Needs improvement:** 0.1 to 0.25 **Poor:** Over 0.25 A CLS of 0 means nothing moved. Higher is worse. ### Interaction to Next Paint (INP) — Interactivity INP measures how quickly your page responds to user interactions (clicks, taps, keyboard input). It replaced First Input Delay (FID) as an official Core Web Vital in March 2024. **Good:** Under 200ms **Needs improvement:** 200ms to 500ms **Poor:** Over 500ms INP captures the worst-case interaction delay across the entire page session, not just the first input. ## Why Core Web Vitals Matter ### They're a Google Ranking Factor Google uses Core Web Vitals as part of the Page Experience signal. Sites that consistently pass all three have a measurable ranking advantage over those that don't — especially when competing for the same keywords with similar content quality. This doesn't mean a site with perfect Core Web Vitals will outrank a site with better content. But between two pages with similar relevance, the one with better performance wins. ### They Measure Real User Experience Core Web Vitals are designed to capture what users actually feel, not synthetic lab conditions. Google collects field data from real Chrome users through the Chrome User Experience Report (CrUX) and uses those real-world numbers for rankings. If your PageSpeed score is high but real users are experiencing slow loads (due to geography, device fragmentation, or caching issues), your CrUX data will reflect that. ### They Affect Conversion Rates Slower LCP means users leave before the page loads. CLS causes accidental clicks and frustration. High INP means buttons feel broken. Every Core Web Vital has a direct line to user behavior and business outcomes. Google's own research shows that pages meeting Core Web Vitals thresholds have significantly lower bounce rates. ## Core Web Vitals vs PageSpeed Score These are related but not the same thing. **PageSpeed score (0-100):** A composite score from Lighthouse that includes Core Web Vitals and other lab metrics like Total Blocking Time (TBT), First Contentful Paint (FCP), and Speed Index. This is the number you see in PageSpeed Insights. **Core Web Vitals (field data):** The real-world measurements of LCP, CLS, and INP from actual users. These are what Google uses for rankings. You need enough traffic for Google to collect this data (a minimum sample size). You can have a high PageSpeed score but still fail Core Web Vitals if real-world conditions (mobile devices, slow connections, geographic latency) are worse than the lab simulation. ## How to Check Your Core Web Vitals **PageSpeed Insights:** Run a test on any URL to see both lab data (PageSpeed score) and field data (Core Web Vitals from CrUX). **Google Search Console:** The Core Web Vitals report shows field data across all your pages grouped by Good/Needs Improvement/Poor. This is the most useful view for site-wide health. **Chrome DevTools:** The Performance panel shows LCP, CLS, and INP in real-time during your own browsing session. **[TheFastestWeb](/test):** Runs PageSpeed Insights on your URL and shows all metrics clearly. Good for tracking over time. ## What to Fix First If you're failing Core Web Vitals: 1. **LCP over 2.5s:** Start here. Optimize your hero image (compress, use WebP, preload), reduce server response time (CDN), eliminate render-blocking resources. 2. **CLS over 0.1:** Add explicit width and height to all images and videos. Reserve space for ads and embeds. Avoid injecting content above existing content. 3. **INP over 200ms:** Break up long JavaScript tasks. Reduce third-party script impact. Defer non-critical work. TBT (Total Blocking Time) from the lab score is a reliable proxy for INP. If your TBT is under 200ms, your INP is likely fine. ## The Passing Threshold Google considers a page to have "good" Core Web Vitals when at least 75% of real user visits meet the Good threshold for all three metrics. The 75th percentile matters — not the average or median. This means you need most of your users, on most devices, in most locations, to have a good experience. [Test your site now](/test) to see your Core Web Vitals alongside your full PageSpeed score. --- # What Is a Good PageSpeed Score? Canonical source: https://thefastestweb.site/blog/what-is-a-good-pagespeed-score Publisher: TheFastestWeb Author: TheFastestWeb Published: 2026-03-26T00:00:00.000Z A score of 90+ is good, but context matters. Here's what PageSpeed scores actually mean, what's realistic for different site types, and what to aim for. Google's PageSpeed Insights scores your site from 0 to 100. A score of 90 or above is "Good." But what score should you actually be targeting for your type of site? ## The Official Thresholds Google defines three categories: - **90-100:** Good - **50-89:** Needs Improvement - **0-49:** Poor These apply to both mobile and desktop scores. But the thresholds are the same regardless of whether you're running a simple blog or a complex SaaS dashboard with real-time data. ## Realistic Targets by Site Type Not all sites can hit 90+, and that's okay. Here's what to expect: ### Static Landing Pages and Blogs **Target: 90-100 mobile, 95-100 desktop** These should be easy. If your landing page or blog is scoring under 85, something is wrong -- likely oversized images, a page builder loading unnecessary CSS, or third-party scripts. ### Marketing Websites (SSR or SSG) **Target: 85-95 mobile, 90-100 desktop** Sites built on Next.js, Nuxt, Astro, or similar frameworks with server-side rendering should consistently hit the 90s. If you're below 80, check for unoptimized images, blocking JavaScript, or too many third-party tools (chat, video, analytics). ### Shopify and E-commerce **Target: 65-85 mobile, 75-90 desktop** E-commerce sites are harder to optimize. Product pages load many images, often have review widgets and live inventory checks, and Shopify's platform adds some baseline overhead. A score in the 70s is respectable for a Shopify store. Above 80 is excellent. ### WordPress Sites **Target: 70-90 mobile, 80-95 desktop** Highly variable. A well-built WordPress site with a fast theme and minimal plugins can hit 90+. A site with a page builder like Elementor and 20 plugins will often score in the 50s-60s. Improving a WordPress score is often more about removing things than adding them. ### SaaS Applications and Dashboards **Target: 60-80 mobile, 70-90 desktop** Authenticated apps with real-time data, complex UI components, and many interactive elements are inherently heavier. A score in the 70s is good for a SaaS product. Focus on getting public pages (marketing, landing, pricing) into the 90s and accept that the app itself will be lower. ### News and Content Sites **Target: 50-70 mobile, 65-85 desktop** High-traffic news sites often score in the 50s-60s due to aggressive ad loading, multiple analytics scripts, comment systems, and related content widgets. Improving scores here requires removing or deferring many third-party tools, which is often a business tradeoff. ## Mobile vs Desktop Desktop scores are almost always higher because the test simulates a faster device and connection. The gap is typically 10-25 points. **Mobile scores are what matter for SEO.** Google uses mobile Core Web Vitals for rankings. If you have to choose where to focus, optimize for mobile. ## The Score Is Not the Goal -- The Metrics Are A score of 95 doesn't mean your site is fast. It means the metrics Lighthouse measures are within good ranges. The score is a weighted composite: - **Total Blocking Time (TBT):** 30% - **Largest Contentful Paint (LCP):** 25% - **Cumulative Layout Shift (CLS):** 25% - **First Contentful Paint (FCP):** 10% - **Speed Index:** 10% A site can score 90 with a mediocre LCP if its TBT and CLS are perfect. What Google actually uses for rankings is Core Web Vitals field data (LCP, CLS, INP from real users), not the lab score. Focus on passing the Core Web Vitals thresholds: - LCP under 2.5s - CLS under 0.1 - INP under 200ms If those pass, your score will usually follow. ## When to Stop Optimizing Getting from 50 to 70 is relatively easy. Going from 80 to 90 takes focused effort. Going from 90 to 100 is often impractical for real-world sites with any dynamic content. A score of 90+ on mobile is the point of diminishing returns for most sites. Beyond that, you're spending significant engineering time for tiny user experience improvements. Exceptions: if you're in a competitive SEO niche where every signal matters, or if your real-world LCP is still above 2.5s even with a high score, keep optimizing. ## What to Do If Your Score Is Low 1. Run the test 3 times and take the average -- single scores vary 2. Check the "Opportunities" section in PageSpeed Insights -- it ranks fixes by impact 3. Fix your LCP first (biggest weight, biggest user impact) 4. Fix TBT second (second biggest weight, reflects JavaScript overhead) 5. Fix CLS third (layout shifts cause user frustration and accidental clicks) [Test your site now](/test) to see your current score and exactly what's affecting it. --- # What Is CLS and How to Fix It Canonical source: https://thefastestweb.site/blog/what-is-cls-and-how-to-fix-it Publisher: TheFastestWeb Author: TheFastestWeb Published: 2026-03-19T00:00:00.000Z Cumulative Layout Shift measures visual stability. It's worth 25% of your PageSpeed score and one of the easiest Core Web Vitals to fix once you know what's causing it. Cumulative Layout Shift (CLS) measures how much your page content moves around while it loads. It's one of Google's three Core Web Vitals and accounts for 25% of your PageSpeed score. A good CLS score is under 0.1. Above 0.25 is considered poor. ## What CLS Actually Measures Imagine you're reading an article and an image loads above the text, pushing everything down. Or you're about to click a button and an ad banner appears, making you click the wrong thing. That's layout shift. CLS scores each unexpected shift based on how much of the viewport moved and how far it moved. The score is the sum of all those shifts during the page load. ## Why CLS Matters Beyond the PageSpeed score, CLS directly affects user experience. Pages with high CLS feel unstable and unprofessional. Google uses it as a signal that your page is frustrating to use. The good news: CLS is usually the easiest Core Web Vital to fix. Most causes have straightforward solutions. ## Common Causes of High CLS ### Images Without Dimensions If your `` tags don't have explicit `width` and `height` attributes, the browser doesn't know how much space to reserve. When the image loads, it pushes everything below it down. **Fix:** Always include width and height on images: ```html Hero ``` In Next.js, the `` component handles this automatically as long as you provide width and height props. ### Web Fonts Causing FOUT When a custom font loads and replaces the fallback font, the text can reflow if the two fonts have different character sizes. This is called Flash of Unstyled Text (FOUT). **Fix:** Use `font-display: swap` and size your fallback font to match your custom font as closely as possible. Modern browsers support `size-adjust` in `@font-face` to match fallback metrics: ```css @font-face { font-family: "MyFont"; src: url("/fonts/myfont.woff2") format("woff2"); font-display: swap; } ``` ### Ads, Embeds, and Iframes Ad networks inject content dynamically, often without reserved space. Social embeds (Twitter cards, YouTube) expand when they load. **Fix:** Always reserve space for ad slots and embeds before they load: ```css .ad-slot { min-height: 250px; } ``` For YouTube embeds, use a 16:9 aspect ratio placeholder: ```css .video-wrapper { aspect-ratio: 16 / 9; } ``` ### Dynamically Injected Content If JavaScript injects content (banners, cookie notices, notifications) above existing content after the page loads, it causes layout shift. **Fix:** Position dynamic content so it doesn't push other elements. Use fixed or absolute positioning for overlays. If you must inject content into the flow, do it before the page renders, not after. ### Late-Loading Embeds Third-party embeds like Calendly booking widgets, map embeds, or review widgets often don't declare their size upfront. **Fix:** Wrap the embed in a container with an explicit height, or lazy-load it below the fold where any shift won't be measured. ## How to Find What's Causing Your CLS **Chrome DevTools:** Open the Performance tab, record a page load, and look for "Layout Shift" entries in the timeline. Click one to see which element shifted and why. **PageSpeed Insights:** Run your URL through [Google PageSpeed Insights](https://pagespeed.web.dev/). Scroll to the "Avoid large layout shifts" diagnostic. It will show you the specific elements causing shifts and their individual impact scores. **Web Vitals Extension:** Install the [Web Vitals Chrome extension](https://chrome.google.com/webstore/detail/web-vitals/ahfhijdlegdabablpippeagghigmibgt). It highlights layout shifts in real time with colored overlays as the page loads. ## CLS Targets | Score | CLS | |---|---| | Good | Under 0.1 | | Needs improvement | 0.1 to 0.25 | | Poor | Over 0.25 | ## Quick Checklist - [ ] All `` tags have explicit `width` and `height` - [ ] Fonts use `font-display: swap` - [ ] Ad slots have reserved `min-height` - [ ] Video and embed containers have explicit dimensions or `aspect-ratio` - [ ] Cookie notices and banners don't push content down - [ ] No content injected above existing content after page load CLS is often completely fixable in an afternoon. Adding dimensions to images alone resolves the issue for most sites. [Test your site](/test) to see your current CLS score and find out exactly which elements are causing shifts. --- # What Is FCP and How to Fix It Canonical source: https://thefastestweb.site/blog/what-is-fcp-and-how-to-fix-it Publisher: TheFastestWeb Author: TheFastestWeb Published: 2026-03-12T00:00:00.000Z First Contentful Paint measures how quickly your page shows its first piece of content. It's worth 10% of your PageSpeed score and affects how fast your site feels. First Contentful Paint (FCP) measures how long it takes for the browser to render the first piece of content on the screen. That content can be text, an image, a background image, or an SVG. FCP is worth 10% of your PageSpeed score. A good FCP is under 1.8 seconds. Above 3 seconds is considered poor. ## Why FCP Matters FCP is the first signal to the user that the page is actually loading. Before FCP, the screen is blank. A slow FCP makes users think the site is broken or down, leading to higher bounce rates even if the rest of the page loads quickly. It's different from LCP (Largest Contentful Paint), which measures when the main content loads. FCP just measures the very first thing the user sees. ## What Causes Slow FCP ### Slow Server Response (High TTFB) If your server takes a long time to respond, FCP can't start until the HTML arrives. TTFB (Time to First Byte) directly delays FCP. **Fix:** Use caching, move to faster hosting, or use edge/CDN delivery. ### Render-Blocking Resources CSS and synchronous JavaScript in the `` block the browser from rendering anything until they finish loading and parsing. **Fix:** Move non-critical CSS to load asynchronously. Add `defer` or `async` to JavaScript. Inline the critical CSS needed for above-the-fold content. ### Large HTML Payload If your server sends a huge HTML document before the browser can start rendering, FCP is delayed. **Fix:** Use server-side rendering or static generation so the first HTML response includes ready-to-display content. Avoid loading all content on a single giant page. ### Too Many Redirects Each redirect adds a round trip before the browser gets the actual page content. **Fix:** Eliminate redirect chains. Go directly from the URL to the final destination. ## How to Fix FCP ### 1. Eliminate Render-Blocking CSS Move non-critical CSS out of the `` or load it asynchronously: ```html ``` Inline only the CSS needed to render above-the-fold content. Everything else can load after FCP. ### 2. Defer JavaScript Any JavaScript in the `` without `defer` or `async` blocks rendering: ```html ``` ### 3. Use a CDN A CDN puts your content on servers close to your users, reducing TTFB and therefore FCP. This is one of the highest-impact changes for global audiences. ### 4. Preconnect to Critical Origins If your page loads resources from external domains (fonts, analytics, CDN assets), add preconnect hints to start those connections early: ```html ``` ### 5. Use Server-Side Rendering Client-side rendered apps (React, Vue, Angular SPAs without SSR) show a blank screen until JavaScript loads and runs. This devastates FCP. Switch to SSR or static generation so the browser receives rendered HTML immediately. ## FCP vs LCP People often confuse FCP and LCP: - **FCP:** First piece of any content (text, image, SVG). Happens early. - **LCP:** The largest content element visible in the viewport. Happens later. FCP is always earlier than or equal to LCP. A fast FCP makes the page feel responsive. A fast LCP makes it feel loaded. ## FCP Targets | Score | FCP | |---|---| | Good | Under 1.8s | | Needs improvement | 1.8s to 3s | | Poor | Over 3s | ## Quick Checklist - [ ] TTFB under 800ms (use CDN or faster hosting) - [ ] No render-blocking CSS in `` - [ ] All JavaScript has `defer` or `async` - [ ] Critical CSS inlined - [ ] No unnecessary redirects - [ ] Preconnect hints for external resources - [ ] SSR or static generation (not pure client-side rendering) [Test your site](/test) to see your current FCP and get a full breakdown of all your Core Web Vitals. --- # What Is LCP and How to Fix It Canonical source: https://thefastestweb.site/blog/what-is-lcp-and-how-to-fix-it Publisher: TheFastestWeb Author: TheFastestWeb Published: 2026-03-22T00:00:00.000Z Largest Contentful Paint is one of the most important Core Web Vitals. Here's what it measures, why it matters, and how to improve it. Largest Contentful Paint (LCP) measures how long it takes for the largest visible element on your page to load. It's one of Google's three Core Web Vitals and counts for 25% of your PageSpeed score. A good LCP score is under 2.5 seconds. Above 4 seconds is considered poor and will hurt your rankings. ## What Counts as the LCP Element? Google measures whichever of these is largest in the viewport when the page loads: - Hero images or background images - Large text blocks (headlines) - Video poster images - Images inside `` tags Most of the time, it's your hero image or the main headline at the top of the page. ## Why LCP Matters for SEO Google uses Core Web Vitals as a ranking factor. A slow LCP tells Google that your page feels slow to users, which can push you down in search results. Sites with LCP under 2.5 seconds consistently outrank those above 4 seconds for the same keywords. ## Common Causes of Poor LCP ### Slow Server Response If your server takes a long time to respond (high TTFB), LCP will always be slow no matter how optimized your images are. Fix your server first. ### Unoptimized Images Large, uncompressed images are the most common cause. A 2MB hero image will take seconds to load on a typical connection. **Fix:** Compress images to WebP format. Aim for under 100KB for images that aren't full-bleed. Use responsive images with `srcset`. ### Render-Blocking Resources JavaScript and CSS that block rendering delay when the browser can even start painting the page. **Fix:** Move critical CSS inline. Defer non-critical JavaScript with `defer` or `async`. ### Images Not Preloaded If your LCP image is loaded via CSS or discovered late in parsing, the browser starts downloading it too late. **Fix:** Add a preload hint in your ``: ```html ``` In Next.js, add `priority` to your LCP image: ```tsx Hero ``` ### Lazy-Loaded LCP Image Never lazy-load your LCP image. If you have `loading="lazy"` on your hero image, remove it immediately. ## How to Find Your LCP Element 1. Open Chrome DevTools 2. Go to the Performance tab 3. Record a page load 4. Look for the "LCP" marker in the timeline Or run your URL through [Google PageSpeed Insights](https://pagespeed.web.dev/) and scroll to the "Diagnostics" section. It will highlight exactly which element is your LCP and why it's slow. ## LCP Targets | Score | LCP | |---|---| | Good | Under 2.5s | | Needs improvement | 2.5s to 4s | | Poor | Over 4s | ## Quick Checklist - [ ] Hero image is WebP, under 100KB - [ ] LCP image has `priority` (Next.js) or `` - [ ] No `loading="lazy"` on the LCP image - [ ] TTFB is under 800ms - [ ] Critical CSS is inlined or loaded early - [ ] No render-blocking scripts above the fold Fixing LCP is usually the highest-impact change you can make to your PageSpeed score. Most sites can go from a 4-second LCP to under 2 seconds with just image optimization and a preload hint. Want to see your current LCP score? [Test your site for free](/test) and we'll show you your full Core Web Vitals breakdown. --- # What Is PageSpeed Insights and How to Use It Canonical source: https://thefastestweb.site/blog/what-is-pagespeed-insights Publisher: TheFastestWeb Author: TheFastestWeb Published: 2026-03-30T00:00:00.000Z Google PageSpeed Insights is the standard tool for measuring website performance. Here's what it measures, how to read the results, and what to do with them. Google PageSpeed Insights (PSI) is a free tool from Google that measures how fast your website loads and how good the user experience is. It gives your site a score from 0 to 100 and tells you exactly what's slowing it down. It's the most widely used web performance tool and the standard reference for SEO and performance discussions. ## What PageSpeed Insights Actually Tests PSI runs your URL through Google's Lighthouse engine, which simulates a page load on a mid-range mobile device on a typical mobile network. It captures performance data and calculates a score based on six metrics: | Metric | Weight | What It Measures | |---|---|---| | Total Blocking Time (TBT) | 30% | JavaScript blocking the main thread | | Largest Contentful Paint (LCP) | 25% | When the main content loads | | Cumulative Layout Shift (CLS) | 25% | Visual stability (content moving) | | First Contentful Paint (FCP) | 10% | When first content appears | | Speed Index (SI) | 10% | How quickly the page fills in | These are called Core Web Vitals (LCP, CLS, TBT/FID) and are used by Google as a ranking signal. ## Lab Data vs Field Data PSI shows two types of data: **Field Data (Chrome User Experience Report):** Real performance data collected from actual Chrome users visiting your site over the past 28 days. This is what Google actually uses for search rankings. If you've just launched or have low traffic, this section may not appear. **Lab Data (Lighthouse):** A simulated test run in controlled conditions. This is what gives you the 0-100 score and the specific recommendations. It's useful for debugging and tracking improvements. Both matter. Field data tells you how your real users experience the site. Lab data tells you what to fix. ## How to Read Your Score **90-100:** Good. Your site is well optimized. **50-89:** Needs improvement. There are meaningful gains available. **0-49:** Poor. Significant performance issues affecting user experience and rankings. The score is calculated on a logarithmic scale, which means going from 50 to 70 is easier than going from 85 to 95. **Desktop vs Mobile:** PSI tests both. Desktop scores are almost always higher because it simulates a faster device and connection. Google prioritizes mobile performance for rankings, so focus on your mobile score. ## How to Read the Diagnostics Below the score, PSI shows three sections: **Opportunities:** Specific improvements with estimated time savings. These are ranked by potential impact. Fix the top ones first. **Diagnostics:** Additional information about performance patterns. Less actionable than Opportunities but useful for understanding what's happening. **Passed Audits:** Things your site is already doing right. Ignore these. Click on any item to get detailed explanations and specific resources causing the problem. ## What the Metrics Mean in Plain English **LCP over 4s:** Your main content (hero image, headline) takes too long to appear. Usually an image or font loading issue. **TBT over 600ms:** Your JavaScript is blocking the browser for too long. Users can't interact with the page. Usually caused by large JS bundles or third-party scripts. **CLS over 0.25:** Content is jumping around as the page loads. Usually caused by images without dimensions or late-loading content. **FCP over 3s:** Nothing appears for over 3 seconds. Usually a server response or render-blocking resource issue. ## How to Use PSI Effectively **Test the right page.** Your homepage may be fast but product pages might not be. Test the pages that matter most for conversions and SEO. **Test multiple times.** Single runs can vary by 10-15 points depending on server load and network conditions. Run it 3 times and take the average. **Fix one thing at a time.** Make a change, run the test again, see if it improved. Don't make 10 changes at once. **Track over time.** A one-time test is a snapshot. Performance can degrade as you add features. Use a tool like [TheFastestWeb](/submit) to monitor your score daily automatically. ## Free Alternatives to PageSpeed Insights PSI is the standard, but other tools can give you additional insight: - **WebPageTest:** More detailed waterfall analysis, real browser testing - **GTmetrix:** Combines Lighthouse and WebPageTest, easy to read - **Lighthouse in Chrome DevTools:** Same engine as PSI, runs locally without network latency All of these use the same underlying metrics. PSI is the reference because it's what Google uses for rankings. ## The Relationship Between PSI and Google Rankings Google uses Core Web Vitals (LCP, CLS, and FID/INP) as a ranking factor as part of the Page Experience signal. A poor PageSpeed score doesn't automatically drop you in rankings, but sites with consistently good scores have an advantage over competitors with similar content. Think of it as a tiebreaker: if two pages are equally relevant for a query, the faster one ranks higher. [Test your site now](/test) and see your PageSpeed score in seconds. --- # What Is Speed Index and How to Fix It Canonical source: https://thefastestweb.site/blog/what-is-speed-index-and-how-to-fix-it Publisher: TheFastestWeb Author: TheFastestWeb Published: 2026-03-10T00:00:00.000Z Speed Index measures how quickly content is visually populated on your page. Here's what it means and how to improve it. Speed Index (SI) measures how quickly the visible content of a page is populated. Unlike LCP which measures a single element, Speed Index tracks the overall visual progress of the entire page loading from top to bottom. Speed Index accounts for 10% of your PageSpeed score. A good Speed Index is under 3.4 seconds. Above 5.8 seconds is considered poor. ## How Speed Index Is Calculated Speed Index captures screenshots of your page loading at multiple points in time and measures how complete the page looks at each point. A page that shows content gradually gets a better score than one that shows nothing for a long time and then everything at once. In technical terms, it's the area above the visual progress curve. A lower area means content appeared faster. ## What Causes a High Speed Index ### Render-Blocking Resources CSS and synchronous JavaScript that block rendering delay when the browser can start painting the page, which directly increases Speed Index. ### Slow Server Response If the server takes a long time to respond, no rendering can happen until the HTML arrives. A high TTFB pushes Speed Index up. ### JavaScript-Heavy Pages Pages that rely heavily on JavaScript to render content show nothing until the JS runs. This creates a gap in visual progress that Speed Index penalizes. ### Large Images Above the Fold Images that take a long time to load leave visible blank spaces on the page. Speed Index tracks these gaps. ### Fonts Causing Invisible Text If fonts take a long time to load and you're using `font-display: block`, your text is invisible until the font arrives. Speed Index captures this invisible period. ## How to Fix Speed Index Speed Index improves when you improve FCP and LCP. Most of the same techniques apply. ### 1. Eliminate Render-Blocking Resources Move non-critical CSS out of the ``. Add `defer` to JavaScript. Inline the critical CSS needed for above-the-fold content so the browser can start rendering immediately. ### 2. Use Font Display Swap Replace `font-display: block` with `font-display: swap` so text renders immediately in a fallback font while the custom font loads: ```css @font-face { font-family: "MyFont"; src: url("/fonts/myfont.woff2") format("woff2"); font-display: swap; } ``` ### 3. Preload Critical Resources Tell the browser to start loading critical resources early: ```html ``` ### 4. Optimize Above-the-Fold Images Images visible when the page first loads should be compressed, correctly sized, and not lazy-loaded. A blank image placeholder while the image loads directly hurts Speed Index. ### 5. Use Server-Side Rendering Client-side rendered apps delay all visual content until JavaScript runs. Switching to SSR means the browser gets rendered HTML immediately and can start displaying content right away. ### 6. Avoid Content Jumping In Avoid using JavaScript to populate content after the initial render for above-the-fold areas. If your hero text, navigation, or featured content loads in via `useEffect`, the page will look blank during that period. ## Speed Index vs FCP vs LCP These three metrics all measure visual performance but from different angles: - **FCP:** When the first piece of any content appears (earliest) - **Speed Index:** How quickly the overall page fills in (average visual progress) - **LCP:** When the largest content element loads (often the most meaningful) A fast FCP that's followed by a slow trickle of content will still have a high Speed Index. You need both a fast FCP and consistent visual progress. ## Speed Index Targets | Score | Speed Index | |---|---| | Good | Under 3.4s | | Needs improvement | 3.4s to 5.8s | | Poor | Over 5.8s | ## Quick Checklist - [ ] No render-blocking CSS in `` - [ ] JavaScript uses `defer` or `async` - [ ] Critical CSS inlined - [ ] Fonts use `font-display: swap` - [ ] Critical resources preloaded - [ ] Above-the-fold images loaded eagerly and compressed - [ ] SSR or static generation (not client-side only rendering) - [ ] No content injected by JavaScript above the fold after load Speed Index rarely needs to be addressed in isolation. If your FCP and LCP are good, Speed Index usually takes care of itself. [Test your site](/test) to see your Speed Index alongside all your other Core Web Vitals metrics. --- # What Is TBT and How to Fix It Canonical source: https://thefastestweb.site/blog/what-is-tbt-and-how-to-fix-it Publisher: TheFastestWeb Author: TheFastestWeb Published: 2026-03-20T00:00:00.000Z Total Blocking Time is the biggest factor in your PageSpeed score at 30%. Here's what it measures and how to reduce it. Total Blocking Time (TBT) is the single biggest factor in your Google PageSpeed score, carrying 30% of the total weight. Yet it's one of the least understood metrics. Here's what it means and how to fix it. ## What TBT Measures TBT measures the total time the browser's main thread is blocked from responding to user input. A task is considered "blocking" if it takes longer than 50 milliseconds. TBT adds up all the blocking time from those tasks between First Contentful Paint and Time to Interactive. In simpler terms: TBT measures how long your JavaScript makes the page feel frozen. A good TBT is under 200ms. Above 600ms is considered poor. ## Why TBT Is Such a Big Deal When the main thread is blocked, the browser can't respond to clicks, scrolls, or keyboard input. The page appears loaded but feels sluggish. Users notice this and so does Google. Because TBT is 30% of the score, even a perfect LCP and CLS won't save you if your JavaScript is heavy. A TBT of 600ms alone can drop your score by 15-20 points. ## What Causes High TBT ### Too Much JavaScript The most common cause by far. Every JavaScript file you ship has to be parsed, compiled, and executed on the main thread. Large bundles from frameworks, UI libraries, and dependencies all contribute. ### Third-Party Scripts Google Analytics with GTM, chat widgets, A/B testing tools, heat maps, ad scripts. Each of these runs on the main thread. The more you load, the higher your TBT. ### Long Tasks in Your Own Code Sometimes it's not third-party scripts but your own JavaScript. Expensive computations, large loops, or synchronous data processing on page load all block the thread. ### Unused JavaScript If you're shipping code that isn't used on the current page, the browser still has to parse it. Code splitting is essential to avoid this. ## How to Fix TBT ### 1. Defer All Non-Critical Scripts Any script that doesn't need to run before the page is interactive should be deferred: ```html ``` In Next.js, use the ` ``` In React/Vue/Svelte apps, lazy-load components that aren't needed on the initial render: ```js const HeavyChart = lazy(() => import("./HeavyChart")); ``` ### 3. Break Up Long Tasks Long tasks block the main thread and keep TTI high. Break them into smaller pieces: ```js // Instead of one blocking task processLargeDataset(data); // Use scheduler to yield to the browser between chunks async function processInChunks(data) { for (let i = 0; i < data.length; i += 100) { processChunk(data.slice(i, i + 100)); await new Promise(r => setTimeout(r, 0)); // yield } } ``` ### 4. Remove or Delay Third-Party Scripts Audit every third-party script on your page. For each one, ask whether it needs to load before the page is interactive. Most analytics tools don't need to run before interaction. Load them with `strategy="lazyOnload"` in Next.js or add `defer` to the script tag. ### 5. Use Server-Side Rendering Pages rendered on the server are visually complete immediately when they arrive. The remaining JavaScript needed for interactivity is smaller, reducing TTI. ## TTI vs TBT TTI and TBT (Total Blocking Time) are closely related: - **TTI:** The timestamp when the page becomes fully interactive - **TBT:** The total duration of long tasks between FCP and TTI TBT is a better metric for optimization because it's less variable and more actionable. Fixing TBT usually fixes TTI as a side effect. ## Realistic TTI Targets | Site Type | Good TTI | |---|---| | Static landing page | Under 2s | | Marketing site (SSR) | Under 3s | | SaaS app (SSR) | Under 4s | | Complex dashboard | Under 5s | ## Quick Checklist - [ ] JavaScript bundle analyzed and reduced - [ ] Code splitting enabled (routes load only what they need) - [ ] Third-party scripts deferred or lazy-loaded - [ ] No synchronous long tasks on page load - [ ] SSR or static generation used for public pages - [ ] Web Workers used for heavy computation [Test your site](/test) to see your TTI and identify what's delaying interactivity on your pages. --- # Why Your PageSpeed Score Dropped (And How to Fix It) Canonical source: https://thefastestweb.site/blog/why-your-pagespeed-score-dropped Publisher: TheFastestWeb Author: TheFastestWeb Published: 2026-03-23T00:00:00.000Z Updated: 2026-09-20T00:00:00.000Z A sudden PageSpeed score drop can silently kill your Google rankings before you notice. Here's how to diagnose what went wrong and recover fast. Your site was fast. Then you launched something new, a redesign, a new plugin, a third-party widget, and your PageSpeed score quietly tanked. Traffic followed a few weeks later. A framework migration can increase JavaScript work or introduce layout shifts even when the site looks unchanged. Compare measurements from before and after the release; a traffic change by itself does not establish that performance caused it. Here's how to figure out why your score dropped and how to get it back. ## The Most Common Causes ### 1. A New Third-Party Script Analytics tools, chat widgets, A/B testing scripts, ad networks. These are the most frequent culprits. Each one blocks the main thread and drives up your **Total Blocking Time (TBT)**, which accounts for 30% of your PageSpeed score. Check your score breakdown in [Google PageSpeed Insights](https://pagespeed.web.dev/) and look at the "Reduce JavaScript execution time" and "Avoid long main-thread tasks" diagnostics. **Fix:** Load third-party scripts with `defer` or `async`, or use a facade (lazy-load the widget only on interaction). ### 2. Unoptimized Images Adding a hero image, a new team photo, or a background without compressing it first can tank your **Largest Contentful Paint (LCP)**, which is 25% of your score. **Fix:** Compress images before uploading. Use WebP format. In Next.js, use the `` component. It automatically serves the right size and format. Make sure your LCP image has `priority` set. ### 3. A Framework or Dependency Upgrade Upgrading frameworks, adding a new npm package, or switching CSS libraries can add kilobytes of JavaScript you don't realize is there. **Fix:** Run a bundle analyzer (`@next/bundle-analyzer` for Next.js) to see what's bloating your JS. Look for large dependencies you can replace with smaller alternatives. ### 4. Layout Shifts from Fonts or Ads If you added a custom font without `font-display: swap`, or if an ad slot loaded in and pushed content down, your **Cumulative Layout Shift (CLS)** will have increased. CLS is 25% of your score. **Fix:** Always use `font-display: swap` in your CSS. Reserve space for ads and embeds with explicit width/height attributes. Avoid inserting content above existing content after page load. ### 5. Server Response Time Regression If your hosting got slower (overloaded shared server, cold starts on serverless, a slow database query), your **Time to First Byte (TTFB)** increases, which pushes everything else back. **Fix:** Check your server logs for slow queries. Use caching (Redis, CDN edge caching). Consider moving to a faster host or region closer to your users. ## How to Diagnose It 1. **Run a PageSpeed test** with [TheFastestWeb](/test) or Google PageSpeed Insights 2. **Look at the score breakdown.** Which metrics dropped? LCP, TBT, CLS? 3. **Check the "Opportunities" and "Diagnostics" sections.** PageSpeed will tell you exactly what's causing the problem. 4. **Compare against your history.** If you're listed on TheFastestWeb, your score history shows exactly when it dropped. ## How to Recover Once you know the cause, the fix is usually straightforward: - **TBT high?** Audit your JavaScript. Defer scripts, remove unused code. - **LCP slow?** Optimize your hero image, preload critical resources. - **CLS issues?** Add explicit dimensions to images, reserve space for dynamic content. - **TTFB slow?** Cache aggressively, move to edge hosting. The key is to fix the specific metric that dropped rather than trying to optimize everything at once. ## Monitor It Going Forward A score drop can go unnoticed between releases. Keep a record of measurements so you can compare performance under similar conditions. Regular monitoring can help identify a regression. Review the recorded test dates and compare the same device and measurement method. A score change alone does not establish a change in search rankings. [Submit your site](/submit) to keep a public performance report. Scheduled retests and email alerts depend on service availability and your notification preferences. --- # Wix PageSpeed Optimization Guide Canonical source: https://thefastestweb.site/blog/wix-pagespeed-optimization-guide Publisher: TheFastestWeb Author: TheFastestWeb Published: 2026-03-22T00:00:00.000Z Wix handles hosting and infrastructure for you, but there are still several things you can do to improve your PageSpeed score. Here's what works and what doesn't. Wix is a fully hosted website builder. Unlike WordPress or self-hosted frameworks, you don't control the server, CDN, or code output. This limits what you can optimize, but there's still meaningful room for improvement. Here's what actually helps on Wix and what to skip. ## Understanding Wix's Performance Baseline Wix has invested significantly in performance in recent years. They moved to a server-side rendering architecture (Wix Editor X and newer sites), use global CDN distribution, and automatically compress images. The platform-level performance is decent. Most Wix sites should be able to achieve scores in the 65-80 range on mobile without any effort. Getting above 80 requires active optimization. ## What You Can Control on Wix ### 1. Optimize Images Images are the biggest variable on Wix. The platform auto-converts to WebP and serves from CDN, but it can only optimize what you give it. - **Compress before uploading.** Use Squoosh or TinyPNG on your images before adding them to Wix. Even though Wix compresses images, starting with a smaller source means better output. - **Use the right dimensions.** Don't upload a 4000px wide image for a 600px slot. Resize to roughly 2x the display size (for retina) before uploading. - **Don't overload pages with images.** Each additional image is another request. Use only the images that serve a purpose. ### 2. Set Your LCP Image to Load Eagerly Your hero image (the large image at the top of your page) is likely your LCP element. Make sure it's the first image on the page and not hidden below other content. In Wix, you can't directly add `loading="eager"` or `fetchpriority="high"` attributes, but you can: - Place the hero image as the first visible element - Avoid having any JavaScript-loaded content above the hero - Keep the hero image file size small (under 150KB after compression) ### 3. Remove Unused Apps and Widgets Every Wix app you install may add JavaScript to your page. Wix Chat, booking widgets, countdown timers, and social feeds all have a performance cost. Audit your installed apps in the Wix App Manager. Remove any app you're not actively using. This is the highest-impact change you can make. ### 4. Minimize Animations Wix makes it easy to add entrance animations and hover effects. Each animation adds JavaScript that must execute before the page becomes fully interactive. Disable animations on elements that don't need them. For important landing pages, consider turning off all entrance animations to reduce TBT. ### 5. Reduce Content Per Page Heavy pages with many sections, videos, embedded maps, and widgets will score lower than focused pages. If your homepage is a single long scroll with 15 sections, consider splitting content across pages. ### 6. Connect a Custom Domain Wix sites on the free plan show on a `wixsite.com` subdomain. This doesn't directly affect performance, but using a custom domain with proper DNS settings (including Wix's CDN) gives slightly better TTFB. ## What You Can't Control on Wix - **JavaScript output.** Wix generates and serves the JavaScript. You can't minify or tree-shake it yourself. - **Rendering architecture.** You can't switch to pure static generation. - **Font loading strategy.** You can choose fonts from Wix's library, but you can't add custom `font-display` settings. - **Server-side code execution.** Wix Velo (their code platform) lets you add backend logic but you can't optimize how Wix's own code runs. - **HTTP/3 or custom headers.** Infrastructure decisions are Wix's. ## Realistic Score Expectations | Page Type | Expected Mobile Score | |---|---| | Simple landing page | 70-82 | | Homepage with video | 55-70 | | Homepage with chat widget | 60-72 | | App-heavy store page | 45-62 | | Optimized product/blog page | 72-85 | Wix is not designed to compete with statically-generated sites on raw PageSpeed scores. The platform adds overhead that you can't remove. But for most small businesses and portfolios, scores in the 65-80 range are acceptable. ## Should You Migrate to a Faster Platform? If you're hitting a ceiling with Wix and performance is critical for your business: - **For marketing sites:** Consider Webflow or a static site generator - **For blogs:** Consider WordPress with a fast theme, or Ghost - **For e-commerce:** Consider Shopify But if you chose Wix because you need to manage your own content without technical knowledge, the performance trade-off may be worth it. A Wix site at 72 is still usable. What matters is whether the performance is affecting your conversions and rankings. ## Quick Checklist - [ ] All images compressed and resized before upload - [ ] Unused apps removed from App Manager - [ ] Unnecessary animations disabled - [ ] No embedded videos on pages where performance is critical - [ ] Custom domain connected (not `.wixsite.com`) - [ ] Pages not overloaded with sections and widgets [Test your Wix site](/test) to see your current PageSpeed score and which metrics are dragging it down. --- # WordPress PageSpeed Optimization Guide Canonical source: https://thefastestweb.site/blog/wordpress-pagespeed-optimization-guide Publisher: TheFastestWeb Author: TheFastestWeb Published: 2026-03-17T00:00:00.000Z WordPress powers 40% of the web but is notorious for slow scores. Here's exactly how to get a fast PageSpeed score on WordPress without breaking your site. WordPress powers over 40% of the web, but it has a reputation for being slow. Plugins, themes, and third-party scripts pile up over time, and before you know it your PageSpeed score is in the 30s. The good news: WordPress can score in the 90s. It just takes deliberate optimization. ## Why WordPress Is Slow by Default WordPress itself is reasonably lean. The problems come from: - **Bloated themes** that load fonts, scripts, and styles you don't use - **Too many plugins**, each adding their own JavaScript and CSS - **No caching**, so every request hits PHP and the database - **Unoptimized images** uploaded without compression - **Shared hosting** with slow server response times Fix these, and your score will jump significantly. ## Step 1: Choose a Fast Theme If you're on a heavy page builder theme like Divi, Avada, or Elementor with a complex theme, this is likely your biggest bottleneck. These themes load hundreds of kilobytes of CSS and JavaScript on every page. Switch to a lightweight theme: - **GeneratePress** (free and premium) - under 10KB base CSS - **Kadence** - fast, block-based, minimal footprint - **Astra** - popular, performance-focused - **Blocksy** - modern, lightweight If you're locked into your current theme, at least disable the features you don't use in the theme settings. ## Step 2: Install a Caching Plugin Without caching, WordPress generates each page dynamically on every request. This kills your TTFB (Time to First Byte). The best free caching plugins: - **WP Rocket** (paid, worth it) - best all-in-one solution - **W3 Total Cache** - free, powerful but complex to configure - **LiteSpeed Cache** - free, excellent if your host runs LiteSpeed - **WP Super Cache** - simple, reliable Enable page caching, browser caching, and Gzip compression at minimum. ## Step 3: Optimize Images Images are almost always the biggest contributor to slow LCP scores in WordPress. **Use a compression plugin:** - **ShortPixel** - excellent compression, 100 free images/month - **Smush** - popular free option - **Imagify** - fast, good quality **Enable WebP conversion.** Most compression plugins do this automatically. WebP files are 25-35% smaller than JPEG at the same quality. **Set lazy loading.** WordPress 5.5+ adds `loading="lazy"` to images automatically. Make sure it's not disabled. **Never lazy-load your hero image.** If your theme or plugin is adding `loading="lazy"` to the first image on the page, remove it. That image is your LCP element and needs to load immediately. ## Step 4: Minimize JavaScript and CSS Every plugin adds its own scripts and stylesheets, even on pages where that plugin isn't used. **WP Rocket** handles this well with its asset optimization settings. For free alternatives: - **Asset CleanUp** - lets you disable scripts and styles per page - **Autoptimize** - combines and minifies CSS and JS files Key settings to enable: - Minify CSS and JavaScript - Combine CSS files (be careful, this can break some plugins) - Defer render-blocking JavaScript - Remove unused CSS **Test after each change.** Aggressive JS/CSS optimization can break plugin functionality. Enable changes one at a time. ## Step 5: Use a CDN A Content Delivery Network serves your static assets (images, CSS, JS) from servers close to your visitors. This reduces load time for users who aren't near your hosting server. Free options: - **Cloudflare** - free tier is excellent, also improves TTFB - **BunnyCDN** - cheap and fast ($1/month for most sites) Most caching plugins integrate with CDNs directly. ## Step 6: Upgrade Your Hosting Shared hosting puts your site on a server with hundreds of other sites competing for the same resources. This creates slow, unpredictable TTFB. For better performance: - **Cloudways** - managed cloud hosting, good value - **WP Engine** - WordPress-specific, fast, more expensive - **Kinsta** - premium WordPress hosting on Google Cloud - **SiteGround** - better than average shared hosting Even moving from cheap shared hosting to a $10/month VPS can cut your TTFB by 500ms. ## Step 7: Audit Your Plugins Every active plugin adds overhead. Go through your plugin list and ask: do I actually need this? Common plugins that hurt performance and have lighter alternatives: | Heavy Plugin | Lighter Alternative | |---|---| | Contact Form 7 + addons | Fluent Forms | | Jetpack (all features) | Individual plugins for what you need | | Google Analytics plugin | Direct script in header or Umami | | Social sharing plugins | Hardcoded share links | | Full page builders | Native WordPress blocks | Deactivate and delete plugins you aren't using. Inactive plugins still bloat your database and sometimes still load assets. ## Realistic Score Targets for WordPress | Setup | Realistic Score | |---|---| | Optimized theme + WP Rocket + CDN | 80-95 | | Lightweight theme, basic caching | 65-80 | | Heavy page builder, no caching | 30-55 | | WooCommerce store, optimized | 60-75 | ## Quick Checklist - [ ] Lightweight theme (GeneratePress, Astra, Kadence) - [ ] Caching plugin enabled (page cache + browser cache + Gzip) - [ ] All images compressed and served as WebP - [ ] Hero image not lazy-loaded - [ ] JavaScript deferred where possible - [ ] Unused plugin scripts disabled per-page - [ ] CDN configured for static assets - [ ] Hosting upgraded from shared if TTFB is above 800ms WordPress can absolutely be fast. It just requires more deliberate effort than frameworks that optimize by default. [Test your WordPress site](/test) to see your current PageSpeed score and find out exactly what's slowing you down. --- # WordPress vs Webflow: Which Is Faster? Canonical source: https://thefastestweb.site/blog/wordpress-vs-webflow-speed Publisher: TheFastestWeb Author: TheFastestWeb Published: 2026-03-18T00:00:00.000Z WordPress and Webflow take very different approaches to building websites. Here's how they compare on real-world PageSpeed scores and what affects performance on each. WordPress and Webflow are two of the most popular ways to build websites without writing everything from scratch. They have completely different architectures, and that architecture directly affects how fast your site can be. ## The Short Answer **Webflow is faster by default.** A new Webflow site with no customization will almost always outperform a default WordPress installation. But a heavily optimized WordPress site can match or beat Webflow. The catch: optimization on WordPress requires more work and technical knowledge. ## How Each Platform Works ### WordPress WordPress is a self-hosted PHP CMS. You install it on a server, add a theme, and install plugins. The speed of your site depends heavily on: - Your hosting provider - Which theme you use (and how bloated it is) - Which plugins you have (and how many) - Whether you've set up caching - Whether you're using a CDN A fresh WordPress install is reasonably fast. The problem is that every plugin and theme adds JavaScript, CSS, and database queries. By the time a typical business WordPress site has a page builder, contact form, SEO plugin, analytics, and a slider, it's loading hundreds of kilobytes of CSS and JS that may or may not be needed on a given page. ### Webflow Webflow is a hosted website builder where you design visually and Webflow outputs clean HTML/CSS/JavaScript. Webflow handles hosting on their global CDN automatically. The output is typically leaner than a WordPress site because you're not layering plugins on top of plugins. Webflow also doesn't run server-side PHP for each request -- pages are static HTML served from a CDN. ## Real-World PageSpeed Scores Typical scores across both platforms: | Setup | Mobile Score | Desktop Score | |---|---|---| | WordPress (default, no optimization) | 40-60 | 60-80 | | WordPress (optimized, good hosting, caching) | 75-95 | 85-100 | | WordPress (page builder like Elementor) | 30-55 | 50-75 | | Webflow (default) | 65-85 | 80-95 | | Webflow (optimized, minimal custom code) | 80-95 | 90-100 | Webflow starts ahead. WordPress can get ahead, but needs work to get there. ## What Hurts WordPress Speed **Page builders.** Elementor, Divi, WPBakery, and similar tools load large amounts of CSS and JavaScript regardless of what's on the page. Elementor alone can add 300-400KB of CSS. If you're using a page builder, your baseline score will be lower. **Plugin accumulation.** Each plugin can add scripts and styles. A site with 30 plugins is almost always slower than a site with 10. **Shared hosting.** Cheap shared hosting has slow TTFB because the server is under load. A fast host (WP Engine, Kinsta, Cloudways) makes a huge difference. **No caching.** WordPress generates pages dynamically with PHP and MySQL. Without a caching plugin (WP Rocket, W3 Total Cache), every request hits the server fresh. ## What Hurts Webflow Speed **Custom code.** Webflow is fast by default, but if you add a lot of custom JavaScript or embed heavy third-party tools, the advantage narrows. **Animations and interactions.** Complex Webflow interactions load a larger JS bundle. Heavy animation-driven designs pay a performance cost. **Large images.** Webflow will optimize images to some extent, but oversized hero images still hurt LCP. **No server-side rendering for dynamic content.** Dynamic Webflow CMS pages are generated at publish time. This is fast, but complex queries or large CMS collections can affect build times and page complexity. ## How to Make WordPress Faster Than Webflow If you're on WordPress and want to compete with Webflow's scores: 1. **Use a fast theme.** GeneratePress, Kadence, or Astra instead of bloated themes. 2. **Get a caching plugin.** WP Rocket is the best option. LiteSpeed Cache if you're on LiteSpeed hosting. 3. **Use a CDN.** Cloudflare's free plan is a significant improvement for most sites. 4. **Optimize images.** Smush or Imagify to auto-compress uploads. 5. **Use good hosting.** Move to a managed WordPress host with fast TTFB. 6. **Avoid page builders if possible.** Or at minimum, use Bricks Builder which is significantly faster than Elementor. ## Which Should You Choose? **Choose Webflow if:** - You're a designer who wants visual control without code - You want good performance with minimal technical effort - You don't need complex plugins or integrations - You're building a marketing site, portfolio, or landing page **Choose WordPress if:** - You need specific plugins that don't exist in Webflow - You're building something complex (membership, WooCommerce, multisite) - You want full ownership of your hosting environment - You have a developer who can handle the optimization Both platforms can produce fast sites. Webflow gets there more easily. WordPress gets there with more control over the final result. [Test your site](/test) to see your current PageSpeed score regardless of which platform you're on.