Παράκαμψη στο περιεχόμενο
Blog
Blog23 Μαΐου 20264 min read

Lighthouse 100 Χωρίς Ψέματα: Τι Πραγματικά Απαιτείται

Lighthouse 100 Χωρίς Ψέματα: Τι Πραγματικά Απαιτείται

Κάθε εβδομάδα κάποιος μου στέλνει screenshot με Lighthouse 100 και ρωτάει «πώς το έκανες». Η αλήθεια είναι ότι το 100 σε desktop είναι σχετικά εύκολο. Το 100 σε mobile είναι πολύ δύσκολο. Και το 100 σε mobile σε production site με analytics, ads, και custom code, είναι σπάνιο.

Σε αυτό το άρθρο γράφω τι πραγματικά χρειάζεται, με βάση το dosmart.gr και 30+ production sites που έχουμε στήσει.

Τι μετράει στο Lighthouse

Το Performance score υπολογίζεται από πέντε μετρήσεις:

  • FCP (First Contentful Paint): πότε εμφανίζεται το πρώτο pixel
  • LCP (Largest Contentful Paint): πότε εμφανίζεται το μεγαλύτερο στοιχείο της σελίδας
  • TBT (Total Blocking Time): πόσο χρόνο block-άρει το main thread
  • CLS (Cumulative Layout Shift): πόσο μετακινούνται τα στοιχεία κατά τη φόρτωση
  • SI (Speed Index): πόσο γρήγορα εμφανίζεται το ορατό περιεχόμενο

Στο mobile profile, το Lighthouse προσομοιώνει αργό 4G με 150ms RTT. Αυτό σημαίνει ότι κάθε resource που χρειάζεται download προσθέτει latency. Είναι αυστηρό, αλλά αντικατοπτρίζει το χειρότερο σενάριο πραγματικού χρήστη.

Βήμα 1: Διάλεξε σωστά τη βάση

Δεν θα φτάσεις 100 mobile σε WordPress με Avada ή Divi theme. Όχι επειδή είναι κακά themes, αλλά επειδή φορτώνουν 800KB JavaScript για functionality που στις περισσότερες σελίδες δεν χρησιμοποιείς.

Για 90+ mobile, υπάρχουν τρεις δρόμοι:

  • WordPress + custom theme (όχι page builders)
  • Headless WordPress + Next.js ή Astro
  • Static site generator (Astro, Eleventy, Hugo)

Στο dosmart.gr τρέχουμε το δεύτερο. Lighthouse desktop 100, mobile 85-92.

Βήμα 2: Εικόνες

Αυτή είναι η ευκολότερη πηγή performance loss σε site που είναι ήδη γρήγορο. Τα checks:

  • Όλες οι εικόνες σε WebP ή AVIF
  • Hero image με fetchpriority=”high” και αντίστοιχο preload
  • Lazy load για όλες τις εικόνες κάτω από το fold
  • Responsive images με srcset για διαφορετικά viewports
  • Width και height attributes πάντα ορισμένα (αλλιώς CLS)

Βήμα 3: JavaScript

Το TBT είναι ο εχθρός στο mobile. Κάθε JavaScript file που πρέπει να γίνει parse + execute πριν την αλληλεπίδραση μετράει εις βάρος σου.

Πρακτικές που λειτουργούν:

  • Όλα τα 3rd-party scripts (Google Analytics, Tag Manager, Clarity, chat widgets) με strategy=”lazyOnload” στο Next.js, ή αντίστοιχο async defer
  • Sentry SDK μόνο όταν χρειάζεται, όχι σε κάθε page load
  • Code splitting σε route level
  • Tree shaking πάντα ενεργό στο production build
  • Δεν φορτώνεις libraries που χρησιμοποιείς για 1-2 σελίδες

Βήμα 4: CSS και fonts

Το CSS πρέπει να φτάνει στον browser σε under 50KB compressed. Τα fonts θέλουν προσοχή γιατί είναι render-blocking by default.

  • Inline critical CSS στο head, async load για το rest
  • Tailwind με purge ON για να μένει μόνο το CSS που χρησιμοποιείς
  • Custom fonts με font-display: swap
  • Subset Greek + Latin μόνο, όχι όλα τα subsets
  • Preload για τα critical fonts του above-the-fold

Βήμα 5: CDN και caching

Σε self-hosted setup, το TTFB κρίνει πολλά. Αν ο server είναι στη Γερμανία και ο επισκέπτης στην Ελλάδα, υπάρχει ένα RTT από 30-50ms που δεν μπορείς να αποφύγεις.

Λύση: Cloudflare με edge cache για τα static HTML pages. Στο dosmart.gr έχουμε page rule που cache-άρει τη homepage 5 λεπτά στο edge. Αυτό σημαίνει ότι ο επισκέπτης από Αθήνα παίρνει την σελίδα από το CF datacenter στη Σόφια ή Αθήνα, με 10-20ms TTFB.

Τι να αγνοήσεις

Δεν είναι όλα τα tips στο internet σωστά. Μερικά παραδείγματα που βλέπω επανειλημμένα:

  • «Απενεργοποίησε όλα τα plugins». Όχι. Απενεργοποίησε αυτά που δεν χρησιμοποιείς. Tα υπόλοιπα είναι μέρος του functionality.
  • «Βάλε caching plugin». Σε WordPress βοηθάει, αλλά αν τρέχεις σε managed hosting τύπου Coolify με Next.js, δεν χρειάζεται.
  • «Αφαίρεσε όλα τα tracking scripts». Η Google Analytics με lazyOnload δεν επηρεάζει ουσιαστικά. Αν τα αφαιρέσεις, χάνεις δεδομένα για τίποτα.
  • «Σερβίρει στατικά αρχεία στο root». Δεν είναι λύση για production site με dynamic content.

Πραγματικοί αριθμοί από dosmart.gr

Η homepage μας στο production μετράται έτσι:

  • Lighthouse desktop: 100
  • Lighthouse mobile: 85-92 (variance σε διαφορετικά runs)
  • LCP desktop: 0,6s
  • LCP mobile: 3,3s
  • CLS: 0,000
  • TBT mobile: 20ms
  • HTML transfer: 29KB compressed
  • JavaScript bundles: 240KB total στο first load

Δεν είναι 100 mobile. Και δεν λέμε ψέματα ότι είναι. Όποιος υπόσχεται σταθερό 100 mobile σε production site με ads, analytics, και custom functionality, ή λέει ψέματα ή σου δείχνει demo σελίδα χωρίς αυτά.

Συμπέρασμα

Lighthouse 95+ mobile είναι εφικτό. Lighthouse 100 mobile σε production είναι σπάνιο και απαιτεί τέτοιες αρχιτεκτονικές αποφάσεις που χάνεις σε λειτουργικότητα. Στόχευσε realistic. 90 mobile στο production = πολύ καλύτερο από 70% των ελληνικών sites.

Αν θες audit στο δικό σου site, στείλε URL εδώ. Δωρεάν analysis με συγκεκριμένες προτάσεις.

Χρειάζεσαι βοήθεια με κάτι από αυτά;

Φτιάχνουμε websites, e-shops και custom εφαρμογές. Αν σου άρεσε αυτό που διάβασες και θέλεις κάτι παρόμοιο για τη δική σου επιχείρηση, στείλε μας μήνυμα.

Μοιράσου το άρθρο:
Τσόκας Γιώργος

Τσόκας Γιώργος

Founder DoSmart

8+ χρόνια web development. Γράφει για πρακτικές λύσεις, τεχνολογίες και στρατηγικές που δουλεύουν πραγματικά.

Σου άρεσε το άρθρο;

Έτοιμος για το επόμενο βήμα;

Αν χρειάζεσαι website, e-shop, ή SEO βοήθεια, στείλε μας μήνυμα. Προσωπική απάντηση εντός 24 ωρών με αναλυτική πρόταση.